githubactions

Subscribe to all “githubactions” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

Today, we are adding a couple of new improvements to required workflows in GitHub Actions.

  • Blocking direct push: Direct pushes are now blocked on branches of the repositories where required workflows are enforced. To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows.

    Block direct push PR

    Block direct push CI

  • Ability to configure required workflows from refs: Required workflows can now be referenced using any branch, tag, or commit SHA from the repository containing the workflow file, during its configuration. This helps you to freeze your required workflow file to a fully validated golden version and gives you the flexibility to move to latest version after testing it thoroughly. The branch, tag, or commit can be specified in the workflow path text field similar to how it is specified for actions within a workflow yaml.

    Required workflows ref

Link to Documentation

Note: Required workflows is currently in beta.

See more

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.

See more

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.

See more

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.

See more

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.

  1. Enterprises: New enterprises will have read-only token.
  2. Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
  3. Organizations not owned by Enterprise: New organizations will have read-only token.
  4. Repositories owned by organization: New repositories will inherit permissions from parent organization.
  5. Repositories owned by personal account: New repositories will have read-only token.
See more

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

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

Learn more about configuration variables

See more

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 at the organization level

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.

Required workflows run at repo

In addition to reducing duplication of CI/CD configuration code, required workflows can also help companies with the following use cases:

  • Security: Invoke external vulnerability scoring or dynamic analysis tools.
  • Compliance: Ensure that all code meets an enterprise’s quality standards.
  • Deployment: Ensure that code is continuously deployed in a standard way.

Learn more about required workflows

See more