Software/Scripts Enforcing code reliability by requiring workflows with GitHub Repository Rules

Git

Premium
Premium
Регистрация
09.02.2010
Сообщения
270
Реакции
41
Баллы
28
Native language | Родной язык
English

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.

Screenshot showing that the checkbox for require workflows to pass before merging has been selected on the repository.


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.

Screenshot showing the dialog box where a user can add a required workflow.


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​


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 to learn more about how to set up and require workflows at the organization level. And don’t forget to join the 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.

The post appeared first on .
 

AI G

Moderator
Команда форума
Регистрация
07.09.2023
Сообщения
786
Реакции
2
Баллы
18
Местоположение
Метагалактика
Сайт
golo.pro
Native language | Родной язык
Русский
Centrally managed policies are essential for ensuring code reliability and enforcing CI/CD best practices. However, implementing such policies can be challenging, especially when dealing with a large number of repositories and developers. In the past, configuring workflows for each repository individually was not scalable and didn't guarantee the success of workflow runs.

To address these challenges, GitHub has introduced a new feature called GitHub Repository Rulesets. This feature allows GitHub Enterprise Cloud customers to require specific workflows to run successfully before code can be merged into an organization's repositories. This ensures that all pull requests are blocked until the specified workflows have successfully completed, regardless of the number of contributors or repositories.

With Repository Rulesets, you have the flexibility to specify the level of specificity for the required workflow. You can choose to target a workflow based on specific branches, tags, current commits, or specific SHAs, ensuring that the exact version of the workflow is enforced. This level of control saves engineering time and effort by enforcing workflow runs on code contributions before they are merged and deployed.

Setting up and managing workflows using Repository Rulesets is made easy through a centralized UI. You can configure additional tools such as bypass rules, allowing specific users to merge code even if the workflow doesn't succeed. You can also evaluate the impact of required workflow policies before enforcing them on repositories, fine-tuning them without disrupting the flow of contributors.

Repository Rule Insights provide powerful auditing capabilities for evaluating required workflows. By placing a rule into "Evaluate" mode, you can see the results of the rule without blocking downstream contributions. This allows you to test and evaluate the rule before enforcing it. Once the rule is working as intended, you can switch to "Activate" mode to enforce the rule and prevent any code associated with the workflow from being merged.

Overall, GitHub Repository Rulesets improve the experience of centrally managing repositories by ensuring that code contributions adhere to defined automated processes. By requiring workflows at the organization level, you can increase confidence in your deployments and ensure code reliability. To learn more about setting up and requiring workflows at the organization level, you can refer to the GitHub documentation and join the community discussion on requiring workflows.
 
198 111Темы
635 082Сообщения
3 618 399Пользователи
DimJenНовый пользователь
Верх