ci(nix): keep the nix job green when the sticky lockfile comment can't post#149
Merged
Conversation
…t be posted The 'Comment/Clear sticky PR comment' steps are cosmetic housekeeping for the lockfile-hash warning. When the comment API rejects the call (observed: HTTP 401 on every fork PR run, twice reproduced on a rerun, while the nix build itself was green), the whole job reports failure — training reviewers to ignore a red nix check and masking real nix breakage. continue-on-error keeps the comment best-effort and lets the build result speak. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🔎 Lint report:
|
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
1 participant
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.
Why
Every fork PR currently shows a red
nix (ubuntu-latest)check even when the nix build is green: the final "Comment/Clear sticky PR comment" housekeeping steps fail with##[error]Requires authentication(reproduced on PRs #137 and #138 including a rerun), and the step failure fails the whole job —nix (macos-latest)then reports cancelled. A permanently red check trains everyone to ignore nix results and masks real breakage.What changed
.github/workflows/nix.yml—continue-on-error: trueon bothmarocchino/sticky-pull-request-commentsteps (the lockfile-hash warning comment and its clear-on-resolution counterpart). The lockfile check itself still fails the job when the hash is stale; only the cosmetic comment delivery becomes best-effort.How to review
continue-on-error: truewith a comment stating the rationale.hash_checkgating logic is untouched — a stale lockfile still reds the job via its own step.Evidence
nix (ubuntu-latest)job: build green end-to-end, thenClear sticky PR comment (resolved)401s and fails the job (https://github.com/OmarB97/hermes-agent/actions/runs/27288537304/job/80603128133); identical pattern on merged PR fix(desktop): hide sidebar timestamp while a session is active (orange dot is the cue) #137 and on a manual rerun.yaml.safe_loadparses the edited workflow.Verification
Risks / gaps
Collaborators