feat(release)!: orchestrate backmerge via backmerge-sync; expose go-pr-validation inputs & enforce coverage - #428
Merged
bedatty merged 8 commits intoJun 17, 2026
Conversation
WalkthroughPR exposes ChangesGo validation inputs and coverage enforcement defaults
Release workflow backmerge orchestration
GHCR push enabled by default
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
lerian-studio
added
size/XS
Contributor
🔍 PR Validation Summary✅ PR Mergeable — no blocking failures
|
Contributor
🔍 Lint Analysis
|
Contributor
🛡️ CodeQL Analysis ResultsLanguages analyzed: ✅ No security issues found. 🔍 View full scan logs | 🛡️ Security tab |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
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/go-pr-validation.yml:
- Around line 95-102: The `golangci_lint_args` input is being passed directly
into a shell command without proper quoting, which creates a shell injection
vulnerability. In the go-pr-analysis.yml workflow file where
`golangci_lint_args` is used in the run command, move the input value to the
`env:` section as an environment variable (e.g., GOLANGCI_ARGS) and then
reference it with proper quoting in the run command (e.g., `"$GOLANGCI_ARGS"`).
This ensures the input is treated as a single string argument rather than being
subject to shell interpretation. Alternatively, document and enforce a strict
allowlist of permitted argument patterns for the `golangci_lint_args` input to
limit the values that can be passed.
🪄 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.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 09af28bc-95a7-43ef-bf00-a86ae506f418
📒 Files selected for processing (2)
.github/workflows/go-pr-validation.ymldocs/go-pr-validation.md
BREAKING CHANGE: fail_on_coverage_threshold now defaults to true in go-pr-analysis and go-pr-validation. Callers whose Go coverage is below coverage_threshold (default 80%) will now fail CI. Set fail_on_coverage_threshold: false to restore the previous reporting-only behavior.
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
.github/workflows/go-pr-analysis.yml (2)
7-9:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd
workflow_dispatchto align with reusable workflow trigger requirements.This workflow currently declares only
workflow_call.As per coding guidelines,
.github/workflows/*.ymlworkflows must include bothworkflow_callandworkflow_dispatch(exceptself-*files).🤖 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/go-pr-analysis.yml around lines 7 - 9, The workflow file is missing the `workflow_dispatch` trigger. In the `on:` section at the beginning of the file, add `workflow_dispatch:` as an additional trigger alongside the existing `workflow_call:` trigger to align with the coding guidelines that require both triggers for non-self workflows.Source: Coding guidelines
8-97:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftIntroduce
dry_runand gate state-changing steps.This workflow performs state changes (PR comments + Slack notifications) but does not expose a
dry_runboolean input. Adddry_run(default: false) and conditionally skip state-mutating steps/jobs when enabled.Suggested change (core wiring)
on: workflow_call: inputs: + dry_run: + description: 'Preview mode: skip state-changing actions (comments/notifications)' + type: boolean + default: false runner_type: description: 'GitHub runner type' type: string default: 'blacksmith-4vcpu-ubuntu-2404' @@ - - name: Post coverage comment - if: github.event_name == 'pull_request' + - name: Post coverage comment + if: github.event_name == 'pull_request' && !inputs.dry_run uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0 @@ notify: name: Notify needs: [detect-changes, lint, security, tests, build, integration-tests, test-determinism] - if: always() && needs.detect-changes.outputs.has_changes == 'true' + if: always() && needs.detect-changes.outputs.has_changes == 'true' && !inputs.dry_run uses: ./.github/workflows/slack-notify.ymlAs per coding guidelines, workflows that apply state changes must expose a
dry_runboolean input (defaultfalse).Also applies to: 622-623, 943-947
🤖 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/go-pr-analysis.yml around lines 8 - 97, Add a new boolean input called `dry_run` with default value `false` to the workflow_call inputs section alongside the other existing inputs like `enable_lint`, `enable_security`, etc. Then identify all state-changing steps in the workflow that perform PR comments or Slack notifications (referenced at lines 622-623 and 943-947) and add conditional checks to skip these steps when `dry_run` is set to true, allowing the workflow to run in test mode without making actual changes to the repository or sending notifications.Source: Coding guidelines
.github/workflows/go-pr-validation.yml (1)
8-10:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd
workflow_dispatchto satisfy reusable-workflow trigger policy.This reusable workflow exposes
workflow_callonly. The shared CI/CD guideline for non-self-*workflows requires both triggers.Suggested change
on: workflow_call: inputs: runner_type: description: 'GitHub runner type to use' type: string default: 'blacksmith-4vcpu-ubuntu-2404' + workflow_dispatch:As per coding guidelines,
.github/workflows/*.ymlworkflows must include bothworkflow_callandworkflow_dispatch(exceptself-*files).🤖 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/go-pr-validation.yml around lines 8 - 10, The workflow file currently only defines the `workflow_call` trigger in the `on:` section but is missing the required `workflow_dispatch` trigger. Add `workflow_dispatch:` as a separate trigger entry under the `on:` section alongside the existing `workflow_call:` trigger to comply with the shared CI/CD guideline that requires all non-self-* workflows to support both trigger types.Source: Coding guidelines
docs/go-pr-validation.md (1)
80-82:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winPin the production
uses:example to an exact semver tag.The example currently uses
@v1, which is a floating major. For production examples indocs/, use an exact pinned tag (for example@v1.0.0).Suggested change
- uses: LerianStudio/github-actions-shared-workflows/.github/workflows/go-pr-validation.yml@v1 + uses: LerianStudio/github-actions-shared-workflows/.github/workflows/go-pr-validation.yml@v1.0.0As per coding guidelines, production examples in
docs/must use pinned stable versions in@vX.Y.Zform.🤖 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 `@docs/go-pr-validation.md` around lines 80 - 82, The production example in the go-pr-validation.md file uses a floating major version tag `@v1` in the uses field of the GitHub Actions workflow reference, which does not meet production documentation standards. Update the uses statement that references the LerianStudio/github-actions-shared-workflows workflow to pin it to an exact semver version in the format `@vX.Y.Z` instead of the floating `@v1` tag to comply with coding guidelines for production examples in documentation.Source: Coding guidelines
docs/go-pr-analysis-workflow.md (1)
1-1:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftRename this workflow documentation file to match the workflow filename contract.
For
.github/workflows/go-pr-analysis.yml, the doc should bedocs/go-pr-analysis.md(notdocs/go-pr-analysis-workflow.md). Please rename and update inbound links.As per coding guidelines, workflow documentation filenames in
docs/*.mdmust exactly match the workflow filename stem.🤖 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 `@docs/go-pr-analysis-workflow.md` at line 1, Rename the documentation file from docs/go-pr-analysis-workflow.md to docs/go-pr-analysis.md to match the workflow filename stem from .github/workflows/go-pr-analysis.yml according to the documentation naming convention. After renaming, search the entire codebase for any inbound links or references that point to the old filename (go-pr-analysis-workflow.md) and update them to reference the new filename (go-pr-analysis.md).Source: Coding guidelines
🤖 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/go-pr-analysis.yml:
- Around line 48-51: The `fail_on_coverage_threshold` parameter in the workflow
inputs has its default set to `true`, which is a breaking change for existing
callers who relied on the previous default behavior. Change the `default` value
for `fail_on_coverage_threshold` back to `false` to maintain backward
compatibility with direct callers of this workflow, unless this breaking change
has been intentionally documented and communicated as a required upgrade.
In @.github/workflows/go-pr-validation.yml:
- Around line 107-110: The default value for the fail_on_coverage_threshold
input has been changed from false to true, which introduces a breaking change
for callers of this workflow that do not explicitly override this input. To
maintain backward compatibility, revert the default value of
fail_on_coverage_threshold back to false, requiring callers to explicitly opt-in
to the stricter coverage checking behavior by setting the input to true.
---
Outside diff comments:
In @.github/workflows/go-pr-analysis.yml:
- Around line 7-9: The workflow file is missing the `workflow_dispatch` trigger.
In the `on:` section at the beginning of the file, add `workflow_dispatch:` as
an additional trigger alongside the existing `workflow_call:` trigger to align
with the coding guidelines that require both triggers for non-self workflows.
- Around line 8-97: Add a new boolean input called `dry_run` with default value
`false` to the workflow_call inputs section alongside the other existing inputs
like `enable_lint`, `enable_security`, etc. Then identify all state-changing
steps in the workflow that perform PR comments or Slack notifications
(referenced at lines 622-623 and 943-947) and add conditional checks to skip
these steps when `dry_run` is set to true, allowing the workflow to run in test
mode without making actual changes to the repository or sending notifications.
In @.github/workflows/go-pr-validation.yml:
- Around line 8-10: The workflow file currently only defines the `workflow_call`
trigger in the `on:` section but is missing the required `workflow_dispatch`
trigger. Add `workflow_dispatch:` as a separate trigger entry under the `on:`
section alongside the existing `workflow_call:` trigger to comply with the
shared CI/CD guideline that requires all non-self-* workflows to support both
trigger types.
In `@docs/go-pr-analysis-workflow.md`:
- Line 1: Rename the documentation file from docs/go-pr-analysis-workflow.md to
docs/go-pr-analysis.md to match the workflow filename stem from
.github/workflows/go-pr-analysis.yml according to the documentation naming
convention. After renaming, search the entire codebase for any inbound links or
references that point to the old filename (go-pr-analysis-workflow.md) and
update them to reference the new filename (go-pr-analysis.md).
In `@docs/go-pr-validation.md`:
- Around line 80-82: The production example in the go-pr-validation.md file uses
a floating major version tag `@v1` in the uses field of the GitHub Actions
workflow reference, which does not meet production documentation standards.
Update the uses statement that references the
LerianStudio/github-actions-shared-workflows workflow to pin it to an exact
semver version in the format `@vX.Y.Z` instead of the floating `@v1` tag to
comply with coding guidelines for production examples in documentation.
🪄 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.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: a08d0001-f444-4143-bc55-a98831b5d73f
📒 Files selected for processing (4)
.github/workflows/go-pr-analysis.yml.github/workflows/go-pr-validation.ymldocs/go-pr-analysis-workflow.mddocs/go-pr-validation.md
…emantic-release plugin Move backmerge out of the @saithodev/semantic-release-backmerge plugin and into a dedicated backmerge-sync step that runs after a successful release. This removes the continue-on-error + release-tag-snapshot + release-tag-check + backmerge-pr fallback machinery that only existed to work around the plugin masking the release outcome. Backmerge is now configurable via inputs and only runs when the release ref matches backmerge_source (so beta releases on develop are unaffected). BREAKING CHANGE: backmerge is no longer driven by the @saithodev/semantic-release-backmerge plugin in each caller's .releaserc. Callers must remove that plugin entry from their .releaserc and rely on the new backmerge_* inputs (defaults reproduce the previous main->develop behavior). Callers that keep the plugin referenced will fail because it is no longer installed by the workflow.
bedatty
changed the title
lerian-studio
added
size/S
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/release-workflow.md (1)
82-90:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winInputs table default for
runner_typeis stale versus workflow contract.The docs still show
runner_typedefault asfirmino-lxc-runners, but.github/workflows/release.ymldefaults it toblacksmith-4vcpu-ubuntu-2404. This will mislead callers configuring overrides.As per coding guidelines, “Flag if inputs table is out of sync with the corresponding workflow changes in this PR.”
🤖 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 `@docs/release-workflow.md` around lines 82 - 90, The documentation table in the inputs section shows an outdated default value for the runner_type input parameter. Update the default value for runner_type in the inputs table from firmino-lxc-runners to blacksmith-4vcpu-ubuntu-2404 to align with the actual default specified in the corresponding .github/workflows/release.yml file. This ensures the documentation accurately reflects the current workflow contract.Source: Coding guidelines
🤖 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.yml:
- Around line 56-77: The workflow orchestrates state-changing backmerge
operations but lacks a dry_run input for safe validation before mutating
branches. Add a new boolean input called dry_run with default value false to the
inputs section alongside the existing backmerge configuration inputs
(backmerge_enabled, backmerge_source, backmerge_target, backmerge_mode). Then
locate where the backmerge-sync action is called (referenced as occurring around
lines 211-227) and pass the dry_run input value to that action invocation to
enable callers to safely validate the backmerge behavior without applying actual
branch mutations.
- Around line 211-227: The backmerge configuration validation is currently only
performed inside the backmerge-sync action, which runs after semantic-release
publishes the release. This creates an operationally problematic scenario where
a release can be published but the backmerge step fails due to invalid
configuration. Add a preflight validation step that runs before the semantic
release step to validate the backmerge inputs early. This step should verify
that inputs.backmerge_mode is valid and that the inputs.backmerge_source and
inputs.backmerge_target branches are properly configured, failing fast if
validation fails so that semantic-release never runs with invalid backmerge
configuration.
In `@docs/release-workflow.md`:
- Around line 463-464: The documentation text at line 463-464 only describes the
direct-with-pr-fallback backmerge behavior, but the backmerge_mode input
actually supports three modes: direct, pr, and direct-with-pr-fallback. Update
the backmerge documentation to explicitly describe what each of these three
modes does, so that callers understand the behavior differences between them.
This should clarify how direct mode works differently from pr mode, and how
direct-with-pr-fallback differs from both.
---
Outside diff comments:
In `@docs/release-workflow.md`:
- Around line 82-90: The documentation table in the inputs section shows an
outdated default value for the runner_type input parameter. Update the default
value for runner_type in the inputs table from firmino-lxc-runners to
blacksmith-4vcpu-ubuntu-2404 to align with the actual default specified in the
corresponding .github/workflows/release.yml file. This ensures the documentation
accurately reflects the current workflow contract.
🪄 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.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: de9aa94b-7628-41ab-b714-a6625fbef1bb
⛔ Files ignored due to path filters (1)
.releaserc.ymlis excluded by!.releaserc.yml
📒 Files selected for processing (2)
.github/workflows/release.ymldocs/release-workflow.md
- Add dry_run input wired to both semantic-release (no tags/releases) and the backmerge-sync step (preview only), so callers can validate safely. - Validate backmerge_mode and source/target branches before the release runs, failing fast instead of producing 'release published + job failed'. - Document all three backmerge modes.
Align go-release.yml and build.yml with the TypeScript side (typescript-build.yml already defaults to true). GHCR push is now on by default; callers must provide MANAGE_TOKEN (org secret) or set enable_ghcr: false to opt out. BREAKING CHANGE: enable_ghcr default changed from false to true in go-release.yml and build.yml. Callers that did not push to GHCR before will now attempt to, which requires the MANAGE_TOKEN secret. Set enable_ghcr: false to keep the previous behavior.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/go-release-workflow.md (1)
41-45:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winClarify MANAGE_TOKEN requirement in secrets table.
The secrets table marks
MANAGE_TOKENas "Required: No", but withenable_ghcrnow defaulting totrue, the token is effectively required unless callers explicitly setenable_ghcr: false. Consider updating the "Required" column to "Yes (unlessenable_ghcr: false)" or adding a note that the token is needed for the default GHCR push behavior.📝 Suggested clarification
| Secret | Description | Required | |--------|-------------|----------| -| `MANAGE_TOKEN` | Token for release commits, tags and private module access | No | +| `MANAGE_TOKEN` | Token for release commits, tags, GHCR push, and private module access | Yes (unless `enable_ghcr: false`) | | `SLACK_WEBHOOK_URL` | Slack webhook for pipeline notifications | No | | `HELM_REPO_TOKEN` | Token for dispatching Helm chart updates (when enabled in build) | No |🤖 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 `@docs/go-release-workflow.md` around lines 41 - 45, Update the secrets table in the documentation to clarify the MANAGE_TOKEN requirement. The current "Required: No" value is misleading since enable_ghcr defaults to true, making the token effectively required for default behavior. Change the "Required" column value for the MANAGE_TOKEN row from "No" to "Yes (unless `enable_ghcr: false`)" to accurately reflect that the token is only optional when callers explicitly disable the GHCR push feature. Alternatively, add a note below the table explaining the conditional requirement based on the enable_ghcr setting.
🤖 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.
Outside diff comments:
In `@docs/go-release-workflow.md`:
- Around line 41-45: Update the secrets table in the documentation to clarify
the MANAGE_TOKEN requirement. The current "Required: No" value is misleading
since enable_ghcr defaults to true, making the token effectively required for
default behavior. Change the "Required" column value for the MANAGE_TOKEN row
from "No" to "Yes (unless `enable_ghcr: false`)" to accurately reflect that the
token is only optional when callers explicitly disable the GHCR push feature.
Alternatively, add a note below the table explaining the conditional requirement
based on the enable_ghcr setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: c772688f-1f41-42c5-a8bd-f391ab298da2
📒 Files selected for processing (4)
.github/workflows/build.yml.github/workflows/go-release.ymldocs/build-workflow.mddocs/go-release-workflow.md
github-actions
Bot
deleted the
feat/go-pr-validation-expose-lint-args-app-prefix
branch
June 17, 2026 18:55
bedatty
added a commit
that referenced
this pull request
Jun 17, 2026
…e-lint-args-app-prefix feat(release): orchestrate backmerge via backmerge-sync; expose go-pr-validation inputs & enforce coverage
14 tasks
This was referenced Jun 18, 2026
Closed
14 tasks
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
2 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.
GitHub Actions Shared Workflows
Description
Several related changes to the Go release/validation pipeline:
1. Expose
golangci_lint_argsandapp_name_prefixongo-pr-validation.yml(closes #427)The umbrella
go-pr-validation.ymlonly forwarded a subset ofgo-pr-analysis.yml's inputs.golangci_lint_args(e.g.--timeout=5m) andapp_name_prefixare now exposed and forwarded.golangci_lint_argsdefaults to--timeout=5m(mirroring the downstream default) so existing callers keep their timeout. While exposing it, the input is mapped through a step-levelenv:var and split withread -rabefore reachinggolangci-lint run, removing the previous direct${{ }}interpolation into arun:block (shell-injection hardening; satisfies shellcheck SC2086; preserves multi-flag word-splitting).2. Enforce Go coverage threshold by default
fail_on_coverage_thresholdnow defaults totrueingo-pr-analysis.ymlandgo-pr-validation.yml.3. Orchestrate backmerge via
backmerge-syncinstead of the semantic-release pluginBackmerge moves out of the
@saithodev/semantic-release-backmergeplugin and into a dedicatedbackmerge-syncstep inrelease.yml, running after a successful release. This removes thecontinue-on-error+release-tag-snapshot+release-tag-check+backmerge-prfallback machinery that only existed to work around the plugin masking the release outcome. Backmerge is now configurable (backmerge_enabled/backmerge_source/backmerge_target/backmerge_mode) and only runs when the release ref matchesbackmerge_source(beta releases ondevelopare unaffected). Adry_runinput (wired to both semantic-release and the backmerge step) and a pre-release validation step were added. This repo's.releaserc.ymldrops the plugin.4. Default
enable_ghcrtotrueingo-release.ymlandbuild.ymlAligns the Go/build side with
typescript-build.yml, which already defaults totrue. GHCR push is now on by default.Affected workflows:
go-pr-validation.yml,go-pr-analysis.yml,release.yml(+.releaserc.yml),go-release.yml,build.yml.Type of Change
feat: New workflow or new input/output/step in an existing workflowBREAKING CHANGE: Callers must update their configuration after this PRBreaking Changes
a) Coverage enforcement —
fail_on_coverage_thresholddefaultfalse→trueingo-pr-analysis.yml/go-pr-validation.yml. Callers belowcoverage_threshold(default80) that previously passed will now fail.Migration: set
fail_on_coverage_threshold: falseto keep reporting-only behavior.b) Backmerge orchestration — backmerge is no longer driven by the
@saithodev/semantic-release-backmergeplugin in each caller's.releaserc.Migration: remove the plugin entry from your
.releaserc; thebackmerge_*inputs default to the previousmain → developbehavior. Usebackmerge_source/backmerge_targetfor other topologies, orbackmerge_enabled: falseto disable. Callers that keep the plugin referenced will fail (it is no longer installed by the workflow).c) GHCR default —
enable_ghcrdefaultfalse→trueingo-release.yml/build.yml. Callers that did not push to GHCR before will now attempt to, which requires theMANAGE_TOKENsecret.Migration: set
enable_ghcr: falseto keep the previous behavior.The input-exposure part (#427) is non-breaking.
Testing
@this-branchor the beta tagCaller repo / workflow run:
Related Issues
Closes #427
Summary by CodeRabbit
golangci-lintarguments (default--timeout=5m) and anapp_name_prefix.backmerge_enabled,backmerge_source,backmerge_target,backmerge_mode) anddry_run.enable_ghcr) for build/release workflows.fail_on_coverage_thresholdnow defaults totrue).