Using GitHub Actions to build a CI/CD pipeline has many advantages - Simple set-up - You can respond to any webhook on GitHub - Community-powered, reusable workflows - Support for any platform, language, and cloud.
Get building today at How to build a CI/CD pipeline with GitHub Actions in four simple steps | The GitHub Blog
Customers can now deterministically restrict their workflows to run on a specific set of runners using the names of their runner groups in the
runs-on key of their workflow YAML. This prevents the unintended case where your job runs on a runner outside your intended group because the unintended runner shared the same labels as the runners in your intended runner group.
Example of the new syntax to ensure a runner is targeted from your intended runner group:
labels: [ self-hosted, label-1 ]
In addition to the workflow file syntax changes, there are also new validation checks for runner groups at the organization level. Organizations will no longer be able to create runner groups using a name that already exists at the enterprise level. A warning banner will display for any existing duplicate runner groups at the organization level. There's no restriction on the creation of runner groups at the enterprise level.
This feature change applies to enterprise plan customers as only enterprise plan customers are able to create runner groups.