ci: add hotfix workflow; align workflow names#2307
Merged
alandtse merged 5 commits intoMay 10, 2026
Conversation
Adds release-hotfix.yaml — a workflow_dispatch entry point that prepares a maintenance release candidate without touching dev: - Auto-detects the latest stable tag, derives `hotfix/X.Y.x` from it (creates the branch from the tag if it does not yet exist on origin). - Cherry-picks eligible commits from `dev` onto a fresh `hotfix-staging/X.Y.x-<run_id>` branch. Selection is via a conventional-commit type filter (fix-only / fix+perf / fix+perf+chore; breaking changes always excluded) or an explicit SHA list. `git cherry` patch-id dedup handles re-runs cleanly. - Opens a PR `staging -> hotfix/X.Y.x` so the existing pr-checks.yaml pipeline builds the candidate and publishes a `vX.Y.Z-prNNNN` prerelease for verification. - Re-running supersedes prior open candidates: open hotfix-staging PRs for the same line are auto-closed and their branches deleted. - On no eligible commits or dry-run, no remote pushes happen. Pipeline integration matches the wiki's documented hotfix flow from step 4 onward — once the candidate PR is merged, a maintainer dispatches Release: Semantic Version with release_type=stable on hotfix/X.Y.x and the standard release-build / publish / Nexus pipeline takes over.
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a new "Hotfix Release" GitHub Actions workflow that selects a base tag, derives maintenance/staging branches, cherry-picks eligible commits (by scope or explicit SHAs) into a staging branch, reports results, and optionally pushes branches, closes superseded staging PRs, and opens a labeled hotfix PR. ChangesHotfix Release Workflow
Sequence Diagram(s)sequenceDiagram
participant User
participant ActionsRunner
participant GitRemote
participant GitHubAPI
User->>ActionsRunner: Manually dispatch workflow (inputs)
ActionsRunner->>GitRemote: fetch tags/branches, checkout
ActionsRunner->>GitRemote: create/checkout maintenance & staging branches
ActionsRunner->>GitRemote: cherry-pick commits sequentially
ActionsRunner->>GitHubAPI: list/open/close PRs, push branches, create PR
GitHubAPI-->>User: return PR URL / comments
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
No actionable suggestions for changed features. |
doodlum
approved these changes
May 9, 2026
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/release-hotfix.yaml:
- Around line 114-116: The workflow currently accepts EXPLICIT_COMMITS verbatim
into CANDIDATES and sets SOURCE_DESC, which bypasses the existing safety checks;
instead, parse EXPLICIT_COMMITS into an initial list but then run each candidate
through the same validation/filtering path used for normal discovery (i.e., the
code that enforces the breaking-change exclusion and patch-id deduplication)
before finalizing CANDIDATES and SOURCE_DESC. Concretely, replace the direct
mapfile assignment with logic that splits EXPLICIT_COMMITS, feeds each SHA into
the existing validation functions/loops (the same checks that normally filter
discovered commits), and only append validated SHAs to CANDIDATES so SOURCE_DESC
reflects the count of post-filtered commits.
- Around line 50-52: Add a concurrency section to the hotfix job to serialize
runs that target the same hotfix line: under the job named "hotfix" add a
concurrency.group that derives from the hotfix line identifier (for example
using the dispatch payload or branch/ref like github.event.client_payload.line
or github.ref) so concurrent dispatches for the same line share a group, and set
cancel-in-progress as appropriate to avoid racing deletions; update the job
"hotfix" configuration to use that concurrency group so only one candidate for a
given line runs at a time.
- Around line 124-129: The filter only inspects the subject (SUBJECT) so commits
with a BREAKING CHANGE: footer slip through; update the loop that builds
CANDIDATES to fetch the full commit body (e.g., FULL_MSG=$(git log -1
--pretty=%B "${sha}")), use that full message for the TYPE_RE match (or still
test the subject extracted from FULL_MSG) and explicitly skip any commit where
FULL_MSG contains a BREAKING CHANGE: trailer (case-sensitive or anchored, e.g.,
grep -qE '^BREAKING CHANGE:'), so CANDIDATES only includes non-breaking commits;
refer to the variables TYPE_RE, UNMERGED, SUBJECT (replace/augment with
FULL_MSG) and the for sha in "${UNMERGED[@]}" loop when making this change.
- Around line 71-79: The grep -Ev in the BASE_TAG assignments can return exit
code 1 when there are no matches and, because of set -euo pipefail, will abort
the script before your explicit empty-BAS E_TAG check; change the two command
substitutions that set BASE_TAG (the branches that run git tag ... | grep -Ev --
'-(rc|pr|alpha|beta)' ...) to make the grep step non-fatal (for example append a
fallthrough like "|| true" to the grep pipeline) so the command substitution
always returns, then let the existing if [[ -z "${BASE_TAG}" ]] block handle the
no-stable-tag case; references: RELEASE_LINE, BASE_TAG, set -euo pipefail, grep
-Ev.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 344bb2fc-f5a7-455f-ab65-b09894d133b5
📒 Files selected for processing (1)
.github/workflows/release-hotfix.yaml
|
✅ A pre-release build is available for this PR: |
SkrubbySkrubInAShrub
approved these changes
May 9, 2026
- Add `concurrency` group keyed on the hotfix line so simultaneous dispatches for the same line queue instead of racing on PR-close + branch-delete + push. - Make tag-detection grep tolerate no matches (`|| true`) so the explicit empty-BASE_TAG error path is reached under `set -e`. - Apply a unified breaking-change filter to both explicit-SHA and scope-discovered paths: catches `type!:` subjects AND `BREAKING CHANGE:` / `BREAKING-CHANGE:` footers. - Detect already-applied patches at runtime (cherry-pick produces an empty result) and report them as a separate `dedup` category instead of mislabeling them as conflicts. Works for both selection paths. - Surface breaking-skipped and dedup categories in the run summary and PR body alongside picked / conflicts. Addresses CodeRabbit feedback on community-shaders#2307.
Bash 5.2 (`ubuntu-latest`'s default) refuses inline regex with a parenthesized group inside `[[ =~ ]]`: syntax error in conditional expression: unexpected token `)' near `^[a-zA-Z]+(\([^)]+\))?' Moves the pattern into BREAKING_SUBJECT_RE so the parser sees a plain variable reference. Caught by exercising the script locally against a v1.5.1 worktree before dispatching the workflow on CI.
Aligns with release-build.yaml's 'Release: ...' colon style so all release workflows cluster together alphabetically in the Actions sidebar. 'Candidate' disambiguates from the release-cutting step (Release: Semantic Version) — this workflow only prepares the PR.
All workflow display names now follow the existing `<Group>: <Action>` pattern matching the file prefix, so they cluster alphabetically in the Actions sidebar: - Cleanup Obsolete Releases (PRs and RCs) → Maint: Cleanup Obsolete Releases - Run TODO to Issue → Maint: TODO to Issue - Update Buffers Wiki → Maint: Update Buffers Wiki - Lint PR → PR: Lint - WIP → PR: WIP - Semantic Release → Release: Semantic Version (matches the wiki's documented label for this workflow) The release-semantic.yaml step name "Semantic Release" is unchanged — that's a step inside the job, not a workflow display name.
alandtse
changed the title
This was referenced May 12, 2026
SkrubbySkrubInAShrub
pushed a commit
that referenced
this pull request
May 14, 2026
ParticleTroned
pushed a commit
to ParticleTroned/skyrim-community-shaders
that referenced
this pull request
May 15, 2026
(cherry picked from commit fe589ec)
ParticleTroned
pushed a commit
to ParticleTroned/skyrim-community-shaders
that referenced
this pull request
May 16, 2026
(cherry picked from commit fe589ec)
IgorAlanAlbuquerque
pushed a commit
to IgorAlanAlbuquerque/skyrim-community-shaders
that referenced
this pull request
May 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
release-hotfix.yaml— aworkflow_dispatchentry point that automates the prep stages of the wiki's Hotfix Release Process (steps 2–3) without touchingdev. The standard release pipeline from step 4 onward (manualRelease: Semantic Version→ tagged build → publish → Nexus) is unchanged.What it does
-rc/-pr/-alpha/-beta); optionalrelease_lineinput pins a specific line (e.g.1.5).hotfix/X.Y.xfrom the tag, creating the branch on origin if it does not exist.devonto a freshhotfix-staging/X.Y.x-<run_id>branch:scopedropdown:fix-only(default) /fix+perf/fix+perf+chore. Breaking changes always excluded.commitsinput accepts an explicit SHA list, bypassing the type filter.git cherrypatch-id dedup handles re-runs and prior patches already on the maintenance branch.staging → hotfix/X.Y.xso the existingpr-checks.yamlbuilds the candidate and publishes avX.Y.Z-prNNNNprerelease for testing.dry_run: true(default) previews the plan in the run summary without any remote writes.Failure / rerun semantics
hotfix-staging/X.Y.x-*PRs auto-closed, branches deleted, fresh PR opened.devmid-flightPipeline integration
Steps 4 onward are identical to the documented manual hotfix flow.
Notes
RELEASE_PAT(same secret asrelease-semantic.yaml).Test plan
dev(defaultrelease_lineempty,scope: fix-only,dry_run: true) — verify run summary shows expected base tag, branch names, and candidate list with no remote pushes.dry_run: falseagainst a low-stakes line — verify staging branch + PR appear, prerelease build fires, candidate is installable.commitsinput set to a specific SHA — verify only that commit is picked.commitsinput with a known-conflicting SHA) — verify it surfaces in PR body and the run continues.Release: Semantic Versionwithrelease_type=stableon the hotfix branch — verify the standard pipeline produces the expected patch tag and draft release.🤖 Generated with Claude Code
Summary by CodeRabbit