test: grow the integration scenario set#43
Merged
Conversation
…nario The extra_hosts check compared against "hostname:ip" (podman's --add-host FLAG syntax), but /etc/hosts itself is written "ip<whitespace>hostname" -- the check never could have matched. Confirmed via a CI diagnostic run that dns/sysctls/extra_hosts all land on podman pod create correctly; only this scenario's own assertion was wrong.
lesnik512
force-pushed
the
test/grow-integration-scenarios
branch
from
9d6eff5 to
881c98b
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
Grows the podman integration harness (from #41) with three more behavioral scenarios, per the design in
planning/changes/2026-07-13.02-grow-integration-scenarios.md. No harness,conftest.py,pyproject.toml, or CI config changes -- each scenario is a new file reusing the existingrun_podfixture.dns/sysctls/extra_hosts-- the exact area that broke in test: CI-only podman integration harness #41 (podman rejecting--add-hostonpodman runfor pod members). One service declares all three; its own command checks/etc/resolv.conf,/proc/sys/net/core/somaxconn, and/etc/hostsfor the expected entries, proving all three land onpodman pod create, not the container.secrets/configs-- both compile topodman secret createunder the hood. One service references a file-sourced secret and a content-sourced config, exercising both source kinds and both default mount paths (/run/secrets/<name>and/<name>).deploy.resources.limits(memory/cpus/pids) is acceptance-only (if podman rejected any of these flags -- the add-host bug's failure class -- the script would fail to start), whileulimitsis value-checked via theulimit -nshell builtin (cgroup-independent, reliable on any runner). Verifying exact memory/pids values would require reading cgroup files and assume a specific cgroup hierarchy on the CI runner -- deferred as a documented risk trade-off.Verification
just test-ciat 100% (363 passed, 6 deselected);just lint-ciandjust check-planningclean. All three scenarios usebusybox:1.36, already cached from the existing seed scenarios, so no new image-pull risk. Behavioral green is produced by the existingintegrationCI job.