GHA workflow to automate creation of GH releases & tags #194
Conversation
glennmoy
changed the title
Codecov Report
@@ Coverage Diff @@
## main #194 +/- ##
==========================================
+ Coverage 95.63% 96.35% +0.72%
==========================================
Files 12 13 +1
Lines 595 631 +36
==========================================
+ Hits 569 608 +39
+ Misses 26 23 -3
Flags with carried forward coverage won't be shown. Click here to find out more. see 9 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
This reverts commit 463b534.
It could lead to a race condition since we can't guarantee that the pre-release assets will have been uploaded before it runs.
|
Ok, following up after a test run the pre-release and tag were correctly made but the downstream workflow that was supposed to run on This is because GitHub precludes workflows which are triggered by a Looking into a few recommended solutions, one was to create a PAT, which I don't think is suitable as it's scoped to the user, while the other was to create a Deploy key which is slightly better as it's scoped to the repo. Testing the latter sadly didn't work either :/ . I expected it to at least run the In other words, the new workflow will be to create PRs as normal, then trigger a manual "Create Pre-Release" workflow. This circumvents the I've tested the Pre-release workflow on this branch
|
.github/workflows/Release.yml
Outdated
| @@ -0,0 +1,82 @@ | |||
| name: "Publish Release" | |||
| on: | |||
| workflow_dispatch: | |||
There was a problem hiding this comment.
i.e. can only be manually triggered and allows for triggering of downstream workflows, e.g. artifacts_CI.yml on tag creation
.github/workflows/Release.yml
Outdated
| - name: Download artifacts | ||
| id: download-artifact | ||
| uses: dawidd6/action-download-artifact@v2 | ||
| with: | ||
| branch: main | ||
| name: ray_julia_libraries | ||
| path: ${{ env.tarballs_dir }} | ||
| workflow: CI.yml |
There was a problem hiding this comment.
does this run any risk of multiple PRs being merged and picking up either too old or too new artifacts?
There was a problem hiding this comment.
actually yeah I think that's a risk if we use branch dawidd6/action-download-artifact#240
but if we use commit it should be deterministic
There was a problem hiding this comment.
I believe there is a definite danger here of making a release with the wrong tarballs
There was a problem hiding this comment.
even with commit? in the linked issue there's confounding variables as the OP is using check_artifacts and search_artifacts which have fallback behaviour
.github/workflows/Release.yml
Outdated
| - name: Get Latest Tag | ||
| id: latest_tag | ||
| uses: WyriHaximus/github-action-get-previous-tag@v1 | ||
| # TODO: in future we might need to perform backports, at which point we'll need to check | ||
| # that the project.version has not already been tagged |
There was a problem hiding this comment.
Just curious if you tried git fetch --tags? If that works then you can change the check later to !(project.version in tags) to support backports
There was a problem hiding this comment.
yeah I think it worked - I'll do it as a follow up. Afraid of accidentally breaking things now...
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
There was a problem hiding this comment.
Left another round of suggestions. I'd prefer if the Pre-release workflow was automatically triggered but this will do.
I believe the issue you ran into with the push not re-triggering the workflow is this: https://github.hscsec.cnmunity/t/push-from-action-does-not-trigger-subsequent-action/16854. I don't think we need to take care of that in this PR and can look into this as a follow up.
Closes #161 and #207
upload/download_tarballs.jland associated codeCI.ymlto not run on tagsartifacts_CI.ymlto only run on tags (rename to Tag.yml?)Release.ymlthat is manually triggered to create (pre-)releasesArtifacts.tomlonmainwith a dummy entry (to be used with Overrides.toml)