-
Notifications
You must be signed in to change notification settings - Fork 1
Break workflow up: a reusable workflow using reusable actions #69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3b2cac7
to
971ea41
Compare
d130e30
to
24367db
Compare
This reverts commit 24367db. See this and the subsequent comment: #69 (comment) When we manually use `actions/checkout` to get an action, _it makes us responsible for finding a safe folder_ to checkout the GitHub action- when we let the GitHub Actions system do it for us, the _system_ is responsible for doing it. So, I think that means I prefer the 'system checkout' syntax: ```yml - id: init uses: guardian/gha-scala-library-release-workflow/actions/init@break-workflow-up-into-smaller-reusable-files ``` ...rather than the 'manual checkout' syntax: ```yml - uses: actions/checkout@v4 with: repository: guardian/gha-scala-library-release-workflow # TODO - adapt for forks ref: ${{ ACTION_BRANCH }} - id: init uses: ./.github/actions/init ``` ...even though the 'manual checkout' syntax lets us configure the `ACTION_BRANCH` in just one place.
1bc81d4
to
890711c
Compare
17225a6
to
4074d5c
Compare
steps: | ||
- uses: actions/setup-java@v4 | ||
- id: act | ||
uses: guardian/gha-scala-library-release-workflow/actions/init@break-workflow-up-into-smaller-reusable-files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before merge, we need to switch this - and the other invocations of our actions - to no longer point to the break-workflow-up-into-smaller-reusable-files
branch.
Where should it point?! Maybe we should point to main
- and when we cut a release, switch it to v2
or v3
?!
uses: guardian/gha-scala-library-release-workflow/actions/init@break-workflow-up-into-smaller-reusable-files | |
uses: guardian/gha-scala-library-release-workflow/actions/init@main |
4074d5c
to
6d477bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
actions/update-github/action.yml
Outdated
shell: bash | ||
env: | ||
GH_TOKEN: ${{ steps.generate-github-app-token.outputs.token }} | ||
GH_REPO: ${{ github.repository }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this used for?
9fcb996
to
5d9e4a5
Compare
60aa859
to
dc7b7e6
Compare
dc7b7e6
to
644e8ff
Compare
This change enables a lot of code-reuse with the new Gradle release workflow: * guardian#1 ## Changes * The bulk of the reusable workflow file has been extracted into a suite of 7 GitHub _Actions_ (specifically [composite actions](https://docs.github.com/en/actions/tutorials/creating-a-composite-action)), each of which correspond to the 7 existing jobs in the flow. * As GitHub Actions have a convention that their parameters are 'dash-case', a lot of the parameters have switched from snake-case (`release_type` - with an underscore) to dash-case (`release-type` - with a hyphen). This change means that we should probably * The 5 global environment variables in the reusable workflow have been removed, to improve encapsulation of the 7 GitHub Actions - ie to be. more explicit about what inputs they're actually using. * Unfortunately there's [no](https://github.com/orgs/community/discussions/18601#discussioncomment-13296390) easy way to express that a GitHub Action should run using the same commit as the reusable-workflow file that called it (tho' [it is possible for workflow-to-workflow](https://docs.github.com/en/actions/how-tos/sharing-automations/reusing-workflows#:~:text=If%20you%20use%20the%20second%20syntax%20option%20(without%20%7Bowner%7D/%7Brepo%7D%20and%20%40%7Bref%7D)%20the%20called%20workflow%20is%20from%20the%20same%20commit%20as%20the%20caller%20workflow.%20Ref%20prefixes%20such%20as%20refs/heads%20and%20refs/tags%20are%20not%20allowed.%20You%20cannot%20use%20contexts%20or%20expressions%20in%20this%20keyword.)). Consequently for this PR, all the references to those GitHub actions have a `@break-workflow-up-into-smaller-reusable-files` reference - which needs to be switched to `@main` before merge * For passing files between jobs, we switch from using GitHub Actions _caching_ infrastructure to [using artifacts](https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow#comparing-artifacts-and-dependency-caching). Using caching was always a bit of a hack, and this change means we don't have to try to come up with unique cache keys. * Everything in the '🔒 Update GitHub' Action needs the `GH_REPO` & `GH_TOKEN` environment variables, so I've added them to the env in the `Common Values` section, and moved that step to the start. For [composite actions](https://docs.github.com/en/actions/tutorials/creating-a-composite-action) (unlike reusable workflows), we can [access `github.action_path`](https://github.com/orgs/community/discussions/32593#discussioncomment-3616375) from the [`github` context](https://docs.github.com/en/actions/reference/accessing-contextual-information-about-workflow-runs#github-context), and get files from our repo that way. ## Testing * guardian/etag-caching#96
644e8ff
to
41f0c0d
Compare
I'm happy this is now in a good state - I'm now going to:
|
Actually, I've just realised that although I intended to update these two workflow parameters to use dash-case, I never got round to it in this PR! So the next release will actually be - I think - compatible (if inconsistent in it's use of dash-case) and so I will just release it as v2.0.2. |
Sadly, on #69, I managed to do lots of testing of Preview releases, but not any of full-main-branch releases - consequently I missed that push-release-commit was missing an input parameter of `release-type` - I need a better linter for GitHub Actions! Example failure: https://github.com/guardian/etag-caching/actions/runs/16078051367/job/45377631265
This change enables a lot of code-reuse with the new Gradle release workflow:
Gradle
libraries including version incrementing, monorepos, and multi-module gha-gradle-library-release-workflow#1Changes
release_type
...with an underscore) to dash-case (release-type
...with a hyphen). This change means that we should probably make the next release ofgha-scala-library-release-workflow
have a major-version-bump, eg to v3.@break-workflow-up-into-smaller-reusable-files
reference - which needs to be switched to@main
before mergeFor composite actions (unlike reusable workflows), we can access
github.action_path
from thegithub
context, and get files from our repo that way.Testing
gha-scala-library-release-workflow
PR 69 etag-caching#96