BUG: Fix workflow run jobs API returning null steps

[bircni]

Problem

GET /api/v1/repos/{owner}/{repo}/actions/runs/{runId}/jobs was always returning steps: null for each job.

Cause

In convert.ToActionWorkflowJob, when the job had a TaskID we loaded the task with db.GetByID but never loaded task.Steps. ActionTask.Steps is not stored in the task row (xorm:"-"); it comes from action_task_step and is only filled by task.LoadAttributes() / GetTaskStepsByTaskID(). So the conversion loop over task.Steps always saw nil and produced no steps in the API response.

Solution

After resolving the task (by ID when the caller passes nil), we now load its steps with GetTaskStepsByTaskID(ctx, task.ID) and set task.Steps before building the API steps slice. No other behavior is changed.

Testing

• New integration test TestAPIListWorkflowRunJobsReturnsSteps: calls the runs/{runId}/jobs endpoint, inserts a task step for a fixture job, and asserts that the response includes non-null, non-empty steps with the expected step data.
• make test-sqlite#TestAPIListWorkflowRunJobsReturnsSteps passes with this fix.

[Copilot]

Pull request overview

Fixes the Actions workflow run jobs API (GET /api/v1/repos/{owner}/{repo}/actions/runs/{runId}/jobs) so that job steps are populated instead of always being null, aligning the response with the underlying action_task_step data.

Changes:

• Load task steps in convert.ToActionWorkflowJob via GetTaskStepsByTaskID when a job has an associated task.
• Add an integration test asserting the jobs list endpoint returns non-null/non-empty steps for a job with stored task steps.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
services/convert/convert.go	Loads task steps before converting a workflow job so API responses can include steps.
tests/integration/api_actions_run_test.go	Adds an integration test that inserts a task step and validates steps are returned by the jobs list endpoint.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[silverwind]

Review of this PR (this comment was written by Claude Code / claude-opus-4-6):

The core fix is correct. ActionTask.Steps is tagged xorm:"-" and lives in the action_task_step table, so db.GetByID never populates it. Explicitly calling GetTaskStepsByTaskID after resolving the task is the right approach, and the if task.Steps == nil guard is consistent with the same pattern used in ActionTask.LoadAttributes (models/actions/task.go:137).

The nil-task guard is a good improvement. The old code didn't check the has return from db.GetByID, so if the task row was somehow missing, it would dereference a zero-value ActionTask. Wrapping the runner/steps logic in if task != nil prevents that.

One pre-existing issue worth noting (not introduced by this PR): The step status conversion uses ToActionsStatus(job.Status) for every step, meaning all steps inherit the job-level status/conclusion rather than their own individual step.Status. Since ActionTaskStep has its own Status field (used elsewhere, e.g. in Duration()), this should probably be ToActionsStatus(step.Status). This is out of scope for this PR but might be worth a follow-up fix.

Test looks good. It directly inserts a step for a fixture task and verifies the API returns non-null, non-empty steps with the correct data. Using t.Context() is fine given the go 1.26 requirement in go.mod.