feat(actions)!: improve support for reusable workflows

[Zettat123]

Summary

This PR improves reusable workflow support for Gitea Actions. The parsing of the called workflow now happens on Gitea side, not on the runner. When the caller becomes ready, Gitea fetches the called workflow source, parses it, and inserts each child job into the database as a ActionRunJob linked to the caller via ParentCallJobID. As a result, every callee job is dispatched as its own task and its logs surface as an independent job entry in the UI, rather than being inlined into the caller's "Set up job" step.

This PR supports two kinds of uses :

• same-repo call: uses: ./.gitea/workflows/foo.yaml
• cross-repo call: uses: OWNER/REPO/.gitea/workflows/foo.yaml@REF

⚠️ BREAKING ⚠️

External reusable workflows (uses: https://other-gitea-instance/OWNER/REPO/.gitea/workflows/test.yaml@REF) are no longer supported. To keep using them, clone the repositories to the local instance.

Main changes

Execution model

• Each caller job carries IsReusableCaller=true and won't be fetched by runners.
• ParentCallJobID can link a called job to its caller.
• Caller status is derived from its direct children.

Workflow syntax

• jobparser now supports parsing on: workflow_call trigger with inputs:, outputs:, and secrets: declarations.
• Max nesting depth: capped at MaxReusableCallLevels = 9, which means a top-level caller may have at most 9 nested callers below it.
• Cycle prevention: at expansion time, checkCallerChain walks the caller's ancestor chain via ParentCallJobID and rejects if the same uses: string appears anywhere upstream (reusable workflow call cycle detected). This catches both direct (A -> A) and indirect (A -> B -> A) cycles.

Cross-repo access

• To share reusable workflows from private repos, use Collaborative Owners introduced by Support actions and reusable workflows from private repos #32562

Rerun semantics

• expandRerunJobIDs partitions the latest attempt's jobs into:
  • a rerun set: jobs being rerun + downstream siblings within the same scope.
  • an ancestor set: reusable callers whose only some descendants are being rerun (the caller itself is not).
• Cloning behavior for callers in execRerunPlan:
  • Caller is fully rerun (caller's AttemptJobID in rerunSet): none of its descendants are cloned. The caller is cloned with IsCallerExpanded=false, and re-expansion (which reinserts the children fresh) happens later when the resolver brings the caller to Waiting again.
  • Caller is in ancestor set (only some descendants rerun): the caller is pass-through (Status will be updated by its fresh children). Its non-rerun descendants are also pass-through clones (point SourceTaskID at the original task). Their ParentCallJobID is remapped to the new attempt's caller row.

UI

• Job list in RepoActionView.vue is now tree-shaped: callers indent their children. Callers default to collapsed.
• New caller detail page using WorkflowGraph to show direct children only; the run summary's WorkflowGraph shows top-level callers and their immediate descendants.

Known trade-offs

• Caller expansion runs inside the enclosing write transaction. expandReusableWorkflowCaller performs a git read of the called workflow while holding the row locks that update the caller and insert its children. This is intentional: the caller-row update and child-row inserts must commit atomically. None of the call sites is hot (each caller is expanded once per attempt), so the trade-off is acceptable.

• A malformed if: expression on a job leaves it Blocked silently. evaluateJobIf now runs server-side as part of resolver passes; deterministic expression errors (typos, undefined context fields) are logged but do not surface in the UI. This is the same behavior the resolver already had for concurrency-expression errors. Distinguishing transient DB errors from user-authored expression errors and writing the latter back as StatusFailure is a follow-up.

Screenshots

References

• https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
• https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations

---

Replace #36388

[Zettat123]

@silverwind @bircni @lunny UI updated. Please review again.

[silverwind]

Checking CI failure

[silverwind]

CI failures are unrelated.

[Zettat123]

Seems like an ES service issue, should we rerun the failed tests?

[silverwind]

I'll make a new PR to fix them. Re-run here is likely to suceed.

[silverwind]

ES fixes are on #37906.