GHA: add arm64 kubevirt and nvidia-jp7 build/publish coverage#5907
Conversation
ade6482 to
88013ae
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #5907 +/- ##
==========================================
+ Coverage 20.64% 21.07% +0.42%
==========================================
Files 489 499 +10
Lines 90373 92071 +1698
==========================================
+ Hits 18656 19401 +745
- Misses 70138 70911 +773
- Partials 1579 1759 +180 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@rene @eriknordmark this is ready to merge |
eriknordmark
left a comment
There was a problem hiding this comment.
Let's try it in master.
eriknordmark
left a comment
There was a problem hiding this comment.
Where are we using EXTERNAL_BOOT_IMAGE_TAG? grep -r doesn't find it.
I think we had something like this in eve-k/kubevirt earlier but that it was removed.
Mirror the staged job structure of build.yml. The previous workflow ran
a single matrix job per arch/hv/platform that rebuilt all base packages
from scratch on every entry. The new structure has three explicit
stages:
Stage 1 (pkgs-amd64, pkgs-arm64): build and push the generic package
set once per architecture.
Stage 2 (eve): one matrix entry per arch/hv/platform variant. Each
pulls the generic packages from the registry and only rebuilds the
HV/platform-specific delta on top, then builds the EVE image.
Stage 3 (manifest, trigger_assets): multi-arch manifests and release
assets.
Add nvidia-jp7 (kvm and k) to the eve matrix.
Collapse the separate 'build' and 'push' steps into single
LINUXKIT_PKG_TARGET=push calls. Linuxkit's push target checks the
registry first and skips images already pushed, so retrying after a
mid-pipeline failure does not rebuild already-published packages.
Drop the pull-only Docker Hub login. Pulls now go through a
pull-through mirror that handles authentication transparently, so a
single release login per job is sufficient.
Signed-off-by: Paul Gaiduk <paulg@zededa.com>
Add four new eve build jobs for arm64: - eve-arm64-k-generic - eve-arm64-k-nvidia-jp6 - eve-arm64-k-nvidia-jp7 - eve-arm64-kvm-nvidia-jp7 All four reuse pkgs-arm64-generic and the linuxkit-cache-arm64-generic artifact, following the existing pattern for arm64 eve jobs. Signed-off-by: Paul Gaiduk <paulg@zededa.com>
publish.yml now builds five additional eve image variants that were not represented in the release-asset matrix: arm64 / nvidia-jp7 / kvm arm64 / generic / k arm64 / nvidia-jp5 / k arm64 / nvidia-jp6 / k arm64 / nvidia-jp7 / k Add them so the release pipeline uploads installer / rootfs / live / sources for these variants alongside the existing ones on tagged builds. Signed-off-by: Paul Gaiduk <paulg@zededa.com>
… errors A partition layout that doesn't fit the pre-sized disk previously surfaced only as a buried sgdisk error several calls deep, with the container exiting silently. Add a pre-flight check using the existing calc_image_size helper, and wrap the make-raw call in runme.sh so the requested size and partition list are reported on failure. Signed-off-by: Paul Gaiduk <paulg@zededa.com>
installer.raw, live.raw, and the eve-sources docker export can exceed GitHub's 2 GiB release asset limit. Compress all three with zstd before upload (typical 5-20x ratio for sparse raw disk images; substantial savings on the sources tar as well). The eve-sources output was named collected_sources.tar.gz but was a raw tar (never gzipped), so rename it to collected_sources.tar and let zstd produce collected_sources.tar.zst. Also rename the surrounding step to reflect that it only exports — publication happens later in the upload step. The upload loop now tracks failures and exits non-zero so a failed upload no longer silently passes the job. Signed-off-by: Paul Gaiduk <paulg@zededa.com>
@eriknordmark sorry, it was a leftover from testing on a fork. I dropped that commit. |
Description
Expands CI coverage for the kubevirt (
HV=k) hypervisor on arm64 and the new nvidia-jp7 (Jetson JetPack 7) platform across both thebuildandpublishworkflows.The PR contains three commits, each described in its own commit message; a quick summary:
publish.yml— restructure into staged jobs that mirror the shape ofbuild.yml. Stage 1 (pkgs-amd64,pkgs-arm64) builds the generic package set once per architecture; stage 2 (eve) pulls these from the registry and only rebuilds the HV/platform-specific delta on top. Adds nvidia-jp7 to the matrix (kvmandk). Collapsesbuild/pushstep pairs into singleLINUXKIT_PKG_TARGET=pushinvocations so retries skip already-pushed images. Drops the pull-only Docker Hub login, since pulls now go through a pull-through mirror that handles authentication transparently.tools/parse-pkgs.sh— addEXTERNAL_BOOT_IMAGE_TAG.pkg/external-boot-imageis required to buildHV=k, so its tag needs to be tracked alongside the other package tags.build.yml— add four new arm64 eve build jobs:eve-arm64-k-generic,eve-arm64-k-nvidia-jp6,eve-arm64-k-nvidia-jp7, andeve-arm64-kvm-nvidia-jp7(the last one for parity withpublish.yml).How to test and validate this PR
The publish workflow was already tested on rene/eve https://github.com/rene/eve/actions/runs/25392062779
All EVE variants got published to the local registy:
Changelog notes
Adds CI build and publish coverage for the nvidia-jp7 (Jetson JetPack 7) platform and for the kubevirt hypervisor variant on arm64. No runtime/user-facing behaviour change beyond the availability of additional published EVE image variants.
PR Backports
Checklist
And the last but not least: