feat(ci): add hotfix cherry-pick and release workflows - #4977
Conversation
|
|
||
| jobs: | ||
| cherry-pick: | ||
| if: github.event.pull_request.merged == true && contains(github.event.pull_request.labels.*.name, 'hotfix') |
There was a problem hiding this comment.
Missing canary branch boundary
When a hotfix-labeled PR is merged into any branch other than canary, this condition still accepts its merge commit and the write-enabled job cherry-picks it directly onto main, bypassing the intended canary integration path. How this was verified: The event has no branch filter, and the job condition checks only merged state and the hotfix label before pushing to main.
| if: github.event.pull_request.merged == true && contains(github.event.pull_request.labels.*.name, 'hotfix') | |
| if: github.event.pull_request.merged == true && github.event.pull_request.base.ref == 'canary' && contains(github.event.pull_request.labels.*.name, 'hotfix') |
| SHA="${{ github.event.pull_request.merge_commit_sha }}" | ||
| if [ "$(git rev-list --parents -n1 "$SHA" | wc -w)" -gt 2 ]; then | ||
| git cherry-pick -x -m 1 "$SHA" | ||
| else | ||
| git cherry-pick -x "$SHA" |
There was a problem hiding this comment.
Migration restriction is unenforced
When a labeled hotfix contains a Drizzle migration that applies cleanly, this unrestricted cherry-pick promotes it to main, allowing stable installations to skip the out-of-order migration or run with a schema inconsistent with the released application. Add an explicit changed-path check that rejects migration and journal files rather than relying on a merge conflict.
| contents: write | ||
| steps: | ||
| - name: Checkout main | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
Privileged action uses mutable tag
Both new workflows resolve actions/checkout@v4 through a mutable tag while granting credentials that can push to main; pinning checkout to a full commit SHA prevents an upstream tag move from changing privileged code without repository review. How this was verified: The cherry-pick job grants contents: write, and the release checkout receives HOTFIX_PUSH_TOKEN.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Adds a hotfix flow so urgent bug fixes can ship as patch releases without waiting for the next big canary → main merge.
How it works
hotfix-cherry-pick.yml— when a PR labeledhotfixis merged into canary, the bot cherry-picks it ontomainand pushes with the defaultGITHUB_TOKEN, which intentionally does not trigger other workflows. Fixes accumulate silently on main. Aconcurrencygroup queues concurrent cherry-picks so they don't race.hotfix-release.yml— manualworkflow_dispatchbutton: bumps the patch version inapps/dokploy/package.json(preserving thevprefix) and pushes withHOTFIX_PUSH_TOKEN(PAT), which does trigger the existingdokploy.ymlbuild + release. One click = one release with all accumulated fixes.Rules
_journal.jsonand fail loudly.Requires the
hotfixlabel and theHOTFIX_PUSH_TOKENrepo secret (already configured).Greptile Summary
Adds two GitHub Actions workflows for accumulating hotfix commits on main and manually releasing them with a patch-version bump.
Confidence Score: 2/5
The PR should not merge until hotfix promotion is restricted to canary-targeted, migration-free PRs.
The new write-capable workflow accepts merged labeled PRs from any base branch and cherry-picks complete commits without excluding migrations, allowing both the intended branch boundary and migration-ordering invariant to be bypassed.
Files Needing Attention: .github/workflows/hotfix-cherry-pick.yml; .github/workflows/hotfix-release.yml
Security Review
The cherry-pick workflow can promote a labeled PR merged into a branch other than canary because it does not validate the PR base branch. Both privileged workflows also use a mutable checkout action tag.
Reviews (1): Last reviewed commit: "feat(ci): add hotfix cherry-pick and rel..." | Re-trigger Greptile