Starting on March 15, 2023, GitHub Team plan customers will be able to create, manage and delete runner groups to better manage their hosted and self hosted runners.
Enterprise customers will continue to have access to this feature at the Organisation and Enterprise level.
Today, we are adding a couple of new improvements to required workflows in GitHub Actions.
Note: Required workflows is currently in beta.
Starting on March 08, 2023, GitHub Enterprise customers using 2-core GitHub-hosted Linux and Windows runners will have the job concurrency on Windows/Linux increased from 180 to 500.
Enterprise customers need to make no changes to take advantage of this increased concurrency. If you require higher concurrency on 2-Core GitHub-hosted Linux and Windows runners than 500, please reach out to GitHub support.
Starting on February 23, 2023, Actions users of GitHub-hosted larger Linux runners will be able to make use of hardware acceleration for Android testing. Testing on a 4-core machine with hardware acceleration is around 2-3 times faster than not using hardware acceleration and around 2 times faster than using MacOS.
To make use of this on Linux, Actions users will need to add the runner user to the KVM user group
- name: Enable KVM group perms
run: |
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm(Thank you gsauthof for the feedback on this!)
You will then be able to make use of hardware acceleration when making use of Android emulator actions such as reactivecircus/android-emulator-runner.
Starting on February 14, 2023, users of GitHub-hosted larger runners will no longer be able to add, edit or remove additional labels on existing or new runners. Customers will continue to be able to use the runner group as a runs-on target to use ‘groups’ of larger runners. This provides a more determinstic approach to targetting groups of machines compared to labels and aligns with our future work to improve the runner management experience.
Existing runners with additional labels will continue to support these labels, if you wish to remove these you will need to delete the runner and create a new one with the same name. Users will continue to be able to target their runners using the runner name as the default label.
Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.
This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.
Today, we are adding support for configuration variables in GitHub Actions
Previously, you needed to store this configuration data as encrypted secrets in order to reuse values in workflows.
While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, server names etc.
Configuration variables allows you to store your non sensitive data as plain text variables that can be reused across your workflows in your repository or organization.
You can define variables at Organization, Repository or Environment level based on your requirement.
Configuration variables can be accessed across the workflow using a new vars context.
The following example shows how configuration variables can be used in a workflow.
jobs:
display-variables:
runs-on: ${{ vars.RUNNER }}
steps:
- name: Use variables
run: |
echo "Repository variable : ${{ vars.REPOSITORY_VAR }}"
echo "Organization variable : ${{ vars.ORGANIZATION_VAR }}"Note: Variables feature is in public beta
Today, we are announcing public beta of required workflows in GitHub Actions
Required workflows allow DevOps teams to define and enforce standard CI/CD practices across many source code repositories within an organization without needing to configure each repository individually. Organization admins can configure required workflows to run on all or selected repositories within the organization.
Required workflows will be triggered as required status checks for all the pull requests opened on the default branch, which blocks the ability to merge the pull request until the required workflow succeeds.
Individual development teams at the repository level will be able to see what required workflows have been applied to their repository.
In addition to reducing duplication of CI/CD configuration code, required workflows can also help companies with the following use cases: