Create a GitHub release for each action release #2517
Conversation
Must make sure this release is not marked as `latest` or else it will interfere with the CLI bundle releases also included in this repo.
| "${VERSION}" \ | ||
| --latest=false \ | ||
| -t "${VERSION}" \ | ||
| -F CHANGELOG.md |
There was a problem hiding this comment.
Will this include just the release notes for the latest release?
There was a problem hiding this comment.
This creates release notes for all releases. Looks like this: https://github.com/aeisenberg/codeql-action/releases/tag/v1.0.0
There was a problem hiding this comment.
I think it would be great if we could pull out just the relevant section. We already have some code to do that in the .github/update-release-branch.py script which we could reuse.
There was a problem hiding this comment.
Good idea. I'll what I can do. There should also be an easy link to the full changelog.
There was a problem hiding this comment.
Hi @aeisenberg, is this something you still plan to address, or shall we review this PR as is?
There was a problem hiding this comment.
Sorry...this slipped through. Let me take a look at this before you review.
|
Here is a release created using the workflow: https://github.com/aeisenberg/codeql-action/releases Here is the run that created it: https://github.com/aeisenberg/codeql-action/actions/runs/11267116373/job/31331695828 |
| "$VERSION" \ | ||
| --latest=false \ | ||
| -t "$VERSION" \ | ||
| -F "$PARTIAL_CHANGELOG" |
There was a problem hiding this comment.
⛏️ Would it make sense to change the -F to the more explicit --notes-file?
Reveals the intent better, and if it's part of a script it might be more convenient for future readers of the code.
| if line.startswith('## '): | ||
| if found_first_section: | ||
| break | ||
| found_first_section = True |
There was a problem hiding this comment.
The way this works is by appending lines until the a second H2 markdown header is found, as I understand it.
In the test run, the release notes it created contain the header [UNRELEASED]. I think that these headers are processed before the release, but does it make sense to have any sort of post-processing/manipulation of the header in case we come across the [UNRELEASED]?
There was a problem hiding this comment.
Hmmm...I'd originally thought that this was because I didn't start on a release branch, but now I'm not so sure. I'll have to take a deeper look.
There was a problem hiding this comment.
OK...there were two things going on:
- The run was not on a release branch, so we don't see the actual version number. This is expected.
- However, I originally created the changelog too late in the process after the header was changed back to
UNRELEASED.
I've now fixed 2. I also added a few cleanups.
| run: | | ||
| python .github/workflows/script/prepare_changelog.py CHANGELOG.md "$VERSION" > $PARTIAL_CHANGELOG | ||
|
|
||
| echo "::group::Partial CHANGELOG" |
There was a problem hiding this comment.
👍🏻 I like this change! Makes it easier to see what the changelog looked like at the time of generation!
| @@ -108,6 +108,17 @@ jobs: | |||
| # - `--force` since we're overwriting the `vN` tag | |||
| git push origin --atomic --force refs/tags/"${VERSION}" refs/tags/"${major_version_tag}" | |||
|
|
|||
| - name: Prepare partial Changelog | |||
| env: | |||
| PARTIAL_CHANGELOG: "${{ runner.temp }}/partial_changelog.md" | |||
There was a problem hiding this comment.
Just one nitpick, can be merged as is:
I think we can pull this at a higher level in the workflow file, and then the PARTIAL_CHANGELOG variable will be shared between the different steps. The benefit this brings is that if at any point we need to change it, it will be changed at both of the steps that require the same file, instead of having to change two separate definitions of the variable, minimising the chance of the two variables being out of sync and causing a bug by accident.
There was a problem hiding this comment.
I tried that earlier and unfortunately, and runner.temp is not initialized at the job level. I thought this way was safer than trying to hard code the temp directory.
Must make sure this release is not marked as
latestor else it will interfere with the CLI bundle releases also included in this repo.See https://cli.github.com/manual/gh_release_create
Merge / deployment checklist