actions

Subscribe to all “actions” 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

Actions authors can now specify that their action can run in Node.js 16 by specifying runs.using as node16 in the action's action.yml. This is in addition to the existing Node.js 12 support; actions can continue to specify runs.using: node12 to use the Node.js 12 runtime.

Runners supporting Node.js 16 actions are available on all GitHub-hosted runners and in GitHub Enterprise Server 3.4 and newer. GitHub Enterprise Server 3.3 and newer can manually install a newer runner to add support for Node.js 16 based actions.

As a result, actions authors who move from targeting Node.js 12 to Node.js 16 should release with a new major version number to communicate that there is a possible breaking change for GitHub Enterprise Server 3.3 and earlier.

See more

A beta of the Ubuntu 22.04 runner image for GitHub Actions is now available. Start using GitHub Actions to build software on the latest version of Ubuntu by updating your jobs to include runs-on: ubuntu-22.04

jobs:
  build:
    runs-on: ubuntu-22.04
     steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

The Ubuntu 22.04 Actions runner image has different tools and tool versions than ubuntu 20.04. See the difference between the two OS versions here. Click here for the full list of software available on Ubuntu 22.04.

If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.

While the runner image is in beta, you may experience longer queue times during peak usage hours.

See more

GitHub Actions now lets you generate markdown files and publish them as a job summary.

We have heard a lot of feedback from users asking for the ability to output something beyond simple text. For example, after running a bunch of tests it would be great to see how many passed, failed, or were skipped at a glance rather than digging through hundreds of lines of log output. Now, using the same familiar functionality that powers pull requests and issues, an action can generate custom Markdown content on the run summary generated by each job.

A couple of GitHub Stars with early access have already incorporated this feature into their test loggers for dotnet test and Jest.

To learn more checkout the blog post from the GitHub Actions engineering team

See more

To further reduce the risk of a user using Actions to merge a change into a protected branch that was not reviewed by another person, the organization setting to disallow Actions from approving pull requests, which was introduced in January 2022, has been extended to also limit Actions from creating pull requests.

The Allow GitHub Actions to create and approve pull requests setting can be managed by admins in organization settings under Actions > General > Workflow permissions.

image

See more

The macOS 12 Actions runner image public beta is now available. Start using GitHub Actions to build and publish apps for the Apple ecosystem with the latest version of Xcode (13.3) by updating your jobs to include runs-on: macos-12

jobs:
  build:
    runs-on: macos-12
     steps:
      - uses: actions/checkout@v2
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 12 Actions runner image has different tools and tool versions than macOS 11. See the full list of changed software.

If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.

While the runner image is in beta, you may experience longer queue times during peak usage hours. Follow the public roadmap for information on general availability of this image.

See more

If you manage self-hosted runners for GitHub Actions, you can now specify shell scripts that run before the runner starts running a job from a workflow, and after a job completes.

This allows you to perform a task on your self-hosted runner before a job starts and after a job ends, so you can set up your execution environment and clean up after workflow runs to ensure a consistent state on the runner itself, without requiring users to add that to their workflows.

Learn more about running scripts before or after a job

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

You can now restrict self-hosted runner groups to only be accessible from certain workflows.

In addition to restricting which repositories can access specific enterprise and organization runner groups, administrators can further control access by selecting specific workflow files and versions. Combining this feature with reusable workflow can help you create more secure standard workflows in your organization.

Workflow access dialog

Learn more about restricting access to self-hosted runners

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

Dependency caching is one of the most effective ways to make jobs faster on GitHub Actions. You can now monitor the storage usage of your existing caches and get greater control over cache availability for your action workflows.

Actions users who use actions/cache to speed up their workflow execution times can now use our cache usage APIs to:

  • query the cache usage within each repository and monitor if the total size of all caches is reaching the upper limit of 10 GB,
  • monitor aggregate cache usage at organization level or even at enterprise level, if your GitHub organization is owned by an enterprise account.

Learn more about Managing caching dependencies to speed up workflows.

See more

Support for Actions in internal repositories is now generally available for GitHub organizations owned by an enterprise account.

You can innersource automation by sharing Actions in internal repositories, without publishing them publicly.
And then manage the repository settings or use our API support to allow access to workflows in other repositories:

  • In the same organization or
  • In any other organization in the enterprise

Learn more about Sharing Actions and workflows with your enterprise.

See more

GitHub code scanning supports a wide variety of code analysis engines through GitHub Actions workflows — including our own CodeQL engine. Users can now discover and configure Actions workflow templates for partner integrations straight from their repository's "Actions" tab under a category called "Security". Workflows are recommended based on the repository's content: we will suggest analysis engines that are compatible with the source code in your repository.

Configure workflow

Code scanning and our own CodeQL analysis engine are freely available for public repositories. Analysis engines and services provided by partners might require a subscription. You can also configure code scanning for organization-owned private repositories where GitHub Advanced Security is enabled.

Learn more about code scanning workflows on GitHub Actions tab.

See more

You now have more control over when your self-hosted runners perform software updates. If you specify the --disableupdate flag to the runner then it will not try to perform an automatic software update if a newer version of the runner is available. This allows you to update the self-hosted runner on your own schedule, and is especially convenient if your self-hosted runner is in a container.

For compatibility with the GitHub Actions service, you will need to manually update your runner within 30 days of a new runner version being available. For instructions on how to install the latest runner version, please see the installation instructions for the latest release in the runner repo.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

You can now reference local reusable workflows more easily. With this release, reusable workflows that are in the same repository as the calling repository can be referenced with just the path and filename: {path}/{filename}.

For example:

jobs:
  call-workflow-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml

When referenced this way, the called workflow will be from the same commit as the caller workflow.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

If your GitHub organization is owned by an enterprise account, you can now innersource automation by sharing Actions only within your enterprise without publishing them publicly.
You can store the Action in an internal repository, and then configure the repository settings to allow access to workflows in other repositories:

  • In the same organization or
  • In any other organization in the enterprise

These Actions in internal repositories can only be used by workflows defined in other private and internal repositories but cannot be used in workflows defined within any public repositories.

Learn more about Sharing Actions and workflows with your enterprise.

See more

We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests. This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.

To prevent breaking existing workflows Allow GitHub Actions reviews to count towards required approval is enabled by default. However, an organization admin can disable it under the organization's Actions settings.

image

See more

GitHub is updating the retention policy as it pertains to Checks data. Checks created by GitHub Actions and third-party GitHub Apps will be affected by the new retention policy.

Starting on February 14th, 2022 GitHub will begin archiving detailed checks data older than 400 days. As part of the archiving process we will create a rollup commit status representing the state of all checks for that commit. As a consequence, the merge box in any pull request with archived required checks will be in a blocked state and checks will need to be rerun in order to merge it.

Learn more about checks

See more

Windows Server 2022 became generally available on GitHub-hosted runners in November 2021. Over the next 8 weeks, jobs using the windows-latest runner label will migrate from Windows Server 2019 to Windows Server 2022. During migration, you can determine if your job has migrated by viewing the Virtual Environment information in the Set up job step of your logs.

Use GitHub Actions to build your apps with the latest Visual Studio 2022 by updating your workflows to include runs-on: windows-latest

jobs:
  build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-dotnet@v1
      - name: Build
        run: dotnet build
      - name: Run tests
        run: dotnet test

The Windows Server 2022 runner image has different tools and tool versions than Windows Server 2019. See the full list of changed software.

If you spot any issues with your workflows when using Windows Server 2022, please let us know by creating an issue in the virtual-environments repository.

See more

Previously, when running a job that requires a self-hosted runner, GitHub Actions would look for self-hosted runners in the repository, organization, and enterprise, in that order.

We are changing that behavior so that the first available matching runner at any level will run the job in all cases. This allows jobs to be sent to self-hosted runners much faster, especially for organizations and enterprises with lots of self-hosted runners.

Learn more in the documentation

See more

Getting started with GitHub Actions just got easier! Now, when you want to create an Actions workflow in the Actions tab of your repository, the workflow recommendations will be based on repository analysis that detects elements, such as programming language, build tools, frameworks, and package managers.

For example, if a repository contains a Node.js application that has been containerized, then the repository analysis will prioritize showing you container and Node related workflows.

We have also extended recommendations to the deployment category.
and added search and filters to help you find the right workflow that matches your unique requirements.

Learn more about this GitHub Actions improvement.

See more