Skip to content

chore(claude-lanes): re-pin callers to ci-workflows v0.39.8 - #748

Closed
melodic-claude-lanes-repin[bot] wants to merge 1 commit into
mainfrom
chore/repin-claude-lanes
Closed

melodic-claude-lanes-repin[bot] wants to merge 1 commit into
mainfrom
chore/repin-claude-lanes

Conversation

@melodic-claude-lanes-repin

@melodic-claude-lanes-repin melodic-claude-lanes-repin Bot commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

No related issue: automated re-pin to the newest ci-workflows release

Summary

Re-pins every melodic-software/ci-workflows reference under
components/claude-lanes/ and components/claude-lanes-hosted/,
the managed-files-guard caller components, and this repository's own sync-family callers from
v0.39.3
to v0.39.8
(594987abe8657a40bccc13d301f1f0d5cccb5348), the newest ci-workflows
release. Opened by .github/workflows/maintenance-repin-ci-workflows.yml.

Fix

Same major version as the pin it replaces (v0.39.3 to v0.39.8).

Warning

Runner-policy lockstep requires a human. melodic-software/ci-workflows/.github/workflows/pr-review.yml melodic-software/ci-workflows/.github/workflows/pr-review.yml credentialReferences changed between revisions (from ab83b01); melodic-software/ci-workflows/.github/workflows/pr-review-security.yml melodic-software/ci-workflows/.github/workflows/pr-review-security.yml credentialReferences changed between revisions (from ab83b01); melodic-software/ci-workflows/.github/workflows/maintenance-sync-standards.yml old revision job sync references needs in a routing-relevant field, which cannot be safely diffed for auto-approval (from ab83b01). Before merging, register one approvedReusableWorkflowContracts entry for each declined workflow named above, add the rollout record in components/runner-policy/README.md, and add REPINE_LANE_SHA_V0_39_8 plus a verbatim copy-forward assertion in components/runner-policy/runner-policy.test.mjs (same shape as the v0.25.0 registration, PR #589). This pull request is never auto-merged.

Merging this cascades: maintenance-sync-standards.yml re-materializes the callers
into every target distribution/sync-manifest.yml marks a lane
caller (fleet or hosted) or a managed-files-guard caller
managed for, as a reviewed pull
request per target. This pull request is never auto-merged.

Verification

  • pin-comment-convention covers components/claude-lanes/*.yml
    and validates the rewritten pin comments' form.
  • claude-lanes component tests materialize and lint the callers.
  • runner-policy lints and tests pass when lockstep applied
    (policy-lockstep=manual).
  • Post-merge: the per-target sync pull requests are the real
    acceptance signal.

Related

@melodic-claude-lanes-repin melodic-claude-lanes-repin Bot changed the title chore(claude-lanes): re-pin callers to ci-workflows v0.39.5 chore(claude-lanes): re-pin callers to ci-workflows v0.39.7 Oct 9, 2026
kyle-sexton added a commit that referenced this pull request Oct 10, 2026
## Related

Refs: melodic-software/ci-workflows#726
Refs: #748

Precedents: #742 (v0.39.3 contracts), #746 (retirement).

## Fix

Registers the nine ci-workflows reusables at the v0.39.8 tag
`594987abe8657a40bccc13d301f1f0d5cccb5348` in
`components/runner-policy/policy.json`. This unblocks the claude-lanes
repin in #748, whose policy lockstep declined, and the ci-runner repin,
whose pin tests need one SHA across every ci-workflows reference. The
v0.39.3 (`ab83b01`) entries stay until every consumer has repinned.

- `policy.json`: nine new keys, each spliced in as text after its
`ab83b01` entry (121 insertions, 0 deletions). No `workflow_call` input,
secret, workflow or job permission, or `runs-on` routing changed between
v0.39.3 and v0.39.8, so each contract equals its v0.39.3 entry.
- `README.md`: rollout note for v0.39.8.
- `runner-policy.test.mjs`: `REPINE_LANE_SHA_V0_39_8` and a copy-forward
assertion that each v0.39.8 entry equals its v0.39.3 entry and that
exactly nine v0.39.8 keys exist.

| Reusable | Change since v0.39.3 | Lockstep result |
| --- | --- | --- |
| `intake-label-needs-triage.yml` | none, blob identical | unchanged |
| `pr-scan-dependencies.yml` | none, blob identical | unchanged |
| `pr-audit-workflows.yml` | none, blob identical | unchanged |
| `pr-automerge-dependabot.yml` | none, blob identical | unchanged |
| `intake-triage.yml` | `claude-code-action` v1.0.241 to v1.0.245
(`6fed3ca`) | declined: `credentialReferences` |
| `pr-review.yml` | same bump, plus rate-limit summary wording |
declined: `credentialReferences` |
| `pr-review-security.yml` | same bump, plus rate-limit summary wording
| declined: `credentialReferences` |
| `maintenance-sync-standards.yml` | `setup-node` v7.0.0 to v7.1.0
(`949feb2`) | declined: `sync` job routes through `needs` |
| `pr-run-checks.yml` | blob identical; `$/markdownlint` takes the
`setup-node` bump | declined: commit-relative reference changed |

"unchanged" means the comparison found the surface unchanged. Because
any decline suppresses every lockstep write, all nine entries were
registered by hand, and the five declined ones were reviewed against the
v0.39.8 file content. `$/report-lane-outcome`, which the claude lanes
reach, changes only its rate-limit error message.

## Verification

- `laneSecuritySurfacesMatch` from `repin-policy-lockstep.mjs`, run
without writes for all nine paths from `ab83b01` to `594987a`, gave the
results in the table.
- Each v0.39.8 file's `workflow_call` surface (inputs, secrets, workflow
and job permissions, `runs-on`) was parsed and compared with v0.39.3:
unchanged for all nine.
- `npm run test:runner-policy` (298/298), `npm run lint:runner-policy`,
biome, markdownlint and the lefthook pre-commit all pass.

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

https://claude.ai/code/session_01TRhsMPSTMFo99ik7gkdgQt

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: claude-lanes-repin <noreply@github.com>
@melodic-claude-lanes-repin melodic-claude-lanes-repin Bot changed the title chore(claude-lanes): re-pin callers to ci-workflows v0.39.7 chore(claude-lanes): re-pin callers to ci-workflows v0.39.8 Oct 11, 2026
kyle-sexton added a commit that referenced this pull request Oct 11, 2026
…t ci-workflows v0.40.0 (#773)

No related issue: Phase 17 of the pr-unblock lane plan; ci-workflows
v0.40.0

Hold: a human merges this.

## Summary

ci-workflows v0.40.0 (`a92020292976c2e9b50f7adc922693a45a6c1226`) adds
an optional `allowed-bot-sender-ids` input to `pr-review.yml` and
`pr-review-security.yml`. A bot whose event sender id is listed passes
the reusable's bot skip, and only that sender's login reaches the
action's `allowed_bots`. This registers that input in runner policy and
has the four review caller components pass the automation-lanes App's
id, so a commit the App pushes to a pull request is reviewed.

## Fix

- `components/runner-policy/policy.json`: `pr-review.yml` and
`pr-review-security.yml` at the v0.40.0 tag, each equal to its v0.39.8
entry plus `allowed-bot-sender-ids` in `allowedInputs`. Only these two
reusables are registered at v0.40.0.
- `components/claude-lanes/claude-{review,security-review}.yml` and
`components/claude-lanes-hosted/claude-{review,security-review}.yml`:
re-pinned from v0.39.3 to v0.40.0, passing `allowed-bot-sender-ids: ${{
vars.AUTOMATION_LANES_APP_SENDER_ID }}`; header comments updated.
- `components/runner-policy/README.md`: rollout note for v0.40.0.
- `components/runner-policy/runner-policy.test.mjs`:
`REPINE_LANE_SHA_V0_40_0` and a test that each v0.40.0 entry is its
v0.39.8 entry plus the input, and that exactly two v0.40.0 keys exist.

Upstream diff v0.39.8 to v0.40.0 for both reusables: the new input, the
job `if:` (bot actor admitted only when the input is non-empty,
well-formed, and contains the sender id), and `allowed_bots`. No secret,
workflow or job permission, `runs-on`, or reached composite action
changed. The claude-lanes lockstep declines both on `inputs`, so the
entries are registered by hand. Moving from v0.39.3 also takes the
v0.39.8 changes reviewed in #762.

### Consumers without the variable

The manifest syncs these components to 11 targets. Hosted callers:
agent-plugins, ci-runner, claude-code-account-rotation,
claude-code-plugins, codex-plugins, cursor-plugins. Fleet callers:
claude-code-proxy, dotfiles, github-iac, medley, provisioning. Only
`claude-code-plugins` sets the repository variable
`AUTOMATION_LANES_APP_SENDER_ID`, and no org-level variable exists
(checked with `gh api
.../actions/variables/AUTOMATION_LANES_APP_SENDER_ID` on each). GitHub
returns an empty string for an unset configuration variable ([contexts
reference,
`vars`](https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#vars-context)),
and the reusable's `if:` requires a non-empty list, so in the other 10
targets the review lanes still skip every bot.

## Verification

- `npm run test:runner-policy`: 299/299 pass. With
`allowed-bot-sender-ids` removed from one v0.40.0 contract, 5 tests
fail: the new test and the four target-audit tests for the lane callers.
- `npm run lint:runner-policy`: passed.
- `claude-lanes.test.sh` (materialize into every target plus
actionlint), `repin-callers.test.sh`, `repin-policy-lockstep.test.mjs`
(23/23), and the pin-comment scan: pass.
- Lefthook pre-commit (editorconfig, typos, markdownlint, gitleaks,
biome): pass.

## Related

- Upstream release:
https://github.com/melodic-software/ci-workflows/releases/tag/v0.40.0
- Contract precedent: #762 (v0.39.8). #748 (the automated v0.39.8
re-pin) touches the same four caller pins and will conflict with this
one.
- After merge, the standards sync carries the callers and `policy.json`
to the targets.

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

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
@kyle-sexton

Copy link
Copy Markdown
Member

Superseded by #773, which re-pinned these callers to ci-workflows v0.40.0.

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