Skip to content

fix(ci): repin standards reusables to a commit that has a lockfile - #82

Merged
hyperpolymath merged 1 commit into
mainfrom
fix/repin-standards-reusables-to-lockfile-head
Aug 27, 2026
Merged

fix(ci): repin standards reusables to a commit that has a lockfile#82
hyperpolymath merged 1 commit into
mainfrom
fix/repin-standards-reusables-to-lockfile-head

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Pilot for an estate-wide repin. See hyperpolymath/standards#657.

Every workflow here calls a standards reusable pinned to a commit with no lockfile:

pinned SHA date actions.lock
81dbf2dd 2026-07-21 ❌ none
892497fe 2026-08-12 ❌ none
84355587 (HEAD) 2026-08-27 11,754 B, 38 workflows onboarded

GitHub's Workflow Dependency Locking (public preview, no changelog entry) rejects a run when the callee at the pinned SHA is not covered by a lockfile — at startup_failure, with zero jobs and nothing in REST or GraphQL. The reason exists only in the run-page banner.

That requirement is unsatisfiable at either stale SHA, because no lockfile existed anywhere in standards on either date. Repinning to HEAD is the fix. Hand-adding entries to this repo's lockfile is not — it addresses only the first line of the rejection, never the second.

Verified before pushing: 0 residual references to either stale SHA.

🤖 Generated with Claude Code

Every workflow here calls a standards reusable pinned to a commit with NO
.github/workflows/actions.lock:

    81dbf2dd  2026-07-21  no lockfile
    892497fe  2026-08-12  no lockfile
    84355587  HEAD        lockfile present, 11754 bytes, 38 workflows onboarded

GitHub's Workflow Dependency Locking (public preview) rejects a run when
the callee at the pinned SHA is not covered by a lockfile. It does so at
startup_failure - zero jobs, no logs, no annotations in REST or GraphQL.
The reason is visible only in the run page banner:

    Workflow must use a lockfile. Run "gh actions pin" to generate one.
    The following workflows are missing a lockfile:
      - .github/workflows/governance.yml
      - hyperpolymath/standards@81dbf2dd

That requirement can never be satisfied at 81dbf2dd or 892497fe, because
no lockfile existed anywhere in standards on either date. Repinning to
HEAD is the fix; hand-adding entries to this repo's own lockfile is not,
because it addresses only the first line of the message.

(Note: "gh actions pin" is not a released command - it is an open RFC,
cli/cli#13314. The shipped tool is the gh actions-lock extension. The
server's own error text names a command that has never existed.)

Pilot for an estate-wide repin. Verified before pushing: 0 residual
references to either stale SHA.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@hyperpolymath
hyperpolymath force-pushed the fix/repin-standards-reusables-to-lockfile-head branch from f5d4a5c to 75cd6d1 Compare August 27, 2026 00:25
@gitar-bot

gitar-bot Bot commented Aug 27, 2026

Copy link
Copy Markdown

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

Gitar

@hyperpolymath
hyperpolymath merged commit 3932770 into main Aug 27, 2026
@hyperpolymath
hyperpolymath deleted the fix/repin-standards-reusables-to-lockfile-head branch August 27, 2026 00:26
@sonarqubecloud

Copy link
Copy Markdown

@coderabbitai

coderabbitai Bot commented Aug 27, 2026

Copy link
Copy Markdown

Review Change Stack

Caution

Review failed

The head commit changed during the review from f5d4a5c to 75cd6d1.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown
Contributor

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

Run reviewer

TIP This summary will be updated as you push new changes.

@codacy-production codacy-production Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

The PR repins reusable workflows to a commit SHA that includes an actions.lock file, ensuring compliance with GitHub's dependency locking policy. This change is necessary to prevent workflow initialization failures (startup_failure). Codacy reports that the PR is up to standards with no new quality issues. No security flaws or major logic bugs were identified. Verification is required to ensure all workflow references are updated and that the modified pipelines execute successfully.

Test suggestions

  • Verify all CI workflow files in the repository have been updated to the correct SHA via static analysis or linting.
  • Trigger a manual or push-based CI run for each modified workflow to verify successful initialization and execution.
  • Scan the entire repository for the old workflow versions to ensure complete removal.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify all CI workflow files in the repository have been updated to the correct SHA via static analysis or linting.
2. Trigger a manual or push-based CI run for each modified workflow to verify successful initialization and execution.
3. Scan the entire repository for the old workflow versions to ensure complete removal.

TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback

hyperpolymath added a commit that referenced this pull request Aug 27, 2026
…83)

Pilot for the estate remediation of GitHub **Workflow Dependency
Locking**. See `hyperpolymath/standards#657`.

Four steps, in this order, because each blocks the next.

**1. `workflow-linter.yml` was unparseable.**
```yaml
permissions: read-all
  actions: read        # <- mapping indented under a scalar
```
Blind-`permissions:`-insertion damage. The consequence reaches far past
the one file: **`gh actions-lock` refuses to run when ANY workflow in
the repo fails to parse**, so the repo can never acquire a lockfile, so
every workflow that needs one stays dead. One broken file kills the
repo.

**2. Generated the lockfile** with `gh actions-lock` v0.1.6.

**3. The generated lockfile was PARTIAL — 10 of 15.** The five omitted
are exactly the reusable-workflow callers; the tool emits no entries for
them. Hand-added each as `'<path>': []`.

⚠️ This is the estate-wide trap: **a partial lock is worse than none.**
Measured across 218 repos, `P(startup_failure | has lock) = 91.7%` vs
`15.8%` without — because every workflow the lock *omits* is rejected.
Running `gh actions-lock` and stopping there is how 55 repos got into
that state.

**4. The tool restamps its banner above line 1**, displacing the SPDX
header that the workflow-security linter greps with `head -1`. Restored
in 14 files; `main-estate-audit.yml` had none at all, so one was
authored (MPL-2.0, Rule 1 default — a new header, not a relicensing, so
A2 is not engaged).

**Verified before pushing:** 0 unparseable workflows · SPDX on line 1 in
**15/15** · lockfile covers **15/15**, no omissions.

Follows #82, which repinned the `standards` callee off a pre-lockfile
SHA and removed the other half of the rejection.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant