ci: Add release-please and bring CHANGELOG up to date

[matthewelwell]

Adopts release-please via github-webhook-handler. Rebased onto main after #248.

⚠️ Merge-order dependency — read first

#248 wrote a ## 0.12.0 section by hand, and v0.12.0 is not tagged yet. So the manifest starts at 0.12.0, not 0.11.0. Starting at 0.11.0 would have release-please see the two feat commits since v0.11.0, propose 0.12.0, and prepend a second 0.12.0 section on top of the hand-written one. bootstrap-sha points at the #248 merge for the same reason.

This is safe whether or not you tag v0.12.0 before merging:

• Tag v0.12.0 first (the intended path) — release-please finds the release, manifest agrees, next feat proposes 0.13.0.
• Merge this first — release-please finds no commits after bootstrap-sha worth releasing and sits idle until the next real change. No duplicate either way.

What it is not safe against is someone resetting the manifest to 0.11.0 to "match the last tag". That is the one change that reintroduces the duplicate.

No workflow — the handler does this

The handler runs release-please itself on every push to a repo's default branch, for any repo with release-please-config.json and .release-please-manifest.json in its root. It also deliberately stands down if it finds a release-please*.yml workflow — should_run_release_please returns (has_config and has_manifest) and not has_workflow. An earlier revision of this PR added a workflow, which would have opted this repo out of the org mechanism rather than complemented it. Now config-only.

12 of the 33 org repos with release-please config are handler-driven, including flagsmith, edge-api, ci, pulumi and the handler itself. The other 21 predate the handler's release-please support (May 2026) and the not has_workflow guard is what keeps them working; flagsmith-cli was migrated off its workflow in July. Config matches house style — flagsmith-cli is the closest analogue (release-type: go, same changelog-sections) and ci also carries a bootstrap-sha.

goreleaser still fires

The handler tags using a GitHub App installation token, not GITHUB_TOKEN, so the tag push does trigger workflows. Verified rather than assumed: flagsmith-cli is handler-driven with release.yml on push: tags: ["v*"], and its v2.0.0-beta.1/2/3 runs were all push-triggered from the handler's release commits.

release-type: go means changelog and tag only — no version file to bump, since goreleaser injects the version from the tag via ldflags.

The handler creates the GitHub release, then goreleaser fires on the tag and wants one too. goreleaser's default is already keep-existing, so it attaches artifacts and leaves the notes alone; I've pinned release.mode: keep-existing explicitly rather than leave a silent dependency on a default.

CHANGELOG — now purely a reformat

#248 brought the content up to date, so this no longer backfills anything. It only converts the existing entries onto the headings release-please emits. Bullet text is copied verbatim — checked mechanically, all 61 bullets on main are byte-identical here. The only textual change is that the three bare fix https://... lines under 0.5.1, 0.7.0 and 0.8.1 become bullets, same text.

ENHANCEMENTS and NOTES keep their own headings; release-please has no equivalent and mapping them onto Other would change what they say.

0.12.0 is dated 2026-08-26, the day #248 merged, since it isn't tagged yet. One line to correct if the release lands on a different day.

Deliberate deviation: bump-minor-pre-major

The other repos carry false. They are all past 1.0.0, so it is inert for them. This provider is at 0.12.0, where it decides whether a breaking change bumps to 0.13.0 or 1.0.0. Set to true here so breaking changes take the minor: every pre-1.0 breaking change in this provider (0.2.0, 0.3.0, 0.4.0) took the minor, and a Terraform registry version cannot be unpublished, so an accidental feat!: promoting the provider to 1.0.0 is not walkable-back. One-line flip if you'd rather match.

Dependabot

Bumps land as Build(deps):, which fails the org PR title check — its regex requires a lowercase type, so Build never even reaches the allowed-types list. I confirmed this by running the handler's own validator: Build(deps): Bump ... → failure, deps: Bump ... → success. That is why these PRs were being renamed by hand (#241 kept the original title, #242 was renamed).

commit-message.prefix fixes the PR title and the commit subject — dependabot builds both from the same string (commit_subject derives from pr_name). Also needed for the changelog: Build(deps): isn't a conventional type, so every dependency update would have been dropped. Note that single-commit dependabot PRs squash using the commit message, so the broken prefix is what lands on main regardless of a renamed title.

Verification

go build ./... and go vet ./... pass; both JSON configs parse. goreleaser isn't installed locally so I couldn't run goreleaser check — worth a glance at the .goreleaser.yml change.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9c1af178-6ece-4e32-a447-a7734f37769b

📥 Commits

Reviewing files that changed from the base of the PR and between a35a2db and 0bc3973.

📒 Files selected for processing (5)

• .github/dependabot.yml
• .goreleaser.yml
• .release-please-manifest.json
• CHANGELOG.md
• release-please-config.json

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The change configures Dependabot commit prefixes, adds Release Please settings and a 0.12.0 manifest entry, and updates GoReleaser to preserve existing GitHub releases and notes. CHANGELOG.md now uses consistent Markdown release formatting, comparison links, dates, headings, and bullet points for releases from 0.1.0 to 0.12.0.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 0bc39

This change adds release automation and updates release metadata without any identified merge-blocking issue; it is merge-ready after normal checks and review.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}