Skip to content

ci: add chloggen and workflows for changelog generation#616

Open
agarvin-nr wants to merge 46 commits into
mainfrom
agarvin/chloggen
Open

ci: add chloggen and workflows for changelog generation#616
agarvin-nr wants to merge 46 commits into
mainfrom
agarvin/chloggen

Conversation

@agarvin-nr

@agarvin-nr agarvin-nr commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds OpenTelemetry's chloggen tool to this repo for changelog management.

  • Adds chloggen make targets
  • Enforces a changelog entry is created with each PR
  • Changelog is skippable with:
    • "Skip Changelog" label
    • Any conventional commit prefix chore*, build*, ci*, refactor*, style*, or test*

Release Flow

  1. Developers create a changelog entry with every PR if needed
  2. Bumping component versions with ci-bump-component-versions workflow automatically creates changelog entry like Bump component versions from v... to v...
    a. If relevant changes are found with the version-bump-analysis skill, we can either elaborate using the subtext: field on the autogenerated entry, or generate our own entries as needed.
  3. Bumping nrdot version with release-bump-version-pr will consolidate all changelog entries using make chlog-update into CHANGELOG.md
  4. The release-draft workflow extracts the most recent changes from CHANGELOG.md and provides to goreleaser via --release-notes (this replaces the previous changelog generation)
  5. Unchanged from before: After we publish, the release-publish workflow will issue a docs PR from github.event.release.body

Validation

Added changelog entry for PR #615 (which will be included next release) - make chlog-validate passes

Tested script outputs:

  • scripts/generate-version-bump-chlog.sh (used in ci-bump-component-versions.yaml) with fake upstream version v0.999.0:
change_type: enhancement
component: distributions
issues: [616]
note: Bump otel component versions from v0.154.0 to v0.999.0
subtext:
  • Tested changelog.md output of release-bump-version-pr in Act (using fake version + both chlog entries above)
<!-- This file is autogenerated. See CONTRIBUTING.md for instructions to add an entry. -->

<!-- next version -->

## 1.90.0

### Enhancements

- `distributions`: Bump otel component versions from v0.154.0 to v0.999.0 (#616)
- `docs`: Fix broken mssql link (#615)

<!-- previous-version -->
## 1.90.0

### Enhancements

- `distributions`: Bump otel component versions from v0.154.0 to v0.999.0 (#616)
- `docs`: Fix broken mssql link (#615)

Comment thread .chloggen/config.yaml
Comment on lines +8 to +13
components:
- distributions
- distributions/nrdot-collector
- distributions/nrdot-collector-experimental
- docs
- examples

@agarvin-nr agarvin-nr Jul 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@agarvin-nr agarvin-nr Jul 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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..."

@agarvin-nr agarvin-nr Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. This workflow opens a PR
  2. CI runs against initial PR and fails
  3. This workflow adds changelog entry
  4. 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.

@agarvin-nr agarvin-nr marked this pull request as ready for review July 10, 2026 18:42
@agarvin-nr agarvin-nr requested a review from a team as a code owner July 10, 2026 18:42
@@ -0,0 +1,14 @@
# Use this changelog template to create an entry for release notes.

# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious what this is about? Is there some kind of link validation in chloggen?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .github/workflows/changelog.yaml Outdated

- name: Validate ./.chloggen/*.yaml changes
run: |
make install-tools

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chlog-validate should have install chloggen as a dependency and not require make install-tools beforehand or am I missing something?

@agarvin-nr agarvin-nr Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above, chlog-update should have install chloggen as a dependency

Comment thread internal/tools/go.mod Outdated
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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should probably be a direct dependency now?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! I forgot to go mod tidy this after adding chloggen, I'll do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants