Add workflow_dispatch trigger for manual CI runs with secrets#1102
Conversation
Fork PRs from external contributors run without repo secrets, so CI cannot exercise flows that need ENVIO_API_TOKEN etc. Add a manual trigger that accepts an explicit commit SHA and pins every checkout to it. Only users with write access can dispatch this workflow, and the pinned SHA prevents a mid-run force-push on the fork from swapping code into the run. Covers all existing suites: build, cargo tests, template tests, scenarios tests, and e2e tests.
📝 WalkthroughWalkthroughAdded a Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant GH as GitHub Actions
participant Validator as validate-dispatch-sha
participant Job as Build/Test Job
participant Checkout as actions/checkout
User->>GH: Trigger workflow_dispatch with `sha` input
GH->>Validator: Run validation job (checks 40-hex SHA only on dispatch)
Validator-->>GH: pass/fail
GH->>Job: Start job (depends on Validator)
Job->>Checkout: Checkout repo with `ref: inputs.sha || github.sha`
Checkout-->>Job: Repo at requested ref
Job->>Job: Execute build/test steps
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build_and_verify.yml:
- Around line 35-37: The workflow uses "ref: ${{ inputs.sha || github.ref }}"
which allows mutable branch/PR refs to be checked out; change each occurrence
(the checkout step using the with: ref input) to use the event SHA fallback
instead, i.e., use "ref: ${{ inputs.sha || github.sha }}" so jobs remain pinned
to the event commit; update all instances matching the pattern (the checkout
step with ref: ${{ inputs.sha || github.ref }}) throughout the file.
- Around line 8-18: The workflow_dispatch input "sha" allows mutable refs in its
description and lacks validation; update the description under
workflow_dispatch.inputs.sha to state it must be an immutable 40-character hex
commit SHA (not refs/pull/<N>/head), and add an "pattern" validation entry for
the sha input (regex: ^[0-9a-fA-F]{40}$) so GitHub will reject non-immutable
values; locate the workflow_dispatch.inputs.sha block in the file and change the
description string and add the pattern field accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 18842503-703c-4de2-a374-404dc709ccf9
📒 Files selected for processing (1)
.github/workflows/build_and_verify.yml
| # Manual trigger for running full CI (with repo secrets) against a specific | ||
| # commit — e.g. a fork PR from an external contributor whose runs would | ||
| # otherwise execute without secrets. Only users with write access to this | ||
| # repo can dispatch this workflow. The provided SHA is pinned at checkout | ||
| # time so a mid-run force-push on the fork cannot swap code under us. | ||
| workflow_dispatch: | ||
| inputs: | ||
| sha: | ||
| description: "Exact commit SHA to run CI against (paste from the PR; must be reachable, e.g. via refs/pull/<N>/head)" | ||
| required: true | ||
| type: string |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does actions/checkoutacceptrefs/pull//headasref, and can that ref change via force-push between jobs in the same workflow run?
💡 Result:
Yes, actions/checkout accepts refs/pull/<N>/head as the ref input. Multiple sources, including the official README and various issues/PRs in the actions/checkout repository, confirm that users can specify ref: refs/pull/${{ github.event.number }}/head to check out the PR head commit instead of the default merge commit. Recent updates (PRs #1774 and #1924, merged in 2024) explicitly improved support for checking out such refs by falling back to commit SHAs if needed. Yes, that ref can change via force-push between jobs in the same workflow run. refs/pull/N/head is a server-side Git ref maintained by GitHub that always points to the current HEAD commit of the PR's head branch. When the head branch is force-pushed (common during rebases or amends), GitHub updates refs/pull/N/head to the new commit SHA, triggering a synchronize event and new workflow runs. Within a single workflow run (triggered by one event), all jobs receive the same fixed event payload (including github.sha and github.event.pull_request.head.sha at trigger time), so checkouts in later jobs using ref: refs/pull/N/head will fetch the potentially updated ref from the server. Evidence includes: GitHub's head_ref_force_pushed event documentation; issues noting async ref updates (e.g., Buildkite agent retries); and checkout issues where PR refs reflect current state. While workflows use event-frozen SHAs by default, explicitly using the dynamic ref fetches the live state, allowing changes to be observed across jobs if a force-push occurs mid-run (rare, as it requires workflow_run or manual triggers, but possible in matrix/dependent jobs).
Citations:
- 1: Cannot use parent specifiers in the ref actions/checkout#61
- 2: https://github.com/actions/checkout
- 3: https://github.com/actions/checkout/blob/v4/README.md
- 4: https://github.com/actions/checkout/blob/main/action.yml
- 5: https://github.com/actions/checkout/pull/1774](https:/redirect.github.com/actions/checkout/pull/1774)
- 6: https://github.com/actions/checkout/pull/1924](https:/redirect.github.com/actions/checkout/pull/1924)
- 7: Gracefully Handle Missing GitHub PR refs/pull/%s/head in Checkout buildkite/agent#3294
- 8: head_ref_force_pushed event documentation github/docs#14910
- 9: on pull request, checkout@v2 built some ref other than the one that was claimed actions/checkout#237
- 10: https://stackoverflow.com/questions/78732301/how-to-force-github-to-update-a-pr-merge-branch
🏁 Script executed:
cat -n .github/workflows/build_and_verify.ymlRepository: enviodev/hyperindex
Length of output: 11843
Update description and validate manual sha input as immutable commit SHA
The description at line 16 suggests refs/pull/<N>/head as a valid input, but that's a mutable ref that can change via force-push between jobs. Per the stated goal, only immutable commit SHAs should be accepted. Add validation to enforce 40-character hex format and update the description to be explicit.
Suggested patch
- description: "Exact commit SHA to run CI against (paste from the PR; must be reachable, e.g. via refs/pull/<N>/head)"
+ description: "Exact 40-character commit SHA to run CI against (immutable)."+ - name: Validate workflow_dispatch sha
+ if: ${{ github.event_name == 'workflow_dispatch' }}
+ run: |
+ [[ "${{ inputs.sha }}" =~ ^[0-9a-fA-F]{40}$ ]] || {
+ echo "::error::inputs.sha must be a 40-character commit SHA"
+ exit 1
+ }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/build_and_verify.yml around lines 8 - 18, The
workflow_dispatch input "sha" allows mutable refs in its description and lacks
validation; update the description under workflow_dispatch.inputs.sha to state
it must be an immutable 40-character hex commit SHA (not refs/pull/<N>/head),
and add an "pattern" validation entry for the sha input (regex:
^[0-9a-fA-F]{40}$) so GitHub will reject non-immutable values; locate the
workflow_dispatch.inputs.sha block in the file and change the description string
and add the pattern field accordingly.
…ommit Address review feedback on PR #1102: 1. Fallback was `github.ref` (mutable branch/PR-merge pointer) which could cause different jobs in the same run to see different commits if the ref advanced mid-run. Switch to `github.sha` so automatic runs stay pinned to the event commit, matching default checkout behavior. 2. Dispatch input description suggested passing reachable refs like refs/pull/<N>/head, which are mutable. Tighten wording to require an immutable 40-character commit SHA, and add a regex validation step in each root job that rejects non-SHA input fast.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build_and_verify.yml (1)
34-43: Consider centralizing SHA validation to avoid future drift.The same validation script is duplicated in three jobs. A small dedicated
validate-dispatch-shajob (with downstreamneeds) would keep this policy in one place.Also applies to: 130-139, 165-174
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build_and_verify.yml around lines 34 - 43, Introduce a single reusable job named validate-dispatch-sha that centralizes the SHA validation logic (the existing bash snippet that tests inputs.sha against ^[0-9a-fA-F]{40}$ and emits an error), replace the duplicated validation steps in the other jobs with dependencies (use needs: [validate-dispatch-sha]) so they only run after the centralized validation, and remove the duplicated run blocks; ensure the new job exports any necessary outputs or uses workflow_dispatch inputs.sha directly so downstream jobs no longer repeat the regex check.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/build_and_verify.yml:
- Around line 34-43: Introduce a single reusable job named validate-dispatch-sha
that centralizes the SHA validation logic (the existing bash snippet that tests
inputs.sha against ^[0-9a-fA-F]{40}$ and emits an error), replace the duplicated
validation steps in the other jobs with dependencies (use needs:
[validate-dispatch-sha]) so they only run after the centralized validation, and
remove the duplicated run blocks; ensure the new job exports any necessary
outputs or uses workflow_dispatch inputs.sha directly so downstream jobs no
longer repeat the regex check.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: da7e1184-9fd6-47b6-b897-4c091c05a395
📒 Files selected for processing (1)
.github/workflows/build_and_verify.yml
Replace the three duplicated inline validation steps with a single `validate-dispatch-sha` job that all independent root jobs depend on. The gate job runs on every event (succeeding trivially outside of workflow_dispatch), which lets downstream jobs use a plain `needs:` without the awkward `if:` dance required to distinguish "skipped" from "failed" dependencies.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build_and_verify.yml (1)
57-57: Optional DRY cleanup for repeated checkout ref expression.You can reduce maintenance drift by centralizing the expression once and reusing it in all checkout steps.
♻️ Optional refactor
env: CARGO_TERM_COLOR: always ENVIO_API_TOKEN: ${{ secrets.ENVIO_API_TOKEN }} FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true + CHECKOUT_REF: ${{ inputs.sha || github.sha }}- ref: ${{ inputs.sha || github.sha }} + ref: ${{ env.CHECKOUT_REF }}Also applies to: 104-104, 143-143, 168-168, 187-187, 233-233, 313-313
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build_and_verify.yml at line 57, Repeated checkout ref expressions use `${{ inputs.sha || github.sha }}` in multiple checkout steps; centralize this by defining a single variable (for example `checkout_ref`) at the workflow or job level (under `env:` or `defaults:`) set to `${{ inputs.sha || github.sha }}` and then replace each `ref: ${{ inputs.sha || github.sha }}` in the checkout steps with `ref: ${{ env.checkout_ref }}` (or `ref: ${{ vars.checkout_ref }}` depending on where you define it) so all occurrences (including the ones noted) reference the single authoritative symbol.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/build_and_verify.yml:
- Line 57: Repeated checkout ref expressions use `${{ inputs.sha || github.sha
}}` in multiple checkout steps; centralize this by defining a single variable
(for example `checkout_ref`) at the workflow or job level (under `env:` or
`defaults:`) set to `${{ inputs.sha || github.sha }}` and then replace each
`ref: ${{ inputs.sha || github.sha }}` in the checkout steps with `ref: ${{
env.checkout_ref }}` (or `ref: ${{ vars.checkout_ref }}` depending on where you
define it) so all occurrences (including the ones noted) reference the single
authoritative symbol.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 228ecd3f-3651-45d1-b461-91e33965806c
📒 Files selected for processing (1)
.github/workflows/build_and_verify.yml
Summary
This PR adds support for manually triggering the CI workflow against a specific commit SHA, enabling full CI runs (with repository secrets) against fork PRs from external contributors.
Key Changes
workflow_dispatchtrigger to the build and verify workflow with a requiredshainput parametergithub.reffor automatic runsImplementation Details
shainput accepts an exact commit SHA that must be reachable (e.g., viarefs/pull/<N>/head)ref: ${{ inputs.sha || github.ref }}to conditionally checkout the specified commit or default referenceThis enables maintainers to safely run the full CI pipeline (including secrets) against external contributor PRs without compromising security.
https://claude.ai/code/session_01MhPxBQUALtaEydgmDXd6X4
Summary by CodeRabbit