Enforcing code reliability by requiring workflows with GitHub repository rules
GitHub Enterprise Cloud customers can now ensure controlled workflows run and pass before code is merged into any of its repositories.
![](https://github.blog/wp-content/uploads/2023/10/githubactions-requiredworkflow.png?resize=1600%2C850)
Centrally managed policies are hard
CI/CD best practices are easy to talk about and hard to implement. For example, teams want to avoid surprises before deploying code but often stop short of introducing centrally managed policies to help protect their repositories. Let’s face it, there are plenty of challenges when defining, setting up, and enforcing policy at scale—especially scaling to hundreds of repositories and thousands of developers.
Reusable workflows introduced the idea of centrally managed workflows for an organization’s repositories. They helped the shareability of workflows but configuring each repository individually didn’t scale and more importantly, didn’t enforce the success of workflow runs.
We’ve made it better
GitHub has simplified the process of centrally managing workflows. Available today, GitHub Enterprise Cloud customers can require that certain workflows need to run successfully before code can be merged into an organization’s repositories. Earlier this month, we shared that GitHub Actions required workflows would be moving to GitHub repository rulesets. We’re excited to announce that setting up and managing these workflows is now formally part of GitHub repository rulesets. Not only do repository rulesets improve the experience of setting up and managing these workflows but it also allows several other benefits like branch targeting, bypass rules, and dry running rules in an evaluation mode.
Enforceability is key
Enforcing required workflow runs provides a new level of control to the code being added to your repositories. By requiring workflows via repository rulesets, all pull requests on selected repositories will be blocked until specified workflows run successfully. This easily scales from some to all repositories in the organization regardless of the number of contributors. The level of specificity for the workflow is also configurable—choose a workflow by specific branch, tag, current commit or specific SHA to lock in the exact version of the workflow that’s required. These controls will help save engineering time and effort by enforcing workflow runs on code contributions before they’re merged and deployed.
Repository rulesets make it easy
Requiring workflows from repository rulesets keeps set-up and maintenance for all your rules in a centralized UI. This also means that all additional tools provided by rulesets can be applied to your workflow rule. For example, you can create a bypass list that allows specific users to “break the glass” so they can merge even if the workflow doesn’t succeed. You can also set up and evaluate the potential impact of required workflow policies before enforcing them on repositories. This will allow you to fine tune and test the settings without disrupting the flow of contributors.
Auditing
Repository Rule Insights are a powerful tool used to evaluate required workflows. When introducing a workflow rule, it’s necessary to make sure things are working properly before enforcing it throughout your repositories. By placing the rule into “Evaluate” mode, the audit reports the results of the rule without blocking downstream repository contributions. Staying in “Evaluate” mode provides the time necessary to evaluate the results of the rule before enforcing it. Once the rule is working as intended, switching from “Evaluate” to “Activate” enforces the rule and prevents any code associated with the workflow from being merged into the repository.
Return confidence to the dreaded “Friday deploy”
Workflows controlled at the organization level ensure repository contributions adhere to a defined set of automated processes. Defining and enforcing these workflows is now a part of GitHub repository rules, which greatly improves the experience to centrally manage repositories. Now, code contributions are guaranteed to adhere to the CI/CD policies defined by required workflows. Check out our docs to learn more about how to set up and require workflows at the organization level. And don’t forget to join the community discussion about requiring workflows. If you’re reading this on a Friday, don’t worry, set up your required workflows and build confidence in today’s deployments.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Enterprise-LightMode-4.png?resize=400%2C212)
GitHub Enterprise: The best migration path from AWS CodeCommit
AWS CodeCommit is discontinuing new customer access and will no longer introduce new features. Learn how to migrate to GitHub Enterprise and why it’s the best option for you.
![](https://github.blog/wp-content/uploads/2024/04/Enterprise-DarkMode-2-3.png?resize=400%2C212)
GitHub Actions, Arm64, and the future of automotive software development
Learn how GitHub’s Enterprise Cloud, GitHub Actions, and Arm’s latest Automotive Enhanced processors, work together to usher in a new era of efficient, scalable, and flexible automotive software creation.
![A schematic diagram depicting the steps an SAST tool takes to scan the source code of an SQL application under an SQL injection attack. The first step is tokenizing the source code, the second is abstracting the source code, the third conducting semantic analysis, the fourth conducting taint analysis, and the last generating a security alert about the SQL injection vulnerability.](https://github.blog/wp-content/uploads/2024/02/sast-tool-diagram.png?resize=400%2C212)
The architecture of SAST tools: An explainer for developers
More developers will have to fix security issues in the age of shifting left. Here, we break down how SAST tools can help them find and address vulnerabilities.