Add initial tmt test plan

[archanaserver]

No description provided.

[adamruzicka]

Could we put all those files being added here into a single directory rather than having them scattered over the repo root, .fmf, plans and tests or is the current structure dictated by tmt?

[adamruzicka]

Can this be rhel-9? Alternatively we'll probably need to set up additional repos here

[archanaserver]

Can you be more descriptive please I might not get it?

[adamruzicka]

The previous build failed with this - apparently it tried to build the rpm without having access to the other repositories we supply for the copr_build job.

No matching package to install: 'foreman-assets >= 3.15'
No matching package to install: 'foreman-plugin >= 3.15'
No matching package to install: 'npm(@theforeman/builder) >= 15.0.1'
No matching package to install: 'rubygem(deface)'
No matching package to install: 'rubygem(foreman-tasks) >= 8.3.0'

With the rhel-9 thing, I was hoping that if we used the same target for both of those jobs, things would sort themselves out, but apparently that is not an available target on testing farm, so I'm sorry for that. So back to epel-9 and we'll see where it takes us

[adamruzicka]

Now we're back where we were, would something like this change anything?

Suggested change

	- epel-9
	epel-9:
	additional_modules: "foreman-devel:el9"
	additional_repos:
	- https://yum.theforeman.org/releases/nightly/el9/x86_64/
	- https://yum.theforeman.org/plugins/nightly/el9/x86_64/

[archanaserver]

i guess this is what i saw missing, trying it for now...

[adamruzicka]

968e68d this seems to be the way forward. It will at least allow the test job to be triggered in testing farm

[archanaserver]

Could we put all those files being added here into a single directory rather than having them scattered over the repo root, .fmf, plans and tests or is the current structure dictated by tmt?

Thanks for the review @adamruzicka and for pointing this out!
I initially followed the scattered layout based on some earlier references and examples. That said, I’ve tried to re-structure it this way to clearly separate host-side orchestration (via hammer) from guest-side testing, which helps avoid some common pitfalls I believe when integrating TMT with Foreman.

[packit-as-a-service]

Failed to load packit config file:

Cannot parse package config. ValidationError({'jobs': {1: {'packages': defaultdict(<class 'dict'>, {'rubygem-foreman_remote_execution': {'value': {'targets': ["Expected 'list[str]' or 'dict[str,dict]', got [{'epel-9': None}] (type <class 'list'>)."]}}})}}})

For more info, please check out the documentation or contact the Packit team. You can also use our CLI command config validate or our pre-commit hooks for validation of the configuration.

[archanaserver]

@adamruzicka i see some failures, could you help me understand if these are expected issues because of this changes?

[adamruzicka]

The failures in unit tests through github actions are unrelated to the changes proposed here.

The testing-farm failure however, is related. If I'm reading it right, then packit builds a package, then testing farm spins up a standard centos9stream machine and tries to install the packit-built rpm there, but since this is a foreman plugin, the rpm cannot be installed on its own.

[evgeni]

prepare:
    how: install
    package:
      - https://yum.theforeman.org/releases/nightly/el9/x86_64/foreman-release.rpm

should setup enough repos to make things install fine

[archanaserver]

The plan on this is unclear right now, so moving it to draft for now.