The new arm64 firmware supporting Secure Boot (see next commit) is in
QCOW2 format only, avoiding the extra space taken up by the 64MB
padding. Supporting both raw and QCOW2 images would be messy, so switch
entirely to QCOW2.
Only the 4MB images are in QCOW2 format on amd64, so also switch away
from the 2MB images. 4MB images are now the default for most
distributions as they are needed to apply certain Windows updates.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The Flatcar extensions get built by the GitHub PR CI but only their
content files get archived. Add the .raw image itself so that one can
copy it into the image (downloading it at boot time won't work because
this uses bincache - so one could get an extension image in case the but
version happens to match but it won't be the one that was built in the
GitHub CI).
The GitHub Action artifacts are compressed zip files which include
bz2 files which are either the raw .bin images that have many zero bytes
in the rootfs but the main data in /usr is using zstd compression, or
they are the qcow2 .img images which are compressed themselves (and of
course have the same /usr compression). The bz2 compression doesn't help
in our case.
Remove the bz2 compression layer. If in the future non-zip artifacts
are supported we can add it back for the .bin image only by using
explicit calls only for that file instead of the
--image_compression_formats= flag for all images.
The qemu and qemu_uefi_secure images have the same contents as the
qemu_uefi image which wastes space on the release server. A similar
case is the PXE vmlinuz which is the same as the regular one, too.
Set up symlinks for same images, and also detect this when compressing
to set up symlinks there as well. To reduce complexity, the qemu and
qemu_uefi_secure images are not supported anymore and the Jenkins or
GitHub CI will skip over them if specified. Users that build their own
images need to adapt, though.
The PXE image and its helper script is a very handy way to test an image
because it does not preserve state. One can boot the same file over and
over again without having to reset the image. One can also easily pass
in additional kernel cmdline options without having to set up grub.cfg.
show-fixed-kernel-cves.py script from flatcar-build-scripts requires
this package:
Traceback (most recent call last):
File "/home/runner/actions-runner/_work/scripts/scripts/flatcar-build-scripts/show-fixed-kernel-cves.py", line 29, in <module>
from packaging import version
ModuleNotFoundError: No module named 'packaging'
Instead of depending on default value of build_image's base_sysext
parameter, create a file that explicitly lists which base sysexts will
be built for each architecture. The file can be sourced by other
scripts that need this kind of information. Currently, image.sh and
image_changes.sh use this file.
This is to limit the amount of reports consisting purely of failures,
because some files were missing. And those files will be missing,
because an OEM might not even have any image for certain arches (like
digitalocean has no arm64 images).
It was only needed for the show-changes script. Now that show-changes
script allows to set the repos parent directory with an environment
variable, we set the variable instead of changing the working
directory.
There's a bug in show-changes script where it defaults to values with
single quotes in them. So the default scripts directory is not
"scripts" but "'scripts'". This will be fixed in show-scripts, but for
now work it around here by explicitly defining the directories.
The kola run didn't pick up the version that was set up in the build
because the git changes from that step are lost.
Redo the version setup in the kola run to use the same version, and
skip the kola update test if no update payload can be found. In the
future we should copy it over from the GitHub Action artifact.
This change updates dispatching of SDK and OS image builds from changes
to a PR to an explicit comment. PRs will only be built if that comment
was added by a member of the Flatcar maintainers team.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
This change adds a github actions workflow to build a new SDK container
based on an existing SDK container. This can be used for CI testing
intrusive changes that also affect the SDK without bootstrapping a whole
new SDK.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
In case of a draft PR created first, no CI gets triggered at the time.
So we should trigger CI afterwards when it is being set to a
ready_for_review state.
Build and CI tests should run automatically whenever a pull request is
opened, reopened or updated. On the other hand, it is not necessary to
run build and CI tests on the events ready_for_review and
review_requested.
This change adds markdown output support to tapfile helper.
tap_generate_report() has been refactored to use low-level output
functions to write tests; TAP and markdown output is supported and both
are generated by default. Also, it should be straightforward to add
other output formats by implementing the respective low level print
functions.
The markdown output is now used by run-kola-tests.yaml to generate step
output and, if run from a PR, add a comment with test results to the PR.
Signed-off-by: Thilo Fromm <thilofromm@microsoft.com>
This change removes "docker commit" at the end of each step and instead
makes build steps re-use the build container, saving some build time.
It also makes artifact upload more granular, so build logs, images, and
dev container can be downloaded individually.
Lastly, it exports torcx tarball and binary packages as a separate
artifact each, for successive re-use in the kola tests.
When the specified remote contains a same-named branch as origin,
the checkout fails with "fatal: 'X' matched multiple (Y) remote
tracking branches".
Add the remote name as prefix to make the reference unambiguous.
* arm64 tests now run in LXD containers instead of VMs
* parallelism increased for arm64
* some setup steps are skipped on arm64
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
* Adds a reusable workflow that can run tests
* Adapts the ci.yaml to use reusable workflow
* Creates a new workflow that helps trigger tests using an arbitrary
workflow run.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
this initial attempt runs right after the "packages" jobs and downloads
the resulting artifacts.
The QEMU image is unzipped then the kola test is running using the
ci-automation scripts.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
This change will prompt the CI workflow to cancel a currently running
job, if a new push is sent in a PR. This should prevent duplicate jobs
running for the same PR simultaneously.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Building for the branch push event causes two builds per PR and is not
needed anyway (we have nightly builds for the main branch).
Only consider PR events to trigger the CI build.
