ci(release): verify CHANGELOG entry on release + fix Release EQL badge#235
Conversation
Add a verify-changelog job to the Release EQL workflow that fails the release run when CHANGELOG.md (at the tagged commit) has no `## [<version>]` section — i.e. the release was cut without first promoting [Unreleased]. This is what happened with eql-2.3.1. Skips pre-releases, which keep entries under [Unreleased] until the final cut. It's an independent job: artifact build/publish still proceed (the release is already published by then), but the workflow goes red so the omission is visible. Also fix the README Release EQL badge: it tracked `?branch=main`, but the workflow effectively never runs on main (it runs on `release` tag events). The last main run was a cancelled workflow_dispatch from 2025-11-26, so the badge showed "failing" despite every release succeeding. Switch to `?event=release`.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
2 participants
What
Two release-workflow hygiene fixes:
verify-changelogjob inrelease-eql.yml— fails the Release EQL run whenCHANGELOG.mdat the tagged commit has no## [<version>]section.?branch=main; switched to?event=release.Why — the consistency check
eql-2.3.1was published without first promotingCHANGELOG.md[Unreleased]→[2.3.1](the "Cutting a release" step inCLAUDE.md). Nothing flagged it. This job is a detective control: on every non-prereleaseeql-*release it checks out the tagged commit and greps for^## \[<version>\]. If it's missing, the release run goes red with an actionable error.build-and-publish/publish-docs. The release is already published by the time the workflow runs, so blocking artifacts would only make things worse; instead the workflow goes red so the omission is visible and gets followed up.github.event.release.prerelease == false) —eql-2.3.0-pre.Netc. keep their entries under[Unreleased]until the final cut, so they have no version section by design.This is the detective option discussed; a fully preventive setup (release-please-style PR-driven releases + a tag ruleset) is a larger change and out of scope here.
Why — the badge
The badge URL had
?branch=main, but the Release EQL workflow effectively never runs onmain— it runs onreleasetag events (head_branch= the tag, e.g.eql-2.3.1). Only two runs in history were onmain, the most recent a cancelledworkflow_dispatchfrom 2025-11-26 — which GitHub renders as a red "failing" badge. Every actual release (2.3.0, 2.3.1, all pre-releases) succeeded.?event=releasemakes the badge reflect the latest release run (currentlyeql-2.3.1— passing).Note
This PR touches
.github/workflows/release-eql.yml, so the workflow'spull_requesttrigger will run it here.verify-changelogis gated ongithub.event_name == 'release', so it is skipped on this PR run — that's expected.