Summary

This PR adds scoped workflows to Gitea Actions. Workflows defined centrally in a "source" repository that automatically run on every repository in scope: an organization's repositories, or (for instance admins) every repository on the instance. Each scoped run executes in the consuming repository's own context (its runners, secrets, and branch) while its content is read from the source repository, so an org or instance can mandate shared CI across many repositories without copying workflow files into each one.

An owner or instance admin registers source repositories on a settings page and can mark individual workflows as required. A required scoped workflow cannot be opted out by a consuming repository and gates its pull-request merges; an optional one can be disabled per repository. Scoped workflows live under a dedicated SCOPED_WORKFLOW_DIRS (default .gitea/scoped_workflows), kept separate from regular WORKFLOW_DIRS.

Main changes

Configuration

New SCOPED_WORKFLOW_DIRS setting, validated to not overlap with WORKFLOW_DIRS. An empty value disables the feature.

Data model & migration

• New action_scoped_workflow_source table mapping a registering owner (owner_id, where 0 = instance-level) to a source repository, with a per-workflow WorkflowConfigs map.
• ActionRun gains WorkflowRepoID / WorkflowCommitSHA (the pinned content source) and an IsScopedRun flag.

Detection & run creation

On consumer events, scoped workflows from the effective sources (the owner's own sources plus instance-level ones) are matched and turned into runs that execute in the consumer's context, with content pinned to the source repo's default-branch commit.

on: workflow_run and on: schedule are currently not supported.

Opt-out

A consuming repository can disable an optional scoped workflow (tracked separately from regular DisabledWorkflows); required scoped workflows can never be disabled, opted out, or bypassed.

Commit status

A scoped run's status context format is "<source repo full name>: <workflow display name> / <job> (<event>)"
(for example: my-org/scoped-workflows: db-tests / test-sqlite (pull_request)),
keeping it distinct from a same-named repo-level workflow and from other sources.

Required status checks

Admins mark workflows required and supply status-check patterns. EffectiveRequiredContexts appends those patterns to the branch protection's required contexts and they are matched must-present-and-pass. If the status checks from scoped workflows fail, the PR cannot be merged.

Screenshots

Reusable workflows (uses:)

A scoped workflow's local uses: ./… resolves against the source repository. uses: directory validation honors the instance-configurable WORKFLOW_DIRS and SCOPED_WORKFLOW_DIRS (previously hardcoded to .gitea/.github/workflows).

Manual dispatch

workflow_dispatch is supported for scoped workflows (web and API), resolving inputs/content from the source repo.

Performance

A process-local LRU cache keyed by source repo ID for the per-source workflow parse, so instance-level and owner-level sources don't open the source repo and parse workflow files on every event.

UI

Org / user / admin pages to register and remove sources, search repositories, and mark workflows required with their status-check patterns. The repository Actions sidebar groups scoped workflows by source with owner/instance labels and required/disabled badges.

Screenshots

Scoped workflows setting page:

Consumer repo's Actions runs list:

• Owner: this is a owner-level scoped workflows source repo
• Global: this is a global scoped workflows source repo
• Required: this scoped workflow is required, repo admin cannot disable it