Add an "upgrade from previous" test#2060
Conversation
We have tests that do upgrades, but they start from the *new* bootc. Add a `just`+CI workflow that starts from a stable shipped image (we just need to inject tmt deps + nu). The readonly test then gains a helper which optionally performs an upgrade to the new target. IOW the flow is - deploy stock image with unmodified bootc etc - upgrade - run readonly tests It could of course make sense to run *all* of the tests this way as an optional thing, nothing blocks that, but it would be *another* entry in our matrix and we're going to need to figure out how to wrangle that matrix size. Also do to that we'd need to abstract over TMT_REBOOT_COUNT. Assisted-by: OpenCode (Claude claude-opus-4-6) Signed-off-by: Colin Walters <walters@verbum.org>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a new test for upgrading from a previously shipped image, which is a valuable addition to the test suite. The implementation is mostly solid, introducing a new Justfile target, a Dockerfile for the source image, and nushell test logic. I've found one potential bug in the test verification logic within a nushell script and provided a suggestion to fix it.
| assert equal $booted.image.transport "containers-storage" | ||
| assert equal $booted.image.image $upgrade_image |
There was a problem hiding this comment.
The way you're accessing the fields from the bootc status --json output appears to be incorrect. After let booted = $st.status.booted.image, the $booted variable should hold a record with transport and image fields. Therefore, you should access them directly as $booted.transport and $booted.image, not $booted.image.transport and $booted.image.image.
assert equal $booted.transport "containers-storage"
assert equal $booted.image $upgrade_image
1 participant
We have tests that do upgrades, but they start from the new bootc. Add a
just+CI workflow that starts from a stable shipped image (we just need to inject tmt deps + nu).The readonly test then gains a helper which optionally performs an upgrade to the new target.
IOW the flow is
It could of course make sense to run all of the tests this way as an optional thing, nothing blocks that, but it would be another entry in our matrix and we're going to need to figure out how to wrangle that matrix size.
Also do to that we'd need to abstract over TMT_REBOOT_COUNT.
Assisted-by: OpenCode (Claude claude-opus-4-6)