fix: run always()/cancelled() and post steps correctly on cancellation (#1043)

## Problem

When a workflow run is **cancelled**, the runner diverged from GitHub Actions:

- Main-stage `if: ${{ always() }}` / `if: ${{ cancelled() }}` steps **did not run** at all (unlike a *failed* run, where they do).
- `if: ${{ cancelled() }}` was **structurally impossible** to satisfy — it could never be true.

GitHub Actions runs `always()`/`cancelled()` steps (and post cleanup) even when a job is cancelled. This runner only honored that for action *post* steps (since #1016), leaving main-stage cleanup steps silently skipped.

## Root causes (both in `act/`)

1. **`getJobContext()`** derived the job status purely from step conclusions, so it could only ever return `"success"` or `"failure"`. Since `cancelled()` checks `Job.Status == "cancelled"`, it was impossible — and `success()` stayed *true* on a cancelled run, so the wrong `if` branch was taken everywhere.

2. **The main step pipeline** is chained with `Executor.Then()`, which short-circuits the moment `ctx.Err() != nil`. Once the server cancelled, every not-yet-started main step (including `always()` ones) was abandoned.

## Fix

- Add a per-`RunContext` `jobCancelled` flag + `markCancelled()`. `getJobContext()` now reports `"cancelled"` (taking precedence over success/failure), so `cancelled()`/`always()` are true and `success()`/`failure()` are false — matching GitHub's "only always()/cancelled() run on cancel" semantics.
- Replace the plain main-steps pipeline with `newMainStepsExecutor`. On interruption (`context.Canceled` from a server cancel, or `context.DeadlineExceeded` from the job timeout) it marks the job cancelled and runs the **remaining** steps under a fresh context (`context.WithoutCancel` + bounded timeout) so `always()`/`cancelled()` steps run for cleanup, while default-`success()` steps skip themselves. The original interrupt error is still propagated upward.
- Backstop `markCancelled()` in the post-step `Finally` so cancellations landing outside the main loop still surface the cancelled status to post steps.

Pre-steps keep normal short-circuit behavior, and reporting (`RESULT_CANCELLED`) is untouched — that remains handled by #1016.

## Reporting semantics (unchanged by this PR)

| Run state | failing post/`always()` step reported as                                                      |
| --------- | --------------------------------------------------------------------------------------------- |
| Normal    | **FAILURE**                                                                                   |
| Timeout   | **FAILURE** (deadline path preserves the job-error container)                                 |
| Cancelled | **CANCELLED** — cancellation wins; the failing step is logged but doesn't flip the conclusion |

The new `always()` path runs under `context.WithoutCancel`, so the job-error container is preserved — a failing `always()` step records its failure at step level and does not panic in `SetJobError`.

Fixes #657

Reviewed-on: https://gitea.com/gitea/runner/pulls/1043
Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com>

act/runner/run_context.go

@@ -73,6 +73,39 @@ type RunContext struct {
 	// captured before execution so each matrix combo interpolates from the originals rather
 	// than from a sibling's already-resolved values written into the shared Job.Outputs.
 	outputTemplate map[string]string
+	// jobCancelled records that this job's run was cancelled (context.Canceled). It makes
+	// getJobContext report the "cancelled" status so cancelled()/always() evaluate the way
+	// GitHub Actions does, letting cleanup and always() steps run while normal steps skip.
+	jobCancelled bool
+	// jobFailed records failures outside normal main-step results, such as action pre-step
+	// failures. Those failures must still make success() false and failure() true for later
+	// main-step if evaluation.
+	jobFailed bool
+}
+
+// markCancelled flags the job as cancelled so subsequent step `if` evaluations and the
+// job status context observe the "cancelled" state.
+func (rc *RunContext) markCancelled() {
+	rc.jobCancelled = true
+}
+
+// markFailed flags the job as failed so subsequent step `if` evaluations observe
+// failure even when the error happened outside a main step result.
+func (rc *RunContext) markFailed() {
+	rc.jobFailed = true
+}
+
+// markInterrupted records the job's interruption status from a context error so later step `if` evaluations and the job result observe it,
+// keeping the timeout path symmetric with the cancel path:
+//   - context.Canceled (server cancel) marks the job cancelled, matching GitHub's "only always()/cancelled() run on cancel".
+//   - context.DeadlineExceeded (job timeout-minutes) marks the job failed, matching the "Timeout -> FAILURE" reporting semantics.
+func (rc *RunContext) markInterrupted(err error) {
+	switch {
+	case errors.Is(err, context.Canceled):
+		rc.markCancelled()
+	case errors.Is(err, context.DeadlineExceeded):
+		rc.markFailed()
+	}
 }
 
 func (rc *RunContext) AddMask(mask string) {
@@ -904,12 +937,21 @@ func trimToLen(s string, l int) string {
 
 func (rc *RunContext) getJobContext() *model.JobContext {
 	jobStatus := "success"
+	if rc.jobFailed {
+		jobStatus = "failure"
+	}
 	for _, stepStatus := range rc.StepResults {
 		if stepStatus.Conclusion == model.StepStatusFailure {
 			jobStatus = "failure"
 			break
 		}
 	}
+	// A cancelled run takes precedence over success/failure so cancelled() is true and
+	// success()/failure() are false, matching GitHub Actions: on cancellation only
+	// always() and cancelled() steps run.
+	if rc.jobCancelled {
+		jobStatus = "cancelled"
+	}
 	return &model.JobContext{
 		Status: jobStatus,
 	}