Summary
The workflow-src relocation introduced in PR #344 (fixing #343,
"workflow-src checkout pollutes the caller's tree during mutation
runs") moves the checked-out workflow source from
${GITHUB_WORKSPACE}/workflow-src to ${RUNNER_TEMP}/workflow-src
part-way through the job, via mv "${WORKFLOW_DIR}" "${dest}".
Local composite actions invoked earlier via a path under the
original workflow-src location (for example
./workflow-src/.github/actions/setup-rust, which wraps
actions-rust-lang/setup-rust-toolchain) still resolve their
post/cleanup step against the original path. Once the directory has
been moved away, the post step cannot find action.yml and the job
is marked failed — even though the actual work (mutation testing,
report upload) completed successfully.
Observed
leynos/ddlint scheduled mutation run
29676782845
(2026-07-19, ~98 minutes) shows the mutants job's "Run mutation
testing" and "Upload mutation report" steps both succeeding — the
run completed all 1061 mutants (150 missed, 358 caught, 533
unviable, 20 timeouts) and uploaded mutation-report-root-0
successfully. Immediately afterwards, the "Post Setup Rust" step
fails:
2026-07-19T08:17:11.5206720Z ##[error]Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under
'/home/runner/work/ddlint/ddlint/workflow-src/.github/actions/setup-rust'. Did you forget to run
actions/checkout before running your local action?
This is the only failing step in the job; it happens after the
"Relocate workflow source" step has already mv'd
workflow-src out of the workspace into $RUNNER_TEMP. The job,
and therefore the whole run, is reported as a failure despite having
produced a complete, valid mutation report.
Impact
Every scheduled mutation run that uses a local composite action
under workflow-src with its own post/cleanup step (at minimum
setup-rust, since actions-rust-lang/setup-rust-toolchain saves
the Cargo/rustup cache in its post step) will report as failed once
PR #344's relocation lands, regardless of whether the mutation
testing itself succeeded. This defeats the purpose of #343's fix:
callers now get a clean tree but a red, unreliable run status, and
the toolchain cache is presumably never saved because the post step
aborts before running its own logic.
Suggested fix
Either:
- keep
workflow-src in place until all steps (including composite
action post steps) that depend on it have finished, and relocate
it only immediately before the mutation tool itself runs, restoring
it (or a symlink) afterwards for cleanup purposes; or
- avoid invoking local composite actions that have their own post
steps via a path inside the relocatable workflow-src tree — e.g.
call setup-rust before checking out/relocating workflow-src, or
vendor a copy outside the relocated directory; or
- set
continue-on-error is not appropriate here since it would mask
genuine failures — prefer fixing the path lifecycle so the post
step resolves correctly.
Whichever approach is chosen, add a regression check (or contract
test, per #362) asserting that a job using
setup-rust inside a mutation workflow finishes green end-to-end,
not just that the mutation step itself succeeds.
Summary
The
workflow-srcrelocation introduced in PR #344 (fixing #343,"workflow-src checkout pollutes the caller's tree during mutation
runs") moves the checked-out workflow source from
${GITHUB_WORKSPACE}/workflow-srcto${RUNNER_TEMP}/workflow-srcpart-way through the job, via
mv "${WORKFLOW_DIR}" "${dest}".Local composite actions invoked earlier via a path under the
original
workflow-srclocation (for example./workflow-src/.github/actions/setup-rust, which wrapsactions-rust-lang/setup-rust-toolchain) still resolve theirpost/cleanup step against the original path. Once the directory has
been moved away, the post step cannot find
action.ymland the jobis marked failed — even though the actual work (mutation testing,
report upload) completed successfully.
Observed
leynos/ddlint scheduled mutation run
29676782845
(2026-07-19, ~98 minutes) shows the
mutantsjob's "Run mutationtesting" and "Upload mutation report" steps both succeeding — the
run completed all 1061 mutants (150 missed, 358 caught, 533
unviable, 20 timeouts) and uploaded
mutation-report-root-0successfully. Immediately afterwards, the "Post Setup Rust" step
fails:
This is the only failing step in the job; it happens after the
"Relocate workflow source" step has already
mv'dworkflow-srcout of the workspace into$RUNNER_TEMP. The job,and therefore the whole run, is reported as a failure despite having
produced a complete, valid mutation report.
Impact
Every scheduled mutation run that uses a local composite action
under
workflow-srcwith its own post/cleanup step (at minimumsetup-rust, sinceactions-rust-lang/setup-rust-toolchainsavesthe Cargo/rustup cache in its post step) will report as failed once
PR #344's relocation lands, regardless of whether the mutation
testing itself succeeded. This defeats the purpose of #343's fix:
callers now get a clean tree but a red, unreliable run status, and
the toolchain cache is presumably never saved because the post step
aborts before running its own logic.
Suggested fix
Either:
workflow-srcin place until all steps (including compositeaction post steps) that depend on it have finished, and relocate
it only immediately before the mutation tool itself runs, restoring
it (or a symlink) afterwards for cleanup purposes; or
steps via a path inside the relocatable
workflow-srctree — e.g.call
setup-rustbefore checking out/relocatingworkflow-src, orvendor a copy outside the relocated directory; or
continue-on-erroris not appropriate here since it would maskgenuine failures — prefer fixing the path lifecycle so the post
step resolves correctly.
Whichever approach is chosen, add a regression check (or contract
test, per #362) asserting that a job using
setup-rustinside a mutation workflow finishes green end-to-end,not just that the mutation step itself succeeds.