-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move the verify-libraries CI check into releng #5779
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @iliana!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
@@ -3,7 +3,6 @@ | |||
#: name = "a4x2-deploy" | |||
#: variety = "basic" | |||
#: target = "lab-2.0-opte-0.27" | |||
#: rust_toolchain = "stable" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the other a4x2 job uses a specific toolchain version in lieu of stable. Did you intend to delete this and pin to 1.77.2, like a4x2-prepare.sh
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a4x2-deploy is similar to the deploy job in that neither needs a Rust toolchain, because they're both targeting lab environments where the ramdisk image does not contain any compilers. (Both these jobs get all their artifacts compiled on a job with a non-lab target.)
(This is merely a cleanup that is tangential to the purpose of this PR, but should get done anyway.)
In the context of the build-and-test job,
cargo xtask verify-libraries
is a bit of an unrelated operation, because it's building all of the binaries in between building all of the test binaries and then running all of the test binaries.I had initially considered moving it to its own Buildomat job, but then realized that this is really a release engineering check; we already have built most of the binaries (in particular, Nexus, the one that takes the longest to build) in order to package them up, so we can manage to build the handful of extra utility binaries and perform the checks while the host OS image builds.
This should improve the build-and-test (helios) job by about 10 minutes while having negligible impact on the tuf-repo job, and will also eliminate a new and exciting source of test flake we've seen where
timeout 10m
is getting hit, presumably because we continue to write software.