-
Notifications
You must be signed in to change notification settings - Fork 7
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
[CZID-8624] Enforce and automate changelog updates #305
base: main
Are you sure you want to change the base?
Conversation
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.