Create a GHA reusable workflow rather than cloning the gha dist everywhere

[aspark21]

Every time there are changes to the gha.dist.yml we have to copy it across 50 repos and reconcile the repo specific config (matrix, additional plugins) with the template. It's quite a faff to have to keep doing https://github.com/moodlehq/moodle-plugin-ci/blob/main/gha.dist.yml

I wonder wether we could move this around so there is a github actions reusable workflow in the moodle-plugin-ci repo that is kept up to date within here, and in our plugin repos we can just call this reusable workflow, while having the matrix & additional plugins specifically setup thus effortlessly always keeping up to date with all of the improvements to moodle-plugin-ci

Happy to work on it if there is appetite for a pull request.

[kabalin]

Hi @aspark21, that is great suggestion. It would be good to have it as GH action, so PR is welcomed :)

For inspiration, this is a snippet by @andrewnicols outlining how this may look like:

- name: Plugin CI Checks
  uses: moodlehq/moodle-plugin-ci@v3
  with:
    moodle-branch: ${{ matrix.moodle-branch }}
    DB: ${{ matrix.database }}
    # All tests are run by default unless otherwise specified, for example:
    lint: false
    # Or arguments may be specified, for example:
    phpmd:
      args: --max-warnings 0
    behat:
      profile: chrome
      suite: classic

[stronk7]

Just noting that, if we go the GH Action (vs reusable workflow) way, there is also #53, created long ago.

[fulldecent]

An important part of having evergreen, reusable, set-it-once-and-forget-it GitHub Actions CI testing is having a MOODLE_STABLE branch in the official Moodle repository that is updated every time a major release of Moodle happens (and running with a GitHub Actions "cron" job.)

This means new versions of Moodle will trigger your all your code to test against it... while you are sleeping. Wouldn't that be great?

Here is the issue in the Moodle project tracker to do just that.

[andrewnicols]

@fulldecent, once again this is not a good approach to solving this issue.

The correct solution here is to create a reusable workflow -- something that is already on our backlog. A moving branch is actually quite unhelpful for most of our plugin developers and it's actively dangerous for any site inadvertently using it.

[fulldecent]

It is helpful to test against new upstream releases. And this is best practice.

Not testing against new upstream releases means that when I want to upgrade my Moodle 4.4 to 4.5, I need to open issues on over a dozen plugin repositories and then wait.

This is the current sorry state of affairs for me trying to upgrade Moodle 4.4 to 4.5, which (lol) is not even the latest release 5.0.