Fix workflow_run events not creating commit statuses

[davidetacchini]

Summary

• Workflows triggered by workflow_run events did not produce commit statuses because getCommitStatusEventNameAndCommitID had no case for HookEventWorkflowRun, causing it to return empty strings and silently skip status creation.
• Add a workflow_run case that walks up the parent run chain (up to 5 levels) to resolve the original triggering event's commit SHA, then attaches the status to that commit.
• Add unit tests covering single-level parent, two-level chained parent, and nil payload edge case.

Test plan

• go test -run TestGetCommitStatusEventNameAndCommitID ./services/actions/ — all 3 subtests pass
• make lint-go — 0 issues
• E2E: pushed a repo with chained workflow_run workflows (push → after-push → after-after) to a local Gitea instance built from this branch; all three commit statuses appear on the push commit in the status popover

[Copilot]

Pull request overview

Fixes missing commit statuses for Actions workflows triggered by workflow_run by resolving the original triggering commit SHA via the parent run chain.

Changes:

• Extend getCommitStatusEventNameAndCommitID to handle workflow_run by walking parent runs (up to 5 levels) to find the originating commit SHA.
• Update commit status creation to pass context.Context into the helper.
• Add unit tests covering direct parent, two-level chained parent, and nil payload handling.

Reviewed changes

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

File	Description
services/actions/commit_status.go	Adds workflow_run support by resolving commit SHA from parent runs; updates helper signature to accept ctx.
services/actions/commit_status_test.go	Adds DB-backed unit tests validating commit SHA resolution for workflow_run chains.

---

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

[silverwind]

Comment authored by @silverwind via Claude Code.

Code review notes:

Overall: This is a clean fix for a real gap — workflow_run-triggered workflows silently skipped commit status creation because the switch had no case for HookEventWorkflowRun. The approach of walking the parent chain iteratively (rather than recursing) is sensible, and extracting the magic 5 into MaxWorkflowRunDepth shared between here and skipWorkflows in notifier_helper.go is a welcome improvement.

Specifics:

• The scoping of GetRunByRepoAndID by repoID is correct and prevents cross-repo lookups.
• Handling ErrNotExist as a silent no-op (returning empty strings) is consistent with how GetRunsFromCommitStatuses handles deleted runs.
• The recursive call to getCommitStatusEventNameAndCommitID(ctx, parentRun) when the parent is a non-workflow_run event correctly delegates to the existing push/PR/release logic. Discarding the parent's event return value and keeping "workflow_run" as the event name is the right behavior — the commit status context should reflect the actual triggering workflow type.
• Returning "", "", nil when payload.WorkflowRun == nil or when the chain exceeds depth means no status is created, which is the safe default.
• Tests cover the three important scenarios (single parent, two-level chain, nil payload) and use the standard unittest.PrepareTestDatabase() pattern.

Looks good.

[ChristopherHX]

This was initially intentional to not have any commit status for workflow_run, based on my GitHub Actions knowledge (if this is not correct anymore, please point me to an example on GitHub)

• Wouldn't this clobber commit statuses of the same context if you have workflow_run depth > 2? No tests checked if they are use unique context
• I usually answered in GitHub Actions Discussions,
  • call the commit status api yourself, then you are in charge of specifing the context name
• Would a workflow_run requested run, clobber an completion request?

If we do this, wouldn't we need to first fix that too many commit statuses, break Giteas branch protection and Pull Request Ui (if we reach the page size)?, could be also stale knowledge.

At least I think the tests needs to be extended to assert for a context name (not only sha + event) to answer my concerns.

[davidetacchini]

This was initially intentional to not have any commit status for workflow_run, based on my GitHub Actions knowledge

I understand GitHub doesn't create commit statuses for workflow_run events, but I think having them in Gitea improves visibility — you can see at a glance on the commit whether all downstream workflows passed. Happy to hear if there's a strong reason to keep parity with GitHub here.

Wouldn't this clobber commit statuses of the same context if you have workflow_run depth > 2?

At each depth level the workflow has a different name, so the contexts are naturally unique (e.g. "after-push / build (workflow_run)" vs "after-after / deploy (workflow_run)"). The only collision would be if someone names two workflows identically at different depths, which seems unlikely. Do you see a realistic scenario I'm missing?

Would a workflow_run requested run, clobber an completion request?

Yes it would — if a workflow triggers on both types: [requested, completed], both runs produce the same context name, so the second overwrites the first. But isn't the end result correct either way? The last run to finish sets the final status (green check or red X), which reflects the actual outcome. The intermediate clobber is transient.

If you think this is a real problem, one option would be including the action in the context name (e.g. "Deploy / build (workflow_run / requested)" vs "Deploy / build (workflow_run / completed)"), but I'd rather not add that complexity if the current behavior is fine in practice.

At least I think the tests needs to be extended to assert for a context name

Agreed. I'll add context name assertions to the tests regardless.