We’re pleased to announce that Runner Group configuration is now supported natively within the org-config repository via Codebase Governor (CBG). This change centralises runner group lifecycle management and enforces consistent, auditable access control across the Flutter-Global GitHub organisation.
Why is This Happening?
Previously, runner group provisioning and repository access management required manual coordination, with no standardised process for tracking ownership. This introduced several operational and governance challenges:
- Repository access to runner groups was managed under a simple ‘runners.csv’ file, with no structured ownership model
- Traceability back to the originating request required significant manual effort, leading to ambiguous accountability
- Cross-repository runner group management lacked scalability as the organisation expanded
Centralising runner group configuration within CBG provides a single source of truth, enabling structured ownership tracking, consistent access control enforcement, and improved operational visibility across the organisation.
What’s Changing?
-
Declarative YAML Configuration: All runner group definitions are expressed as version-controlled YAML manifests, enabling peer review, auditability, and change tracking via standard pull request workflows.
-
Automated Migration: All existing runner group configurations will be programmatically migrated to the new format. No manual intervention is required from capability teams.
Note: The Operations team retains responsibility for provisioning and updating runner groups directly on GitHub following config approval, ensuring separation of concerns and maintaining security boundaries.
How Do I Use the New GitHub Runner Groups Features?
Provisioning a Runner Group:
- Define a YAML manifest for your runner group under /runner-groups in the org-config repository.
- Raise a Pull Request against the org-config repository. Upon approval, the Operations team will handle downstream provisioning on GitHub.
Need help? Refer to the guide: Runner Groups guidelines
Configuring Repository Access:
- To expose a runner group to all repositories within a capability, declare it in the capability’s _defaults.yml.
- To scope access to specific repositories, add the runner group reference directly to the relevant repository config files.
This model provides fine-grained access control, allowing teams to scope runner group availability precisely to where it is required.
Self-Hosted Runners in Repositories
As part of this migration, eight self-hosted runners were identified across six repositories, configured at the repository level rather than at the organisation level. These runners fall outside the scope of the automated migration to CBG, as they are not managed through organisation-level runner group
If you’re a mantainer or an owner of these repositories, please use one of the existent runner groups in the organization or create a new one.
Reference Documentation
For technical queries or assistance, reach out in #inner-source.
by: Francisco Pereira
in:
category: Changelog