ci: add chloggen and workflows for changelog generation#616
ci: add chloggen and workflows for changelog generation#616agarvin-nr wants to merge 46 commits into
Conversation
c124eb3 to
c11a324
Compare
| components: | ||
| - distributions | ||
| - distributions/nrdot-collector | ||
| - distributions/nrdot-collector-experimental | ||
| - docs | ||
| - examples |
There was a problem hiding this comment.
Adding this list to the config enforces that only these components may be added to each entry. If this is too restrictive, we could instead omit this section entirely (then users would still be mandated to add some "component" to their changelog, but would be free to choose whatever.)
| @@ -0,0 +1,31 @@ | |||
| #!/bin/bash | |||
There was a problem hiding this comment.
I've had a few near-misses (from copy-paste or Claude) with GitHub Actions commit hashes being pinned to versions differing from the rest of the repo. I made this script to try and catch that more reliably, and I thought it might be nice for CI.
Examples of it working: Failing run from this PR and successful run after I fixed it
| echo "Updated PR #$pr_number" | ||
| else | ||
| echo "Creating new PR..." | ||
| echo "Creating new draft PR..." |
There was a problem hiding this comment.
chloggen mandates that there is at least one value entered into the issues field of each entry, which is meant to represent either an issue number (which we don't use) or pull request number.
For our auto-generated PRs, we cannot generate a passing changelog before we have a PR number, which means we must create a PR beforehand. This leads to the following issue:
- This workflow opens a PR
- CI runs against initial PR and fails
- This workflow adds changelog entry
- CI runs against workflow and passes
The CI run in step 2 will always fail, either because of the lack of changelog, or because it was cancelled by the CI run at 4. I don't think this would affect the release process, but my idea here was to mark it as a draft PR here, then mark it as 'ready' after the changelog is added so we don't get emailed until it's ready.
| @@ -0,0 +1,14 @@ | |||
| # Use this changelog template to create an entry for release notes. | |||
|
|
|||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | |||
There was a problem hiding this comment.
It would be ideal if we had control over the categories and could use our existing labels like 'Features'. Eventually we'll also want to inject the changes into the metadata like we do for the host use case.
I think it's worth seeing if we can extend and/or configure chloggen somehow to adjust this behavior. One solution might also be wrapping it and have a postprocessor adjust the output?
If it gets too complicated, we can skip it for now, but a plan how we can get to that state would be great.
There was a problem hiding this comment.
If the template is essentially fixed to use the terminology OTel has established, than we can probably live with just relabelling it in the changelog template, would just be ideal if we don't have that translation layer, so that the chloggen files already use our terminology.
There was a problem hiding this comment.
I had the same thought about trying to control these categories. I briefly looked at trying to configure these values, and unfortunately it looks like the change types are hard-coded.
I agree that it would be much nicer to have the actual section names reflected in the changelog entries though. I can look into adding an intermediary processor that sits in between the changelog .yamls and chloggen.
| env: | ||
| # Make sure to exit early if cache segment download times out after 2 minutes. | ||
| # We limit cache download as a whole to 5 minutes. | ||
| SEGMENT_DOWNLOAD_TIMEOUT_MINS: 2 |
There was a problem hiding this comment.
curious what this is about? Is there some kind of link validation in chloggen?
There was a problem hiding this comment.
That's a great question - I took most of this workflow from the components repo and missed this. I just did some research and found that it's an environment variable used to set cache download timeout in actions/cache. In this instance, it seems it's used to configure actions/setup-go (which uses the same cache mechanism via toolkit/cache.)
The default timeout is 10 minutes. I imagine this would be a lot more relevant for repos with bigger caches than releases (like our components repo or upstream contrib), but we're probably safe to remove this from here if need be.
|
|
||
| - name: Validate ./.chloggen/*.yaml changes | ||
| run: | | ||
| make install-tools |
There was a problem hiding this comment.
chlog-validate should have install chloggen as a dependency and not require make install-tools beforehand or am I missing something?
There was a problem hiding this comment.
You are correct, it shouldn't require make install-tools, I will remove it. A few of the other new make targets were missing the install dependency too, so I'll add those in.
| - name: Generate changelog | ||
| id: chloggen | ||
| run: | | ||
| make install-tools |
There was a problem hiding this comment.
same as above, chlog-update should have install chloggen as a dependency
| github.com/sergi/go-diff v1.3.1 // indirect | ||
| github.com/spf13/cobra v1.10.2 // indirect | ||
| github.com/spf13/pflag v1.0.10 // indirect | ||
| go.opentelemetry.io/build-tools/chloggen v0.30.0 // indirect |
There was a problem hiding this comment.
should probably be a direct dependency now?
There was a problem hiding this comment.
Good catch! I forgot to go mod tidy this after adding chloggen, I'll do that.
Summary
Adds OpenTelemetry's
chloggentool to this repo for changelog management.chore*,build*,ci*,refactor*,style*, ortest*Release Flow
ci-bump-component-versionsworkflow automatically creates changelog entry likeBump component versions from v... to v...a. If relevant changes are found with the
version-bump-analysisskill, we can either elaborate using thesubtext:field on the autogenerated entry, or generate our own entries as needed.release-bump-version-prwill consolidate all changelog entries usingmake chlog-updateintoCHANGELOG.mdrelease-draftworkflow extracts the most recent changes fromCHANGELOG.mdand provides to goreleaser via--release-notes(this replaces the previous changelog generation)release-publishworkflow will issue a docs PR fromgithub.event.release.bodyValidation
Added changelog entry for PR #615 (which will be included next release) -
make chlog-validatepassesTested script outputs:
scripts/generate-version-bump-chlog.sh(used inci-bump-component-versions.yaml) with fake upstream versionv0.999.0:release-bump-version-prin Act (using fake version + both chlog entries above)