Skip to content

devtool: Fix get_newest_s3_artifacts() selecting incomplete revisions - #6173

Open
ilstam wants to merge 1 commit into
firecracker-microvm:mainfrom
ilstam:fix-newest-s3-artifacts
Open

ilstam wants to merge 1 commit into
firecracker-microvm:mainfrom
ilstam:fix-newest-s3-artifacts

Conversation

@ilstam

@ilstam ilstam commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

A revision of the CI artifacts is uploaded one architecture at a time, and within an architecture the kernels land before the rootfs. The old code picked a revision by finding the newest object whose key contained "vmlinux" across all architectures, and download_ci_artifacts() then appended the host architecture to it and synced. So as soon as the aarch64 half of a new revision appeared, x86_64 jobs selected that revision too, synced an empty directory, and setup-ci-artifacts.sh died globbing *.squashfs.

Filtering by architecture alone would not be enough, because a revision whose kernels have uploaded but whose rootfs has not would pass such a check and still leave the glob empty.

Require a rootfs for both architectures before accepting a revision. Until a new revision has fully uploaded, every job keeps using the previous one, so a CI run tests against the same artifacts no matter which host each job lands on. Fail loudly if no revision qualifies, instead of returning a path that cannot be used.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkbuild --all to verify that the PR passes
    build checks on all supported architectures.
  • I have run tools/devtool checkstyle to verify that the PR passes the
    automated style checks.
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md.
  • If a specific issue led to this PR, this PR closes the issue.
  • When making API changes, I have followed the
    Runbook for Firecracker API changes.
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests.
  • I have linked an issue to every new TODO.

  • This functionality cannot be added in rust-vmm.

A revision of the CI artifacts is uploaded one architecture at a time,
and within an architecture the kernels land before the rootfs. The old
code picked a revision by finding the newest object whose key contained
"vmlinux" across all architectures, and download_ci_artifacts() then
appended the host architecture to it and synced. So as soon as the
aarch64 half of a new revision appeared, x86_64 jobs selected that
revision too, synced an empty directory, and setup-ci-artifacts.sh died
globbing *.squashfs.

Filtering by architecture alone would not be enough, because a revision
whose kernels have uploaded but whose rootfs has not would pass such a
check and still leave the glob empty.

Require a rootfs for both architectures before accepting a revision.
Until a new revision has fully uploaded, every job keeps using the
previous one, so a CI run tests against the same artifacts no matter
which host each job lands on. Fail loudly if no revision qualifies,
instead of returning a path that cannot be used.

Signed-off-by: Ilias Stamatis <ilstam@amazon.com>
@ilstam
ilstam force-pushed the fix-newest-s3-artifacts branch from 65a90db to 44fd9cf Compare September 1, 2026 13:49
@ilstam ilstam changed the title tools: Fix get_newest_s3_artifacts() selecting incomplete revisions devtool: Fix get_newest_s3_artifacts() selecting incomplete revisions Sep 1, 2026
@codecov

codecov Bot commented Sep 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.06%. Comparing base (3522ac5) to head (44fd9cf).
⚠️ Report is 34 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #6173   +/-   ##
=======================================
  Coverage   83.06%   83.06%           
=======================================
  Files         277      277           
  Lines       31019    31019           
=======================================
  Hits        25767    25767           
  Misses       5252     5252           
Flag Coverage Δ
5.10-m5n.metal 83.34% <ø> (-0.01%) ⬇️
5.10-m6a.metal 82.70% <ø> (ø)
5.10-m6g.metal 80.18% <ø> (ø)
5.10-m6i.metal 83.34% <ø> (+<0.01%) ⬆️
5.10-m7a.metal-48xl 82.70% <ø> (ø)
5.10-m7g.metal 80.18% <ø> (ø)
5.10-m7i.metal-24xl 83.31% <ø> (ø)
5.10-m7i.metal-48xl 83.32% <ø> (ø)
5.10-m8g.metal-24xl 80.18% <ø> (-0.01%) ⬇️
5.10-m8g.metal-48xl 80.18% <ø> (-0.01%) ⬇️
5.10-m8i.metal-48xl 83.31% <ø> (-0.01%) ⬇️
5.10-m8i.metal-96xl 83.31% <ø> (ø)
5.10-m9g.metal-48xl 80.18% <ø> (ø)
6.1-m5n.metal 83.36% <ø> (-0.01%) ⬇️
6.1-m6a.metal 82.73% <ø> (-0.01%) ⬇️
6.1-m6g.metal 80.18% <ø> (ø)
6.1-m6i.metal 83.36% <ø> (ø)
6.1-m7a.metal-48xl 82.72% <ø> (ø)
6.1-m7g.metal 80.18% <ø> (ø)
6.1-m7i.metal-24xl 83.37% <ø> (-0.01%) ⬇️
6.1-m7i.metal-48xl 83.38% <ø> (+<0.01%) ⬆️
6.1-m8g.metal-24xl 80.18% <ø> (-0.01%) ⬇️
6.1-m8g.metal-48xl 80.18% <ø> (ø)
6.1-m8i.metal-48xl 83.38% <ø> (ø)
6.1-m8i.metal-96xl 83.38% <ø> (-0.01%) ⬇️
6.1-m9g.metal-48xl 80.18% <ø> (ø)
6.18-m5n.metal 83.36% <ø> (ø)
6.18-m6a.metal 82.73% <ø> (ø)
6.18-m6g.metal 80.20% <ø> (-0.01%) ⬇️
6.18-m6i.metal 83.36% <ø> (ø)
6.18-m7a.metal-48xl 82.72% <ø> (ø)
6.18-m7g.metal 80.20% <ø> (ø)
6.18-m7i.metal-24xl 83.38% <ø> (+<0.01%) ⬆️
6.18-m7i.metal-48xl 83.38% <ø> (+<0.01%) ⬆️
6.18-m8g.metal-24xl 80.20% <ø> (ø)
6.18-m8g.metal-48xl 80.20% <ø> (ø)
6.18-m8i.metal-48xl 83.38% <ø> (ø)
6.18-m8i.metal-96xl 83.38% <ø> (ø)
6.18-m9g.metal-48xl 80.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ilstam ilstam added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Awaiting review Indicates that a pull request is ready to be reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant