[CZID-8624] Enforce and automate changelog updates #305
Conversation
There was a problem hiding this comment.
Is there a plan to convert over to only using the top-level CHANGELOG.md file? Because we also have # Changelog sections of the READMEs for both long-read and AMR workflows. It looks to me like this approach assumes that there is only a single changelog file for all of the workflows. If we're going to standardize on a single changelog file for all workflows in the upcoming backfill PR to get our changelogs up to date, no issue. But if that's not planned, uhhh, problems.
| @@ -9,7 +9,7 @@ on: | |||
| description: major, minor, or patch | |||
| default: patch | |||
| release_notes: | |||
| description: A text message summarizing the changes in this release | |||
| description: A text message summarizing the changes in this release, only used for branch releases | |||
There was a problem hiding this comment.
I was a bit confused by this phrasing until you explained it on the team meeting. Maybe expand this a bit to say:
"A text message summarizing the changes in this release. Unused for standard major/minor/patch releases, but used for branch releases."
I'm not sure that's great, but just something clarifying that it doesn't have an expected use in "normal" release flows.
This enforces developers update a changelog and automates the versioning of the changelog. When developing developers can now update the changelog with unreleased notes like:
If they don't, the PR check fails. At deploy time the correct version is automatically filled in instead of unreleased.