fix(agent): workflow runner use shutdown context

[Pnkcaht]

What was happening

When a workflow/run was canceled from the UI or API, the server correctly marked the run as Canceled, but the runner machines continued executing job steps.

Specifically:

• The cancel signal was received by the runner
• The workflow state was updated on the server
• Pipeline execution on the runner was not interrupted
• Tests and other long-running steps kept running and consuming runner capacity

This resulted in:

• Wasted compute time
• Runner capacity remaining blocked
• Confusing UX (UI shows Canceled, but jobs keep running)

Related issue

Closes #5925

Related PRs

This change complements previous cancellation-related fixes:

• Fix: Agent now gracefully handles running containers when killed #6018 — fixes container cleanup on step cancellation
• pipeline: always destroy step on cancellation #6020 — ensures DestroyStep runs on pipeline cancellation

While those PRs focus on step and backend cleanup, this PR ensures that workflow cancellation is properly propagated to the runner execution context.

What this PR changes

This PR ensures that canceling a workflow immediately stops execution on the runner.

• Propagates server-side cancel events to the runner workflow context
• Cancels the workflow execution context as soon as a cancel signal is received
• Ensures pipeline execution and backend steps are interrupted
• Normalizes cancellation handling so the workflow consistently ends as Canceled

Why this approach

In Woodpecker, the workflow context is the single source of truth for execution lifecycle.

Previously, receiving a cancel event did not reliably cancel the workflow execution context, allowing pipeline steps to continue running.
By explicitly canceling the workflow context when a cancel signal is received:

• The pipeline runtime receives context.Done()
• Backend implementations (Docker, Kubernetes, etc.) can terminate running steps
• Runner capacity is freed promptly

This aligns runner behavior with what the UI reports and avoids wasted resources.

Implementation overview

sequenceDiagram
    participant UI as Web UI / API
    participant Server as Woodpecker Server
    participant Runner as Agent Runner
    participant Pipeline as Pipeline Runtime
    participant Backend as Backend Engine

    UI->>Server: Cancel workflow
    Server->>Runner: Cancel signal (Wait)
    Runner->>Runner: cancel workflow context
    Runner->>Pipeline: ctx.Done()
    Pipeline->>Backend: stop execution
    Backend-->>Pipeline: terminate running steps
    Pipeline-->>Runner: execution aborted
    Runner->>Server: report canceled state

Loading

[6543]

@Pnkcaht for you as you are new to the project i just documented a bunch of dev stuff:

#6012
#6019

-> https://woodpecker-ci-woodpecker-pr-6019.surge.sh/docs/next/development/architecture

[codecov]

Codecov Report

❌ Patch coverage is 0% with 46 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.85%. Comparing base (b1cbd96) to head (860fc34).
⚠️ Report is 306 commits behind head on main.

Files with missing lines	Patch %	Lines
agent/runner.go	0.00%	46 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6021      +/-   ##
==========================================
- Coverage   21.86%   21.85%   -0.01%     
==========================================
  Files         432      432              
  Lines       39254    39258       +4     
==========================================
  Hits         8581     8581              
- Misses      29865    29869       +4     
  Partials      808      808              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[6543]

before the patch:

if you cancle the agent while running a workflow the steps and workflow is marked as failed

now:

workfow is correctly stated as failed but the step is marked as success

[Pnkcaht]

@6543 What do you think? :)

[6543]

sorry wont do ... the steps are marked as succes the state of the whole workflow is not the problem

[Pnkcaht]

Can you explain the mistakes you made? I can fix them.

[6543]

lgtm as smal refactor pull and handling context now correct

[6543]

this intorduced an regression, proper fix is #6361