fix(actions): report individual step status in workflow job API response

[bircni]

When a workflow job failed, the API response reported all steps as failed — even steps that had completed successfully before the failing step. ToActionWorkflowJob was calling ToActionsStatus(job.Status) for every step instead of ToActionsStatus(step.Status), so the job's overall conclusion was propagated to each step.

Each ActionTaskStep has its own Status field that tracks the actual outcome of that step independently of the job result.

[bircni]

Seems like a regression from #33964

[ChristopherHX]

I would not call something that was never correct in it's initial PR a regression.

Since I assume that I created this bug from scratch.

---

My time is very limited until 20th of May, this PR seems trivial enough, code fix looks fine.

[bircni]

I would not call something that was never correct in it's initial PR a regression.

Since I assume that I created this bug from scratch.

yep you're right - sorry
Thanks for your time though!!!

[silverwind]

Review

Verdict

This is the right fix. The original code is unambiguously buggy — ToActionsStatus(job.Status) was called inside a per-step loop, so every step inherited the job's overall conclusion. ActionTaskStep.Status is the source of truth for individual step state and is maintained per-step via UpdateTaskByState (models/actions/task.go:411-415) and StopTask (:461-468).

GitHub compatibility

The fix improves GitHub compatibility. GitHub's GET /repos/{o}/{r}/actions/jobs/{id} returns steps[] with each step carrying its own status and conclusion. A successful step that ran before a failing one is reported completed/success even when the job's overall conclusion is failure. Before this PR, Gitea painted every step with the job-level conclusion — that was the divergence; this PR closes it.

The Web UI already does the right thing (routers/web/repo/actions/view.go:554 → FullSteps() reads step.Status). The API was the lone outlier; this aligns it.

Edge case worth noting (pre-existing, not introduced)

For steps that never executed because an earlier step failed, step.Status typically remains StatusWaiting (created at task.go:310, only flipped to terminal if the runner reports it or StopTask runs). After this PR they surface in the API as "queued"/"". GitHub returns them as completed/skipped. This isn't worse than before (previously they were mislabeled failure), but it's not GitHub-perfect either. Worth a follow-up, not a blocker for this PR.

Minor nits

• services/convert/action_test.go:12 — db "code.gitea.io/gitea/models/db" uses a redundant alias since the package is already named db. Other tests in the same package import it without an alias (e.g. issue_test.go:11). Drop the alias for consistency.
• Consider adding a test case where the job is still running and one step has StatusSuccess while another is StatusRunning — that exercises the non-IsDone branch of ToActionsStatus, which the current test doesn't cover.

Recommendation

Approve, with the alias nit. The one-line production change is correct, narrowly scoped, and matches GitHub's documented behavior.

---

This review was written with the help of Claude Opus 4.7

[silverwind]

Minor nits should be addressed, edge case maybe too.

[wxiaoguang]

It needs clear IDs 638305d , but not 9001 for everything.