HMS-3162: tests: add basic integration testing

[mvo5]

This commit adds basic integration testing for the project. It is pytest based and can run both locally or via tmt [0] which will spin up a clean VM and run the tests inside.

See https://github.com/osbuild/osbuild-deploy-container/compare/main...mvo5:tmt-smoke?expand=1#diff-5de36acd90308dc62abf7855a686ee7052ffb6e762c756fd735fb0c9fbd9595dR1 (tests/README.md) for a very basic description.

There are still some TODOs that need addressing (here or in followups):

• integrate with tmt/testing farm so that this (also) run in a fedora VM
• boot the generated VM and test it, code for this already exists https://github.com/osbuild/osbuild-deploy-container/compare/main...mvo5:integration-test?expand=1 - maybe best as a followup?
• selinux denails checks (need HMS-3141: image: add new ContainerBuildable flag to OSTreeDiskImage images#287)
• Run on MacOS

I personally think that as it is it is already useful and we could merge and iterate but I'm equally happy to flesh it out more. It will already do a container build/run/validate that something got generated.

[0] https://github.com/teemtee/tmt

[achilleas-k]

I clicked the rebase button. The linter was failing because the branch was from before the repo and package rename so it was failing.

[ochosi]

@mvo5 Just fyi, I changed to PR title because the Jira reference needs to be a prefix for the automation to pick it up and link it.

[mvo5]

@mvo5 Just fyi, I changed to PR title because the Jira reference needs to be a prefix for the automation to pick it up and link it.

Thanks @ochosi ! Maybe it's just me (or me just not being used to this) but I wonder if we could change the automation to look at the end? I find it aesthetically more pleasing to keep the existing form of <subsystem>: what changed and just make that <subsystem>: what changed (JIRA-xxxx). Similar patterns are used e.g. in debian changelogs when bugs are closed (there its technically free form but the convention is that it's at the end). No super strong opinion though just an wondering because now it's early enough to tweak what we do :)

[ochosi]

@mvo5 Just fyi, I changed to PR title because the Jira reference needs to be a prefix for the automation to pick it up and link it.

Thanks @ochosi ! Maybe it's just me (or me just not being used to this) but I wonder if we could change the automation to look at the end? I find it aesthetically more pleasing to keep the existing form of <subsystem>: what changed and just make that <subsystem>: what changed (JIRA-xxxx). Similar patterns are used e.g. in debian changelogs when bugs are closed (there its technically free form but the convention is that it's at the end). No super strong opinion though just an wondering because now it's early enough to tweak what we do :)

I wholeheartedly agree, but it seems this is hardcoded in Jira's DVCS plugin, so there's little we can do about it.

[ondrejbudai]

Amazing, thanks!

Addressed.