Add tmt integration plan

[LecrisUT]

See:

• Propose podman friends integration plan in relevant repos teemtee/tmt#4047
• Add plan and test for container tools integration testing teemtee/tmt#4026
• Add tmt integration plan container-selinux#410
• Add tmt integration plan podman#27140

An alternative design is to add the tests in .packit.yaml. Let me know which approach would be preferred. I don't quite follow the steps you do with podman-next*.repo, maybe we could look into that as well?

(should use only one PR where we discuss and test these)

Summary by Sourcery

New Features:

• Add a new FMF plan file for tmt-based integration testing

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Introduce a new TMT-based integration test plan by adding a dedicated FMF configuration under plans/tmt.fmf, enabling standardized discovery and execution of integration tests for container-selinux.

File-Level Changes

Change	Details	Files
Add a new FMF-based integration testing plan using tmt	Create plans/tmt.fmf with FMF metadata (summary, tags, url) Configure test discovery to use tmt run Define execution steps to invoke tmt with required environment Specify reporting and cleanup actions within the plan	plans/tmt.fmf

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on 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 issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on 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 dismiss on 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 review to 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]

Hey there - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[flouthoc]

@lsm5 PTAL

[lsm5]

I don't quite follow the steps you do with podman-next*.repo, maybe we could look into that as well?

In .packit.yaml we add the podman-next repo and in the TMT plan we bump the priority so that podman and other packages will be fetched from podman-next copr instead of testing-farm-tag repository.

[lsm5]

An alternative design is to add the tests in .packit.yaml. Let me know which approach would be preferred.

I think the current setup is fine given the TMT tests finish in a matter of seconds IIUC, and assuming they won't flake.

[lsm5]

LGTM. This should help catch any potential breakages crun could cause on tmt.

I'll defer to @giuseppe and @flouthoc .

[LecrisUT]

I don't quite follow the steps you do with podman-next*.repo, maybe we could look into that as well?

In .packit.yaml we add the podman-next repo and in the TMT plan we bump the priority so that podman and other packages will be fetched from podman-next copr instead of testing-farm-tag repository.

Hmm, I don't think we set any special repo priority, but it sounds like you want install.exclude and remove the testing-farm created repo? Anyway with the imported plans it could be dubious because you cannot inject those steps arbitrarily, so let's check that all is as expected on that front

[lsm5]

Hmm, I don't think we set any special repo priority, but it sounds like you want install.exclude and remove the testing-farm created repo? Anyway with the imported plans it could be dubious because you cannot inject those steps arbitrarily, so let's check that all is as expected on that front

There's the recent TMT RFE about better install tracking. Would that help toward this? Ideally, I'd prefer no priorities / equal priorities on all repos and let the user deal with it.

[lsm5]

Hmm, I don't think we set any special repo priority, but it sounds like you want install.exclude and remove the testing-farm created repo? Anyway with the imported plans it could be dubious because you cannot inject those steps arbitrarily, so let's check that all is as expected on that front

By default I've noticed testing-farm envs fetch packages from testing-farm tag repo even after a copr was enabled. I don't know if that's still the case.

[LecrisUT]

By default I've noticed testing-farm envs fetch packages from testing-farm tag repo even after a copr was enabled. I don't know if that's still the case.

Still the case, but if you overwrite the artifacts completely, it should only do the copr enablement. Looking at the request, the original build artifacts are still there. I think you had a RFE on packit to allow to overwrite this? I will make a quick PR if you can point me to the design requirement you had in mind.

There's the recent TMT RFE about better install tracking. Would that help toward this? Ideally, I'd prefer no priorities / equal priorities on all repos and let the user deal with it.

Indeed there is, but I think with the design you have in mind for this, it is more on packit side to allow for the case above, and it should be possible in the current implementation. Specifically, we should be able to do this directly from testing-farm-cli and just strip out the rpm artifacts from the request above. Just need a second pair of eyes to check that everything is as intended.