Required workflows: enforcing CI/CD policy across repos
GitHub Actions is introducing required workflows in public beta, giving DevOps teams a way to define standard CI/CD practices once and enforce them across an entire organization. Rather than configuring each repository individually — an impractical task at scale — admins can now apply a single workflow definition to all or selected repositories. This cuts down on duplicated configuration code while supporting common use cases like security scanning, compliance checks, and standardized deployment.
Organization admins control which repositories the required workflows apply to. When enabled, these workflows run as required status checks on pull requests opened against the default branch, blocking merges until they pass. Repository-level teams can see which required workflows are active in their repos.
Use cases for required workflows include:
- Security: invoke external vulnerability scoring or dynamic analysis tools.
- Compliance: ensure all code meets enterprise quality standards.
- Deployment: enforce a consistent continuous deployment process.
Configuration variables: a plain-text alternative to secrets
Until now, any reusable value in a workflow had to be stored as an encrypted secret. That works for sensitive data, but it's awkward for non-sensitive configuration like compiler flags, usernames, or server names. During development of required workflows, GitHub heard from customers who needed parameterization so local repositories could override certain values.
Configuration variables address that gap. They store non-sensitive data as plain text variables that can be reused across workflows at the organization, repository, or environment level, depending on your needs.
With required workflows plus existing reusable workflows, configuration variables, and secrets, teams can apply a uniform set of standards across many repositories without hours of per-repo setup.
