Repository navigation
Conversation
…it did The blocked comment said only that the gate did not reach a verdict and linked the run. True, and no help: the author opens the run and hunts for the red job. Measured on ungoliant-controller, whose first breaking change produced exactly that comment. The cause was three steps away in the log - no catch-all CODEOWNERS rule, no fallback reviewer, so the Environment could not be created - and nothing on the pull request pointed at any of it. The verdict already knew which half failed; it was writing it to the log and telling nobody else. It now emits the stage, the outcome forwards it, and the comment names it. The request case also names the cause that actually occurs, since it is the one a reader cannot guess. Empty keeps the neutral wording, so a caller that does not pass it is no worse off. @radagast-lerian offered both options on #926 and I took the cheaper one; this is the other.
…lock
charts.lerian.studio is built by GitHub Pages (Jekyll 3.10), which runs Liquid
over every .md. Upgrade guides carry Helm template snippets ({{ ... }}): they
raised hundreds of Liquid warnings and an unterminated one broke the whole
site build (LerianStudio/helm#2565 fixes the existing guides).
Generated guides that contain {{ or {% are now wrapped in
<!-- {% raw %} --> ... <!-- {% endraw %} -->: Liquid honours the tags and
GitHub's markdown view hides the comments. Raw markers are stripped from the
few-shot examples and from the model output first, so the model never echoes
them and the wrap is never nested (nested raw breaks Liquid too).
… logging it The "Run govulncheck" step carried a bare `continue-on-error: true`, so a known vulnerability in a consumer's dependency graph left the Security job green and the finding sat in a job log nobody opens on a passing check. Removing the flag outright would be a break for every repository on the channel: the Go vulnerability database moves independently of the pull request, so a newly published CVE in a common dependency would turn them all red at once, on pull requests touching nothing related — the same shape of breakage x/vuln v1.8.0 already caused here. So the step now branches on the exit code instead. Findings are always annotated: a warning by default, an error — failing the job — when the new `fail_on_govulncheck` input is true. The default keeps today's behaviour, and a repository that has cleaned its graph can opt into the gate on its own schedule. Closes #910
…name A reusable workflow's check is reported as `<caller job> / ... / <job>`, and the caller's job name lives in the consumer's own repository. Measured across the 68 repositories consuming the umbrellas, the same gate produces six distinct names: 48 validate / PR Metadata / Breaking Change Approval / Breaking Change Approval 18 validate / Breaking Change Approval / Breaking Change Approval 5 ui / PR Metadata / ... 1 validate_mcp / PR Metadata / ... 1 Validate PR / ... 1 Metadata Validation / ... Required status checks match the context exactly, with no wildcard, so no single organisation ruleset can require the gate - and a required check that never arrives leaves the pull request pending forever, so listing all six would block every repository that produces only one. A commit status carries no job path. It is the reason `CodeRabbit` and `Socket Security` read identically everywhere, and it removes the caller from the name: set `BREAKING_APPROVAL_STATUS_CONTEXT` once and one rule covers every repository. Published on every run, including the ones with nothing to approve - out of scope, no breaking commits, superseded all publish success. A status that appears only sometimes cannot be required. `result` decides pass or fail; the state only chooses the wording, and the two are not allowed to disagree. `statuses: write` is deliberately not declared on the job: a called workflow may only ask for permissions the caller already holds, so declaring it would break every consumer that does not grant it - the same reasoning the file already applies to `actions: read`. It goes through MANAGE_TOKEN, and warns rather than failing when it cannot be written. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… dead one Three findings from CodeRabbit on #949, all valid. **A superseded run published failure over its replacement.** The verdict emits `state=superseded` with `result=failure` - confirmed by running it - so the authority line turned the intended success into a failure and published it. GitHub reads the latest status for a context, and a superseded run can finish after the one that replaced it, so this would block a pull request on a decision already given. Superseded now publishes nothing, the same rule the comment and the close already follow. My test could not see it: it passed the helper's default `result=success` for every state, which is not what the verdict emits for this one. Each state now carries its real result. **No pending status before the wait.** The previous run's success stayed current while this run sat at the Environment, so a rule requiring the status would allow the merge on a decision nobody had given. The head SHA does not have to change for that - `edited` re-runs on the same commit, and retargeting a pull request moves it in or out of scope. The status now goes pending in `request`, before `approval` can wait, and only when this run will actually hold. **The warning offered a remedy that does nothing.** It suggested granting `statuses: write` on the caller's job. The job declares its own `permissions:`, which replaces what the caller granted, so only MANAGE_TOKEN can write it. Corrected in the warning, the input description and the guide. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two more from CodeRabbit on #949, both real. **An older run could publish success over a newer run's pending.** Retarget a pull request to an in-scope base without touching the head SHA: the old out-of-scope run keeps going - `concurrency` covers the approval job alone, not the workflow - reaches `state=none`, and publishes `success` after the new run has set `pending`. GitHub reads the latest status for a context, so a status-only rule would allow the merge before anyone decided. `superseded` does not cover it. The head did not move and nothing was cancelled, so the old run's `none` is a legitimate verdict about a scope that no longer applies. Both writers now read who wrote the context last and stop if that run is newer. The run id is already in the `target_url` this gate writes, so the ordering is readable without asking the runs API, and a status written by anything else has no id to compare and is left alone. **The doc's failure mode was wrong.** It said a rule requiring the status would stay pending if the write failed. That is only true for a commit with no status yet; where the SHA already carries `success` for the context, a failed write leaves that success current and the merge is allowed. Now stated, with the advice to require the gate's job alongside the status until a run has written it at least once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
lerian-studio
added
size/L
Contributor
🛡️ CodeQL Analysis ResultsLanguages analyzed: ✅ No security issues found. 🔍 View full scan logs | 🛡️ Security tab |
Contributor
🔍 PR Validation Summary✅ PR Mergeable — no blocking failures
|
Contributor
🔍 Lint Analysis
|
This branch was successfully deployed
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.
GitHub Actions Shared Workflows
Description
Type of Change
feat: New workflow or new input/output/step in an existing workflowfix: Bug fix in a workflow (incorrect behavior, broken step, wrong condition)perf: Performance improvement (e.g. caching, parallelism, reduced steps)refactor: Internal restructuring with no behavior changedocs: Documentation only (README, docs/, inline comments)ci: Changes to self-CI (workflows under.github/workflows/that run on this repo)chore: Dependency bumps, config updates, maintenancetest: Adding or updating testsBREAKING CHANGE: Callers must update their configuration after this PRBreaking Changes
None.
Testing
@this-branchor the beta tagCaller repo / workflow run:
Related Issues
Closes #