WorkflowDispatch api optionally return runid

[ChristopherHX]

Implements https://github.blog/changelog/2026-02-19-workflow-dispatch-api-now-returns-run-ids

[ChristopherHX]

swagger page now looks like this

[Copilot]

Pull request overview

This PR implements the GitHub workflow dispatch API feature that optionally returns run details (workflow run ID and URLs) when dispatching a workflow. This matches the GitHub API behavior announced in their February 2026 changelog. The implementation adds an optional return_run_details query parameter that, when set to true, returns a 200 OK response with run details instead of the default 204 No Content response.

Changes:

• Modified DispatchActionWorkflow service function to return the created workflow run ID
• Updated API endpoint to optionally return run details based on return_run_details query parameter
• Added RunDetails struct to define the response format with workflow run ID and URLs
• Added comprehensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
services/actions/workflow.go	Changed DispatchActionWorkflow to return (runID int64, workflowError error) instead of just error, updating all error returns to include a 0 runID
routers/api/v1/repo/action.go	Added conditional response logic: returns 204 No Content by default, or 200 OK with run details when return_run_details=true
routers/web/repo/actions/view.go	Updated caller to handle the new return signature by ignoring the returned runID
modules/structs/repo_actions.go	Added RunDetails struct containing WorkflowRunID, RunURL, and HTMLURL fields
routers/api/v1/swagger/action.go	Added Swagger response definition for RunDetails
templates/swagger/v1_json.tmpl	Updated Swagger documentation with new query parameter and response definitions
tests/integration/actions_trigger_test.go	Added test case to verify the new functionality works correctly

---

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

[silverwind]

Comment written by Claude (AI assistant) on behalf of @silverwind

---

Nice feature! A few observations:

Consider reusing ActionWorkflowRun instead of a new RunDetails struct

The codebase already has ActionWorkflowRun (in modules/structs/repo_actions.go) and ToActionWorkflowRun (in services/convert/convert.go) which construct the full workflow run API response including id, url, html_url, and more. Instead of introducing a new RunDetails struct with different field names, could this endpoint just return the existing ActionWorkflowRun? That would be:

• More consistent with other run-related API endpoints (e.g., GetWorkflowRun)
• More useful for API consumers (they get status, event, head_sha, etc. without a second call)
• Less new surface area to maintain

Field naming diverges from existing patterns

The new RunDetails struct uses workflow_run_id and run_url as JSON keys, while the existing ActionWorkflowRun struct uses id and url for the same concepts. This inconsistency could confuse API consumers. If a separate struct is preferred, aligning the field names with the existing convention (id, url, html_url) would be better.

Minor: named return value

The DispatchActionWorkflow signature change to (runID int64, workflowError error) - the named workflowError is a bit unusual. Plain error is more idiomatic Go unless naked returns are used (which they aren't here). Not a blocker, just a style note.

[ChristopherHX]

Consider reusing ActionWorkflowRun instead of a new RunDetails struct

The codebase already has ActionWorkflowRun (in modules/structs/repo_actions.go) and ToActionWorkflowRun (in services/convert/convert.go) which construct the full workflow run API response including id, url, html_url, and more. Instead of introducing a new RunDetails struct with different field names, could this endpoint just return the existing ActionWorkflowRun? That would be:

• More consistent with other run-related API endpoints (e.g., GetWorkflowRun)
• More useful for API consumers (they get status, event, head_sha, etc. without a second call)
• Less new surface area to maintain

Field naming diverges from existing patterns

The new RunDetails struct uses workflow_run_id and run_url as JSON keys, while the existing ActionWorkflowRun struct uses id and url for the same concepts. This inconsistency could confuse API consumers. If a separate struct is preferred, aligning the field names with the existing convention (id, url, html_url) would be better.

Note, adding more fields is ok for me. However not following the GitHub Docs not. So I generally disagree to these points of claude

Minor: named return value

The DispatchActionWorkflow signature change to (runID int64, workflowError error) - the named workflowError is a bit unusual. Plain error is more idiomatic Go unless naked returns are used (which they aren't here). Not a blocker, just a style note.

I saw wxiaoguang using an anonymous struct with named fields, not sure if this is a better pattern.

[wxiaoguang]

Minor: named return value
The DispatchActionWorkflow signature change to (runID int64, workflowError error) - the named workflowError is a bit unusual. Plain error is more idiomatic Go unless naked returns are used (which they aren't here). Not a blocker, just a style note.

I saw wxiaoguang using an anonymous struct with named fields, not sure if this is a better pattern.

Changed it to (runID int64, _ err)

Sometimes I use "anonymous struct" when the returned values are too many (more than 2 or 3)

[ChristopherHX]

Thanks.

Sounds good, to give the error the discard identifier, since this is self explaining if not used. Never thought about this.