New Ansible based Github Workflow

[jhoyt4]

This is an attempt to update the workflow to
use ansible as the "one source of truth"
for build requirements.

Any new build requirements will need to
be added to ansible (ideally before the
commit to master requiring the new build
requirements).

In theory, the workflows will need little
to no changes when the distros update
their versions, as we use the docker
tags for latest/current for the Linux
distros and macports port names for macOS.

Fedora was selected for the Qt6, Clang,
and CMake builds because Fedora
typically has the "latest/greatest" which
makes things more likely to identify issues.
If there is a desire to use Ubuntu or Debian
(or some other distro) that adjustment can
be made.

macOS was migrated to macports to allow for
better testing of all features as well as an
attempt to increase the stabiity of the CI
chain when the upstream package management
developers shift versions of python, mysql,
and qt.

Thank you for considering this PR.

This PR is a collaboration between @garybuhrmaster and @jhoyt4. Gary has been instrumental in getting the main flow and linux pieces working. John just hacked around as usual with macOS :)

Checklist

• contribution does not duplicate one of our existing pull requests
• contribution is in a branch rebased against master
• code compiles successfully without errors
• code follows the MythTV Coding Standards
• documentation added/updated/removed where necessary
• commits are logically organised and have good commit messages

[jhoyt4]

@garybuhrmaster - Please review and suggest changes where you feel they'd be appropriate.

[jhoyt4]

I'm not quite sure what Fedora cmake failed. It's been consistently passing up until now.

[garybuhrmaster]

I'm not quite sure what Fedora cmake failed. It's been consistently passing up until now.

I'll try to take a look at it this weekend. I do know (from past "experience" (that means surprise and confusion)) that PR's that add/delete/update the workflow itself tend to generate "interesting" results, and once committed the issues are no longer seen. Some of those issues I understand, and some I do not.

[garybuhrmaster]

I'm not quite sure what Fedora cmake failed. It's been consistently passing up until now.

I'll try to take a look at it this weekend.

The issue is CMake cannot determine the proper version history from the repo using git, and the fallback was not entirely usable.

I am not sure this will fix the issue for PR's (testing that is a bit complicated), but to make CMake happier, one needs to add

fetch-depth: 0

after line 255 to the MythTV repo checkout (in the with: section) to obtain the full history which CMake uses. Let's try that and see if that is adequate to fix the issue for both normal pushes, and PRs (PR's are always tricky, as the ref is not in a more common form).

[jhoyt4]

Thanks Gary - I just pushed your suggested fix. I'll squash everything assuming a successful CI run - which will provide the bonus advantage of another CI run to confirm everything is ready.

[jhoyt4]

no joy on cmake

[garybuhrmaster]

no joy on cmake

I was afraid that that was not going to be sufficient, although the fetch-depth: 0 addressed a different issue.

The failure is due to there being no current branch for a PR. And the CMake functions as written need one (and don't understand an empty branch). I'll continue working the issue later.

[garybuhrmaster]

The failure is due to there being no current branch for a PR. And the CMake functions as written need one (and don't understand an empty branch). I'll continue working the issue later.

Fixes are proposed in #877 that will address this. I presume David H will need to carefully review the proposal.