Can a workflow supervise the upload-artifact process on a GitHub-hosted Windows runner?

[jude150]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner

Discussion Details

On a standard GitHub-hosted windows-2025 runner, does a workflow have a supported way to restrict child-process creation before the Node process for actions/upload-artifact starts, preserve its normal artifact access, and let an independent supervisor enforce a wall-clock deadline and observe that process exit? If so, which documented interface provides those guarantees, and what evidence is available for an upload interrupted before finalization?

[MrFabry]

Not with documented guarantees, at least not the child process part.

With uses: actions/upload-artifact@v4 the runner starts node.exe for the action itself. There's no hook that runs before that, so you can't put the process in a Windows job object, which is what you'd need to block child process creation at the OS level. Nothing in the workflow syntax exposes anything like that.

What you do get:

For the deadline, timeout-minutes also works on individual steps, not just jobs. When it's hit the runner kills the step and it fails with a timeout error. It's enforced by the runner rather than something independent, but it's the supported way to cap a step.

For observing the exit, give the step an id and a later step with if: always() can read steps.<id>.outcome.

For evidence of an interrupted upload, the artifact-id output is only set when the upload succeeds. If it's empty the artifact was never finalized, and it won't show in the run summary or in GET /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts. v4 artifacts are immutable, so you don't end up with a half-written artifact, you just get none. As far as I know there's no public API that shows unfinalized uploads.

If you really need the job object, the only way I can think of is skipping the action: call @actions/artifact from your own Node script and launch that from PowerShell inside a job object you create. The catch is the upload needs ACTIONS_RUNTIME_TOKEN and ACTIONS_RESULTS_URL, which the runner only gives to actions and not to run: steps, so you'd need a small JS action to export them first. It works, but at that point it's your setup and not something GitHub guarantees.

If what you're actually after is catching a hung upload, step-level timeout-minutes plus checking artifact-id afterwards covers most of it.

[jude150]

Thanks, @MrFabry — this is helpful. I appreciate the clear explanation and the pointers to step-level timeouts and artifact checks.

[MrFabry]

Thanks, @MrFabry — this is helpful. I appreciate the clear explanation and the pointers to step-level timeouts and artifact checks.

Great, remember to mark the thread has answered!