mirror of
https://gitea.com/gitea/act_runner.git
synced 2026-06-29 23:55:26 +00:00
b7f6b6d90a
## Summary A nested `uses:` action inside a **local composite action** fails to clone with a bare `authentication required: Unauthorized` (401) when the instance resolves host-less action references against itself (`DEFAULT_ACTIONS_URL = self`). The job fails at the composite **main→post boundary**, even though the composite's own steps and all post-steps report success. ## Root cause `newCompositeRunContext` nils `Config.Secrets` so composite steps do not see job secrets. But the action-clone path in `prepareActionExecutor` sourced its token via `getGitCloneToken` → `Config.GetToken()` → `Config.Secrets`, which is empty inside a composite RunContext. The nested action is therefore cloned anonymously → 401 against the authenticated instance. Two details explain the exact symptom: - It surfaces at the composite **main→post boundary** because the swallowed nested-step error is re-emitted by `common.JobError` at the end of the composite main pipeline. - It carries **no clone URL** because, on a warm action cache, only `r.Fetch` runs (not `PlainClone`), and the go-git fetch error is returned verbatim. ## Fix Source the clone token from `github.Token` instead of `Config.Secrets`. It is preserved across the composite config copy (`Config.Token` / `PresetGitHubContext`) and is identical to `Config.GetToken()` at the top level, so top-level and `act exec` behaviour is unchanged. The `shouldCloneURLUseToken` host gate is kept so the token is never sent to a foreign host. This also aligns the git-clone path with the ActionCache fetch path, which already uses `github.Token`. Reusable workflows are unaffected — their RunContext keeps `Config.Secrets`. ## Before / after Local composite action with a nested `uses:` (+ post step), followed by a marker step. Same workflow, same runner host — only the runner fix differs. | Job step | Before fix | After fix | | --- | --- | --- | | `Run actions/checkout@v6` | ✅ success | ✅ success | | `Run ./.gitea/actions/probe-composite` (nested `uses:` + post) | ❌ **failure** — bare 401 at the main→post boundary | ✅ success | | `Step after composite` | ⊘ **skipped** | ✅ **ran** | | Job result | ❌ **failed** | ✅ **succeeded** | ### Before — boundary log ```text ::endgroup:: ##[error]authentication required: Unauthorized ← bare 401, no clone target Run Post ./.gitea/actions/probe-composite Success - Post ./.gitea/actions/probe-composite ← post steps run and succeed Success - Post actions/checkout@v6 Job failed ``` The composite's own steps and both post-steps report `Success`; the job fails solely on the bare 401 emitted at the main→post boundary, and the next step is skipped. ### After — boundary log ```text Run ./.gitea/actions/probe-composite ...composite steps... Success - ./.gitea/actions/probe-composite Run Marker after composite PASSED composite boundary — no 401 (runner fix confirmed) Success - Marker after composite Job succeeded ``` ## Reproduction `.gitea/actions/probe-composite/action.yml`: ```yaml name: probe-composite runs: using: composite steps: - uses: actions/setup-node@v6 # nested uses → has a post step with: { node-version: 22 } - run: echo "composite inner step OK" shell: bash ``` `.gitea/workflows/probe.yaml`: ```yaml on: [push] jobs: composite-boundary: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: ./.gitea/actions/probe-composite - run: echo "step after composite" # skipped before the fix; runs after ``` ## Verification - **Before:** bare 401 at the boundary, reproduced with a `delay=0` tail — rules out a token-TTL / expiry effect; it is a missing credential. - **After:** the composite step succeeds, the step after the composite runs, the job succeeds, and there is no `authentication required` in the log. - A reusable workflow (`workflow_call`) with the same nested `uses:` + post step never hit the 401, which isolated the bug to the composite main/post path. ## Tests Adds `TestStepActionRemoteCloneTokenSurvivesNilSecrets` (`act/runner`): asserts the clone token is forwarded when the RunContext mirrors a composite (`Secrets == nil`, token via `Config.Token`), and that the host gate still withholds the token for a foreign host. Verified to fail without the fix and pass with it. --------- Reviewed-on: https://gitea.com/gitea/runner/pulls/1041 Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com> Co-authored-by: Christian Heim <christian@heimdaheim.de> Co-committed-by: Christian Heim <christian@heimdaheim.de>