Repository navigation
bootc: stop recurring tmt generated-fmf rebase conflicts #263
Description
Every new tmt test edits the generated tmt/plans/integration.fmf and tmt/tests/tests.fmf at the same spot, so each open test PR conflicts whenever main gains one (most recently bootc-dev/bootc#2516, resolved by regenerating with cargo xtask update-generated direct).
Suggested durable fix: either a .gitattributes merge driver for those two files that re-runs the generator (needs per-clone git config, so a documented just setup step), or stop committing them and generate at build time (just validate then has nothing to check). The second removes the conflict class entirely; propose it upstream.
Generated-by: https://github.com/cgwalters/#llms
Activity
cgwalters-bot commentedon Oct 22, 2026
✅ dispatch ended well. Result: #263 (comment)
cgwalters-bot commentedon Oct 22, 2026
Triage (22 Oct 2026): valid, and already being fixed by bootc-dev/bootc#2581. That PR can't merge yet: one bug in it fails every integration job. cgwalters needs to decide how that fix gets made. Keep this item open until #2581 merges.
Still reproducible on main. On bootc main
de7ae55(17 Oct), all tests are still generated into onetmt/tests/tests.fmf. All plans go between the# BEGIN/END GENERATED PLANSmarkers oftmt/plans/integration.fmf(crates/xtask/src/tmt.rs), andjust validatechecks them with--check. So two open test PRs still conflict.The issue's "stop committing them" option doesn't work. Packit/Testing Farm run
tmt_plan: /tmt/plans/integrationstraight from the checked-out tree (.packit.yamlL98, L120), and nothing generates the files before they read them. The merge-driver option needs config in every clone. #2581 takes a better route: it generates one file per test (tmt/tests/tests/test-<name>.fmf) and one per plan (tmt/plans/integration/plan-<name>.fmf), and drops the test numbers. A new test then only adds files, so there is nothing to conflict.Why #2581 is red. All 15
test-integrationjobs on head2acec749fail in run 39307240799, and they fail the same way. The/plan-soft-rebootrun picks up two extra pieces of work. Its discover step also findstest-soft-reboot-selinux-policy, and the whole/plan-soft-reboot-selinux-policyplan runs in the same VM, which then fails withExpected staged deployment to exist(e.g. this job). The cause is a name clash. run-tmt callstmt ... plan --name {plan}(tmt.rs L705 on the PR head), and tmt reads--nameas a regex. The generateddiscover: test:lists are matched the same way. Without the two-digit numbers,plan-soft-reboot/test-soft-rebootare prefixes of the-selinux-policynames. The fix is small: anchor both (^...$, with the name regex-escaped) in run-tmt and in the generated plan files. Optionally,--checkcould also reject a name that is a prefix of another. Test withjust validateandjust test-tmt soft-reboot; the CI integration matrix should go green.Decision for cgwalters: how should that fix land on #2581?
dispatch.tomlL7), so a plan can't target #2581 directly.I recommend (A). Once #2581 merges, close this item as completed.
Generated-by: https://github.com/cgwalters/#llms