catalyst / catalyst-moodle-workflows

5 stars 9 forks source link

Releases and CI in one file? #16

Closed keevan closed 2 years ago

keevan commented 2 years ago

Releases are currently in a separate workflow. I was wondering if instead of that, it should be included in a single workflow file, perhaps with dependencies on the tests passing, as well as ensuring it only runs for specific branches instead of well, all the time.

I'm not 100% sure how this might affect things like, not allowing PRs to automatically trigger releases on the custom branch, but lock it down so it's only available on a stable/main branch.

But if those things are covered then it should be better I think. It also reduces the amount of workflows that needs to be run before a release is done (because it won't need to test the code twice after it's merged into a supported branch)

Taking from an example I'm familiar with, this is my personal repo for an atom package, which uses a single workflow for testing and releases.

https://github.com/keevan/git-link/blob/main/.github/workflows/ci.yml

I believe the relevant lines/checks are here: https://github.com/keevan/git-link/blob/main/.github/workflows/ci.yml#L33-L37

And I'm not too sure but it might accept a range of standard names which would encourage using MOODLE_XX_STABLE as branch names to make it "work", or if that's too drastic, then perhaps some other checks such as branch protection (if available) would suffice.

For repositories that do not have a release yet, it would probably be okay to check if the required secrets.MOODLE_ORG_TOKEN was provided, and if not then skipping the release. This should make it easier to apply to an existing workflow once it's confirmed as ready.

keevan commented 2 years ago

Also this is how it's triggered currently, as pointed out by Brendan via internal comms:

https://github.com/catalyst/moodle-local_envbar/blob/63f04c1/.github/workflows/moodle-release.yml#L7-L12