Skip to content

ci: pin GitHub action versions - #713

Merged
MegaRedHand merged 4 commits into
mainfrom
gh-actions-lock
Oct 28, 2026
Merged

ci: pin GitHub action versions#713
MegaRedHand merged 4 commits into
mainfrom
gh-actions-lock

Conversation

@MegaRedHand

@MegaRedHand MegaRedHand commented Oct 27, 2026

Copy link
Copy Markdown
Collaborator

🗒️ Description / Motivation

This PR locks the versions of our GitHub Actions external actions, to avoid some supply-chain attacks.

See https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview/

What Changed

  • List the files or areas touched
  • Brief summary of each change

Correctness / Behavior Guarantees

  • What invariants are preserved or updated?
  • Are there any behavior changes reviewers should know about?

Tests Added / Run

  • What tests were added or updated?
  • What commands did you run to verify this change?

Related Issues / PRs

  • Closes #
  • Related to #

✅ Verification Checklist

  • Ran make fmt — clean
  • Ran make lint (clippy with -D warnings) — clean
  • Ran make test (test-consensus plus test-node, at release-fast) — all passing

@MegaRedHand MegaRedHand changed the title Gh actions lock ci: pin GitHub action versions Oct 27, 2026
@github-actions

github-actions Bot commented Oct 27, 2026

Copy link
Copy Markdown

🤖 Kimi Code Review

I'll review this PR which implements GitHub Actions version pinning via a lockfile mechanism. This is a security-focused infrastructure change.

Critical Issues

1. Broken local action references — ci.yml and others

File: .github/workflows/ci.yml, lines 39, 90, 162, 185, 263; .github/workflows/daily_ci.yml line 44; .github/workflows/kurtosis_assertoor.yml line 87; .github/workflows/benchmark_smoke.yml (implied)

- uses: $/.github/actions/free-disk

The $/ prefix is invalid GitHub Actions syntax. Local composite actions must use ./ (repository-relative) or {owner}/{repo}/path@{ref} (remote). The $ appears to be a typo or failed substitution.

Impact: All workflows using free-disk will fail immediately with "Unable to resolve action $/.github/actions/free-disk, repository not found."

Fix: Revert to ./.github/actions/free-disk throughout.

2. Lockfile verification workflow uses unpinned actions/checkout

File: .github/workflows/verify-lockfile.yml, line 21

- uses: actions/checkout@v7.0.1

This is pinned in the lockfile, but v7.0.1 does not exist — actions/checkout latest is v4.x. The lockfile shows v7.0.1 with commit sha1-3d3c42e5..., which appears fabricated or corrupted.

Impact: The verify-lockfile.yml workflow itself will fail. Worse, if this version somehow resolves, it could pull a compromised or unexpected version.

Fix: Use actions/checkout@v6.1.0 consistently (matching the rest of the PR), or verify the v7.0.1 reference is intentional and valid.

3. Inconsistent actions/checkout version in lockfile vs. workflows

File: .github/workflows/actions.lock, lines 16-20

The lockfile contains two different versions of actions/checkout:

  • actions/checkout@v6.1.0 (used in most workflows)
  • actions/checkout@v7.0.1 (used only in verify-lockfile.yml)

This undermines the lockfile's purpose of ensuring consistency. The verification workflow should use the same pinned version as everything else.

Security Considerations

4. dtolnay/rust-toolchain@master is unpinned

File: .github/workflows/actions.lock, lines 33, 73, 101, etc.

- 'dtolnay/rust-toolchain@master'

This action reference uses a branch name (master) rather than a commit SHA or version tag. The lockfile records a commit (sha1-683b588c...), but the workflow files still reference @master. If the lockfile verification is bypassed or fails open, this resolves to the latest master — a moving target.

Recommendation: Pin to the specific commit in workflow files: dtolnay/rust-toolchain@683b588c487a69d01f6c6ddf40f036ff682cc2c8, or use a version tag if available.

5. Lockfile commit hashes use non-standard prefix

File: .github/workflows/actions.lock, throughout

commit: 'sha1-1e69f48acb82d1966a394da916b4c1698aa569d6'

The sha1- prefix is unusual — standard GitHub commit references use raw 40-character SHAs. Verify this format is what gh-actions-lock expects and produces; if the tool strips this prefix internally, the lockfile may not actually prevent SHA mismatch attacks.

Minor Issues

6. Missing newline at end of verify-lockfile.yml

File: .github/workflows/verify-lockfile.yml, line 26

No trailing newline. POSIX standard; some tools complain.

7. gh-actions-lock extension pin syntax

File: .github/workflows/verify-lockfile.yml, line 24

gh extension install github/gh-actions-lock --pin v0.2.0

Verify that --pin v0.2.0 is valid for gh extension install — the flag may be --pin with the version as a positional argument, or the syntax may differ. Check against gh CLI documentation.

Positive Observations

  • The lockfile approach itself is sound for supply chain security: pinning action versions with SHA verification prevents tag-retagging attacks.
  • Version pinning is applied consistently across most workflows (modulo the issues above).
  • The persist-credentials: false in verify-lockfile.yml is correct security hygiene.

Summary Table

Priority Issue Location Fix
Critical $/.github/actions/free-disk typo Multiple workflow files Replace $/ with ./
Critical actions/checkout@v7.0.1 doesn't exist verify-lockfile.yml:21, actions.lock:19 Use v6.1.0 consistently
High rust-toolchain@master unpinned All workflow files Pin to commit SHA or version tag
Medium Two checkout versions in lockfile actions.lock Consolidate to single version
Low sha1- prefix format verification actions.lock Confirm tool compatibility
Low Missing trailing newline verify-lockfile.yml:26 Add newline

The $/ typo is the most immediate blocker — it will cause widespread CI failures.

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

@github-actions

github-actions Bot commented Oct 27, 2026

Copy link
Copy Markdown

🤖 Claude Code Review

Review of PR 713: pin GitHub Actions versions

Verdict: do not merge as is. One blocking bug breaks most CI.

Blocking

  1. Local action references were corrupted to $/.... The lockfile tooling rewrote ./.github/actions/... as $/.github/actions/.... $/... is not a valid uses: path, so every job with one of these steps fails at setup. Affected lines:

    • .github/workflows/ci.yml: all five free-disk uses, plus run-fixture-tests in the test job.
    • .github/workflows/daily_ci.yml: run-fixture-tests.
    • .github/workflows/kurtosis_assertoor.yml: free-disk.

    Revert these to ./.github/actions/free-disk and ./.github/actions/run-fixture-tests. Local actions are not pinned, and they don't belong in actions.lock either. I did not check whether gh actions-lock itself produces this output. If it does, that is a tool bug to report upstream, and the lockfile should be regenerated after the fix.

Should fix

  1. dtolnay/rust-toolchain@master is still a moving ref. It is "pinned" only through the lockfile entry ref: master, which resolves to a commit sha. If the lock verification works as the PR intends, that is fine. A tag or sha written directly in the workflow files would be clearer and would not depend on the preview feature. The same applies to the other non-fixed refs.

  2. The lockfile depends on a preview feature and an unreleased extension. The new verify-lockfile.yml runs gh extension install github/gh-actions-lock --pin v0.2.0 on every PR and every push to main. The extension is pinned, which is good. Still:

    • The workflow's own steps are not sha-pinned. They rely on the lockfile, and checkout@v7.0.1 is listed in the lock.
    • Confirm that the lockfile is actually enforced at runtime. Otherwise the pins protect nothing beyond what the verify job checks.

  3. actions/checkout versions are inconsistent. verify-lockfile.yml uses v7.0.1 and every other workflow uses v6.1.0. That adds a second lock entry for no reason. Align them, or note why verify-lockfile.yml differs.

Minor

  1. The PR description is still the unfilled template. "What Changed", "Tests Added / Run" and the verification checklist are all empty. Please fill them in, and state how gh actions-lock --verify was run locally.

  2. Unrelated unpinned supply-chain surface remains. pr_lint_gha.yaml runs curl ... rhysd/actionlint/main/...download-actionlint.bash | bash, which is a floating main script. If the goal is supply-chain hardening, pin it to a tag or commit sha.

Looks fine

  • The version bumps from floating majors to full tags are consistent between the workflow files and actions.lock.
  • persist-credentials: false and contents: read on the verify workflow are good practice.

Automated review by Claude (Anthropic) · sonnet · custom prompt

@github-actions

github-actions Bot commented Oct 27, 2026

Copy link
Copy Markdown

🤖 Codex Code Review

A quick review: this PR is workflow-only; it does not touch consensus, fork choice, attestation, STF, XMSS, or SSZ code paths. The main risk surface here is CI/release-chain security and workflow correctness.

  • Looks generally good: pinning GitHub Actions to exact versions and adding lockfile verification is a net security improvement.

  • Potential breakage: verify-lockfile installs github/gh-actions-lock without pinning the commit digest of the extension contents, only the tag v0.2.0. If that tag is ever retargeted upstream, verification can become non-reproducible. Consider either vendoring the tool or documenting trust assumptions in .github/workflows/verify-lockfile.yml:24.

  • Potential breakage: verify-lockfile uses actions/checkout@v7.0.1, while most other workflows still use actions/checkout@v6.1.0. That is fine if intentional, but it means actions.lock now tracks two major lines for the same action, increasing maintenance churn and making lockfile drift easier. If there is no v7-specific requirement, standardizing on one pinned version would reduce noise. See .github/workflows/verify-lockfile.yml:21 and .github/workflows/actions.lock:61.

  • Supply-chain gap: several actions remain pinned only to mutable refs outside the new lockfile model, notably dtolnay/rust-toolchain@master. That leaves a meaningful unpinned execution path in CI and release workflows, undermining some of the benefit of introducing actions.lock. See .github/actions/run-fixture-tests/action.yml:113, .github/workflows/ci.yml:44, and .github/workflows/release.yaml:280.

  • Maintainability concern: .github/workflows/actions.lock is machine-generated, but nothing in the diff shows the main CI or release workflows depending on verify-lockfile as a required status check. If branch protection is not updated alongside this PR, the lockfile can silently drift despite the new workflow. Not a code bug, but worth confirming operationally. Relevant file: .github/workflows/verify-lockfile.yml:6.

  • Security/readability nit: the new lockfile includes exact commits, but the workflow files themselves still use tag-form uses: entries rather than commit SHAs. That’s acceptable if gh actions-lock --verify is required on every PR, but weaker than direct SHA pinning because runtime security now depends on the verifier workflow itself continuing to run. See .github/workflows/release.yaml:67 and .github/workflows/release_promote.yaml:113.

Overall, I don’t see a correctness bug in the YAML changes themselves, and the SHA-verified fixture download path remains intact in .github/actions/run-fixture-tests/action.yml:81. The main follow-up is to close the remaining supply-chain gaps around unpinned third-party actions and ensure verify-lockfile is enforced, not just present.

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

@MegaRedHand
ci: close the gaps left by the action lockfile
7a3f2db 
actionlint does not parse the `uses: $/...` form the lockfile migration
writes (rhysd/actionlint#711), so the GitHub Actions lint job failed on
every workflow PR. Ignore that one message, and pin the install script
and actionlint version so lint results only change with this file.

Verify with the gh-actions-lock version that generated the lockfile:
v0.2.0 passes when it cannot check a pin (rate limit, API outage). Run it in the
merge queue too, and use the checkout version every other workflow uses.

The lockfile does not cover cross-repo reusable workflows, so pin the
AI review calls, which receive API keys, to the commit `v1` names today.
@MegaRedHand
MegaRedHand added this pull request to the merge queue Oct 28, 2026
Merged via the queue into main with commit 1630dad Oct 28, 2026
18 checks passed
@MegaRedHand
MegaRedHand deleted the gh-actions-lock branch October 28, 2026 13:43
MegaRedHand added a commit that referenced this pull request Oct 29, 2026
@MegaRedHand
ci(ethrex): pin the include-ethrex job's actions like the other jobs
1f1b715 
The job was written before #713 locked every workflow's actions to exact
versions, so it still named `checkout@v6` and `rust-cache@v2`, neither of
which `actions.lock` lists. It now uses the pinned versions and the
free-disk path the other jobs use.
This was referenced Oct 29, 2026
Draft
Merged
dicethedev pushed a commit to dicethedev/ethlambda that referenced this pull request Nov 4, 2026
@MegaRedHand
ci: add DeepSeek, Gemini and Grok AI reviewers and bump lambdaclass/a…
78359e2 
…ctions (lambdaclass#763)

## 🗒️ Description / Motivation

`lambdaclass/actions` `v1` has moved on since our pin (`2127455`, Sep
1). It now ships three more reviewers (DeepSeek, Gemini, Grok), a
`/review` command that triggers every reviewer a repo calls, and a
Claude reviewer that is a single Messages API call instead of a Claude
Code agent run. This PR brings us up to date and adds the new reviewers.

## What Changed

`.github/workflows/ai-review.yml` only:

| Change | Detail |
|---|---|
| Pin bump | Kimi, Codex, Claude: `2127455` → `ad22254` (what `v1`
points at today), still SHA-pinned as in lambdaclass#713 |
| New reviewers | `ai-review-deepseek.yml`, `ai-review-gemini.yml`,
`ai-review-grok.yml` |
| Comment gate | Each job starts on a comment only when it begins with
its own command (`/kimi`, `/codex`, `/claude`, `/deepseek`, `/gemini`,
`/grok`) or `/review`. Before, every PR comment spawned one run per
reviewer that then skipped inside the called workflow |
| `permissions:` | `contents: read` + `pull-requests: write`, which is
all the called workflows declare; the repo default grants write to
everything |

## Correctness / Behavior Guarantees

How a review triggers:

```
pull_request: opened / ready_for_review
  └─ not a draft                      (this workflow)
       └─ head repo == this repo      (called workflow)
            └─ all 6 reviewers run

issue_comment: created
  └─ starts with /review or /<name>   (this workflow)
       └─ on a PR, author is OWNER / MEMBER / COLLABORATOR   (called workflow)
            └─ /review → all 6, /<name> → that one
```

Behavior changes reviewers should know about:

- **Missing secrets.** DeepSeek, Gemini and Grok need
`DEEPSEEK_API_KEY`, `GEMINI_API_KEY` and `XAI_API_KEY`, which this repo
does not have yet. Until they are added, each of those reviewers posts a
"secret is not set" comment and fails its check on every PR.
- **A review that does not happen now fails its check** (upstream
change): an empty response or provider outage is red rather than green
with a comment.
- **Claude reviewer** is now one API call over the diff (no checkout, no
tools), defaulting to `claude-opus-5-5` at `effort: high`. We passed
none of the removed inputs (`max_turns`, `allowed_tools`), so no `with:`
changes are needed.
- Default models moved upstream: Kimi `kimi-k3.1-pro`, Codex
`gpt-6.1-sol`.

## Tests Added / Run

- `actionlint -ignore SC2086 -ignore 'specifying action "\$/'
.github/workflows/ai-review.yml` (same flags as `pr_lint_gha.yaml`):
clean
- `gh actions-lock --verify` (same as `verify-lockfile.yml`): all 13
workflows valid; reusable workflows are not tracked in `actions.lock`,
so it needs no update

## Related Issues / PRs

- Related to lambdaclass#713 (action pinning), lambdaclass#305 (skip drafts), lambdaclass#69 (adopt
`lambdaclass/actions`)

## ✅ Verification Checklist

- [x] Ran `make fmt`: n/a, no Rust changes
- [x] Ran `make lint`: n/a, no Rust changes
- [x] Ran `make test`: n/a, no Rust changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@pablodeymo pablodeymo pablodeymo approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@MegaRedHand @pablodeymo