feat: auto-release on tracked upstream version bump#446
Conversation
Adds a workflow that watches docker-bake.hcl for changes to modsec2-version, modsec3-version, httpd-version, or nginx-version. When one of these changes lands on main, it tags and creates a GitHub release, then invokes the publish workflow directly as a reusable workflow so the images build and push without waiting for the next manual release.
📝 WalkthroughWalkthroughAdds a new GitHub Actions workflow ( ChangesAuto-release Workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Push as Push to main
participant CheckJob as check-version-bump
participant TagJob as tag-and-release
participant PublishJob as publish
participant PublishWF as publish.yml
Push->>CheckJob: trigger on docker-bake.hcl change
CheckJob->>CheckJob: compare versions (before vs current SHA)
CheckJob-->>TagJob: bumped=true
TagJob->>TagJob: create release tag
TagJob->>TagJob: gh release create
TagJob-->>PublishJob: release created
PublishJob->>PublishWF: call workflow with dockerhub_user, dockerhub_token
Related issues: None specified. Related PRs: None specified. Suggested labels: ci, github-actions Suggested reviewers: None specified. 🐰 A hop, a bump, a version's shift, 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/auto-release.yml:
- Around line 66-82: Add workflow-level concurrency to the auto-release workflow
so only one release run on main can create tags at a time. The issue is in the
Create release tag and GitHub release step: the gh api loop in tag-and-release
is a non-atomic existence check, so overlapping runs can still pick the same tag
and collide. Fix it by adding a top-level concurrency group keyed to the
workflow/ref so runs serialize before reaching gh release create, and keep the
tag-generation logic in the tag-and-release job as the unique symbol to locate.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ce7ea26f-1d71-47ed-b33d-760eddb544e7
📒 Files selected for processing (2)
.github/workflows/auto-release.yml.github/workflows/publish.yml
| - name: Create release tag and GitHub release | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} | ||
| run: | | ||
| set -euo pipefail | ||
| base="release/$(date -u +%Y%m%d)" | ||
| tag="$base" | ||
| suffix=1 | ||
| while gh api "repos/${{ github.repository }}/git/ref/tags/$tag" >/dev/null 2>&1; do | ||
| tag="${base}-${suffix}" | ||
| suffix=$((suffix + 1)) | ||
| done | ||
|
|
||
| gh release create "$tag" \ | ||
| --target "${{ github.sha }}" \ | ||
| --title "$tag" \ | ||
| --generate-notes |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Race window in tag-existence check; no run-level concurrency control.
Two pushes to main touching docker-bake.hcl in quick succession can trigger overlapping workflow runs. Both tag-and-release jobs would independently loop-check git/ref/tags/$tag, and since the existence check and the gh release create call aren't atomic, both could pass the check for the same $tag before either creates it, causing one run to fail with a duplicate-tag error. Additionally, since only the gh api exit code is checked, a transient non-404 failure (auth hiccup, rate limit, network blip) would be indistinguishable from "tag not found" and cause the script to proceed as if the name were free.
Add a workflow-level concurrency group to serialize runs on main.
🔒 Suggested fix
on:
push:
branches: [main]
paths:
- docker-bake.hcl
+concurrency:
+ group: auto-release-${{ github.workflow }}-${{ github.ref }}
+ cancel-in-progress: false
+
permissions: {}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-release.yml around lines 66 - 82, Add workflow-level
concurrency to the auto-release workflow so only one release run on main can
create tags at a time. The issue is in the Create release tag and GitHub release
step: the gh api loop in tag-and-release is a non-atomic existence check, so
overlapping runs can still pick the same tag and collide. Fix it by adding a
top-level concurrency group keyed to the workflow/ref so runs serialize before
reaching gh release create, and keep the tag-generation logic in the
tag-and-release job as the unique symbol to locate.
1 participant
Summary
.github/workflows/auto-release.yml, triggered on push tomainwhendocker-bake.hclchangesmodsec2-version,modsec3-version,httpd-version, andnginx-versionvalues before/after the push; if any changed, it creates arelease/YYYYMMDDtag (with a numeric suffix on same-day collisions) and a GitHub releaseworkflow_call(with explicitdockerhub_user/dockerhub_tokensecret inputs) topublish.ymlso the new workflow can invoke the build-and-push job directly, without depending onGITHUB_TOKEN-created releases re-triggering therelease: publishedevent (which GitHub Actions does not do)Test plan
actionlint/zizmorpass on both workflow filesdocker-bake.hcland confirm a release is tagged and images are publisheddocker-bake.hclwithout touching the tracked versions (e.g. a CRS bump) and confirm no release is createdAI Disclosure
Per the project's AI-Assisted Contribution Policy:
.github/workflows/auto-release.yml(diffing tracked version variables indocker-bake.hclbetween pushes, tagging/creating the release with same-day collision handling) and theworkflow_calladdition topublish.ymlwith explicit secret inputs, needed because GitHub Actions doesn't let aGITHUB_TOKEN-created release re-trigger therelease: publishedevent.actionlintandzizmorrun against both workflow files (zero findings). I reviewed the job/permission structure and the version-diff logic myself before publishing; the actual tag-and-publish path is still marked as unverified in the test plan below pending a real merge that bumps one of the tracked versions.Summary by CodeRabbit