tests: Add bootc end-to-end validation test #126
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reviewer's GuideIntegrates bootc end-to-end validation into CI by adding a dedicated test playbook, gating role execution with a new flag, disabling tuning in buildah containers, and updating GitHub workflows for tox-lsr 3.10.0 and Podman 5.x support. Sequence Diagram for Bootc End-to-End Validation TestsequenceDiagram
participant CI as GitHub Actions
participant Playbook as tests_bootc_e2e.yml
participant Builder as bootc-image-builder
participant TargetEnv as QEMU VM / Deployed Image
CI->>Playbook: Trigger bootc E2E test
Playbook->>Playbook: Prepare environment (e.g., Podman 5.x)
Playbook->>Builder: Build bootc image
Builder-->>Playbook: Image built
Playbook->>TargetEnv: Deploy/Run image
Playbook->>TargetEnv: Validate deployed image
TargetEnv-->>Playbook: Validation results
Playbook->>CI: Report test status (pass/fail)
Flow Diagram for
|
| Change | Details | Files |
|---|---|---|
| Introduce __run_role flag to optionally skip role execution in validation tasks |
|
d(true) |
| Disable server tuning by default in buildah container builds |
|
defaults/main.yml |
| Document buildah-specific tuning behavior in README |
|
README.md |
| Add new bootc end-to-end test playbook |
|
tests/tests_bootc_e2e.yml |
| Bump tox-lsr dependency to v3.10.0 in CI workflows |
|
.github/workflows/ansible-lint.yml.github/workflows/ansible-managed-var-comment.yml.github/workflows/ansible-test.yml.github/workflows/qemu-kvm-integration-tests.yml |
| Enhance QEMU CI for Podman 5.x compatibility and bootc validation |
|
.github/workflows/qemu-kvm-integration-tests.yml |
Tips and commands
Interacting with Sourcery
- Trigger a new review: Comment
@sourcery-ai reviewon the pull request. - Continue discussions: Reply directly to Sourcery's review comments.
- Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it. You can also reply to a
review comment with@sourcery-ai issueto create an issue from it. - Generate a pull request title: Write
@sourcery-aianywhere in the pull
request title to generate a title at any time. You can also comment
@sourcery-ai titleon the pull request to (re-)generate the title at any time. - Generate a pull request summary: Write
@sourcery-ai summaryanywhere in
the pull request body to generate a PR summary at any time exactly where you
want it. You can also comment@sourcery-ai summaryon the pull request to
(re-)generate the summary at any time. - Generate reviewer's guide: Comment
@sourcery-ai guideon the pull
request to (re-)generate the reviewer's guide at any time. - Resolve all Sourcery comments: Comment
@sourcery-ai resolveon the
pull request to resolve all Sourcery comments. Useful if you've already
addressed all the comments and don't want to see them anymore. - Dismiss all Sourcery reviews: Comment
@sourcery-ai dismisson the pull
request to dismiss all existing Sourcery reviews. Especially useful if you
want to start fresh with a new review - don't forget to comment
@sourcery-ai reviewto trigger a new review!
Customizing Your Experience
Access your dashboard to:
- Enable or disable review features such as the Sourcery-generated pull request
summary, the reviewer's guide, and others. - Change the review language.
- Add, remove or edit custom review instructions.
- Adjust other review settings.
Getting Help
- Contact our support team for questions or feedback.
- Visit our documentation for detailed guides and information.
- Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @martinpitt - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Review instructions: all looks good
- 🟢 Testing: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Contributor
Author
|
That first version fails as expected, already noticed in https://issues.redhat.com/browse/RHEL-88396: When running the role during a container build, the |
martinpitt
force-pushed
the
qemu-bootc
branch
3 times, most recently
from
101b9fe to
272e0f4
Compare
There was a problem hiding this comment.
Hey @martinpitt - I've reviewed your changes - here's some feedback:
- Consolidate the repeated tox-lsr installation steps across workflows into a shared template or composite action to reduce duplication and maintenance overhead.
- Define sensible defaults for the __run_role and __bootc_validation variables in role defaults or a common vars file so tests have predictable behavior and avoid false negatives.
- Add a clear TODO or expiration note around the ‘plucky’ Podman pinning hack, so it’s removed once Ubuntu 26.04 LTS is in place and the workaround is no longer needed.
Here's what I looked at during the review
- 🟡 General issues: 1 issue found
- 🟢 Security: all looks good
- 🟢 Review instructions: all looks good
- 🟢 Testing: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
richm
reviewed
Jun 3, 2025
| changed_when: true | ||
|
|
||
| - name: Validation of deployed image | ||
| when: ansible_connection | d("") != "buildah" |
Contributor
There was a problem hiding this comment.
Under what conditions can ansible_connection be undefined? Because above you reference it without the | d() in postgresql_server_tuning: "{{ false if ansible_connection == 'buildah' else true }}" ?
Contributor
Author
There was a problem hiding this comment.
ansible_connection is undefined for QEMU runs, i.e. when not using an external connection plugin.
Without the | d() it fails like this:
TASK [Flush handlers] ******************************************************************************************************************
task path: /var/home/martin/upstream/lsr/postgresql/tests/tasks/install_and_check.yml:11
Tuesday 03 June 2025 18:48:02 +0200 (0:00:00.017) 0:00:00.082 **********
ERROR! The conditional check 'ansible_connection != "buildah"' failed. The error was: error while evaluating conditional (ansible_connection != "buildah"): 'ansible_connection' is undefined. 'ansible_connection' is undefined
The error appears to be in '/var/home/martin/upstream/lsr/postgresql/tests/tasks/install_and_check.yml': line 11, column 7, but may
be elsewhere in the file depending on the exact syntax problem.
Apparently Ansible gets along with testing for equality == against an undefined value, but not with !=. However, that's confusing, and I applied the default everywhere now for consistency.
Contributor
There was a problem hiding this comment.
ansible_connectionis undefined for QEMU runs, i.e. when not using an external connection plugin.
That's really strange. I cannot reproduce this behavior. No matter what I try, I get "ansible_connection": "ssh" unless I explicitly specify another connection type.
Without the
| d()it fails like this:TASK [Flush handlers] ****************************************************************************************************************** task path: /var/home/martin/upstream/lsr/postgresql/tests/tasks/install_and_check.yml:11 Tuesday 03 June 2025 18:48:02 +0200 (0:00:00.017) 0:00:00.082 ********** ERROR! The conditional check 'ansible_connection != "buildah"' failed. The error was: error while evaluating conditional (ansible_connection != "buildah"): 'ansible_connection' is undefined. 'ansible_connection' is undefined The error appears to be in '/var/home/martin/upstream/lsr/postgresql/tests/tasks/install_and_check.yml': line 11, column 7, but may be elsewhere in the file depending on the exact syntax problem.
Can you provide your exact tox command line?
Apparently Ansible gets along with testing for equality
==against an undefined value, but not with!=.
That is even stranger.
However, that's confusing, and I applied the default everywhere now for consistency.
Contributor
Author
There was a problem hiding this comment.
Prep (works):
LSR_CONTAINER_PROFILE=false LSR_CONTAINER_PRETTY=false tox -e container-ansible-core-2.16 -- --image-name centos-9-bootc tests/tests_bootc_e2e.yml
Validate:
tox -e qemu-ansible-core-2.16 -- --image-file `pwd`/tests/tmp/tests_bootc_e2e/qcow2/disk.qcow2 --log-level=debug -e __bootc_validation=true -- tests/tests_bootc_e2e.yml
Perhaps you forgot the -e __bootc_validation=true?
Contributor
There was a problem hiding this comment.
The variable reference is in a handler - code run in handlers is in a strange variable namespace - I have seen cases where vars defined in the playbook are not available in the handler - but this one doesn't make any sense - if I put a debug var: ansible_connection at the beginning of the playbook, it prints the value - I have no idea why it would be removed before the handler is run - I'll chalk this up to a bug in ansible that we have to workaround.
martinpitt
force-pushed
the
qemu-bootc
branch
2 times, most recently
from
397646d to
7e74d99
Compare
richm
approved these changes
Jun 3, 2025
Contributor
Author
|
The prep commits landed in the meantime in #127, so rebasing. |
Cause: Detecting available RAM and basing the shared memory settings of the server on that is futile and wrong during a container image build. The available RAM during that build is independent of the actual runtime, be that a bootc deployment or a system container. Consequence: postgresql.service failed to start when the available RAM during container build was higher than at deployment time. In the opposite case, the shared memory tuning was too small and thus also wrong. Fix: Disable `postgresql_server_tuning` by default for container builds, i.e. when being connected to a buildah instance.
Add a knob to tests/tasks/install_and_check.yml to skip the role run, as we don't want to do this during validation. Skip the memory tuning checks for bootc validation, as running the role during a container build disables the automatic tuning.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a knob to tests/tasks/install_and_check.yml to skip the role run, as we don't want to do this during validation.
This uses a new test, as e.g. tests/tests_default.yml are already just wrappers
around task includes, and modifying them would be messier and harder to
understand than a new test.
The other commits are identical to linux-system-roles/sudo#59 and linux-system-roles/.github#114 .
Summary by Sourcery
Add support for end-to-end validation of bootc container images via QEMU and update related CI, defaults, and test logic to accommodate bootc scenarios
New Features:
__run_roleflag to skip role execution during validation runsEnhancements:
__run_roleand skip tuning checks under bootc validationCI:
Documentation:
Tests:
tests/tests_bootc_e2e.ymlfor bootc validation