Add tmt tests for simple smoke tests

[LecrisUT]

Pull Request Description

Followup to #7910 (comment), this adds the basic framework for testing-farm tests. Right now these are quite simple, just trying to compile some of the hello-world examples and checking the exit code. For more complex checks like grepping the output, beakerlib could be used, or any preferred scripting language.

Here's a bit of quick reference for how you can run some quick introspection and tests locally (after getting tmt installed in your preferred method):

• tmt (plans|tests) show: does quick validation and shows the content of the .fmf files with all inheritance, merge etc resolved
• tmt run -a provision --how=container: run the plan (basically collection of tests) locally with the mpich version in the repos
• tmt run -a provision --how=container --image fedora:44 prepare --insert --how=artifact --provide=copr.build:10808121:fedora-44-x86_64 --order=40: same as before, but now use the rpms from copr build 10808121 (and chroot fedora-44-x86_64, matching the requested container)

Author Checklist

• Provide Description
  Particularly focus on why, not what. Reference background, issues, test failures, xfail entries, etc.
• Commits Follow Good Practice
  Commits are self-contained and do not do two things at once.
  Commit message is of the form: module: short description
  Commit message explains what's in the commit.
• Passes All Tests
  Whitespace checker. Warnings test. Additional tests via comments.
• Contribution Agreement
  For non-Argonne authors, check contribution agreement.
  If necessary, request an explicit comment from your companies PR approval manager.

[LecrisUT]

/packit test

[Growl1234]

Could we make tmt also triggered automatically with commit, as the PR test is manually triggered?

[hzhou]

@LecrisUT Please sign http://www.mpich.org/documentation/contributor-docs/ and send it to cla@lists.mpich.org

[LecrisUT]

Could we make tmt also triggered automatically with commit, as the PR test is manually triggered?

Only with labels, otherwise it will always show it as pending. There are 3 options:

• run on all commits (golden path). With the builds taking at most 20min, it is fine
• run when a github label is set (I think it doesn't listen to label change events)
• run when /packit ... comment is given

[Growl1234]

I mean to make it act the same as packit building CI, to automatically work on push to main branch 🤔

[LecrisUT]

I mean to make it act the same as packit building CI, to automatically work on push to main branch 🤔

Ah sure, I usually don't do that to avoid duplication, but in this case it may make sense because otherwise they might not be run at all. Just do not want to repeat the design decisions in cp2k that had the jobs failing for a whole release cycle