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

A GitHub Actions workflow run is made up of one or more jobs and each job is associated with a check run. The workflow_job webhook is sent during state transitions of a workflow job. The job state is included in the webhook payload as the action property, which currently takes the values of queued, in_progress, or completed.

With this change, the workflow_job webhook will now support a new waiting state whenever a job is waiting on an environment protection rule, aligning with the waiting state of the corresponding check run. This enables better insight into the progress of a job when using environment protection rules.

In addition, when a job refers to an environment key in its YAML definition, the resulting workflow_job webhook payload will also include a new property, deployment with the metadata about the deployment created by the check run.

Learn more about using environments for deployment Jobs in a Workflow

For questions, visit the GitHub Actions community.

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

See more

We’ve launched a public preview of GitHub Actions Importer, which helps you forecast, plan, and automate migrations from your current CI/CD tool to GitHub Actions.

Doing individual migrations is relatively easy in isolation. However, for those that have a large and established CI/CD footprint, having tooling available to assist with migrations is key to their ability to adopt Actions at scale. In the time that we’ve been developing and using GitHub Actions Importer in its private preview form, we’ve encountered numerous customers that have thousands of pipelines—even in excess of 15K—in their legacy environments that need to be migrated. GitHub Actions Importer is designed to help when manual migration is not feasible, such as when users have a large number of teams that depend on hundreds or thousands of workflows.

Sign up here to request access to the public preview. Once you've been added, you will receive an email at the address registered on your GitHub account with instructions for getting started.

To learn more, see Automating migrations with GitHub Actions Importer and the announcement post on the GitHub blog.

See more

You can now require approval from a user with write permissions to the repository before a workflow run can be triggered from a private fork. This can be useful for some inner source scenarios, where you want to ensure that the code is reviewed before it is run.

image

Learn more about enabling workflows for forks of private repositories
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

Workflows using the ubuntu-latest runner label will soon run on Ubuntu-22.04.

Ubuntu 22.04 became generally available on GitHub-hosted runners in August 2022. Now Ubuntu-22.04 is ready to be the default version for the ubuntu-latest label in GitHub Actions workflows. This change will be rolled out over a period of 8 weeks beginning on October 1, 2022.

If you see any issues with your workflows when they are transitioned to Ubuntu-22.04:

  • File an issue in the runner-images repository
  • Switch back to Ubuntu 20.04 by specifying the ubuntu-20.04 runner label. We will continue to support Ubuntu 20.04.

Note that image software between Ubuntu-20.04 and Ubuntu-22.04 differs by the pre-installed and default versions versions of some tools. See the full list.

See more

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:

runs-on:
  group: my-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.

See more

Starting today, customers can now enjoy larger runners without any pre-configuration work. GitHub now automatically creates a default runner group configured with four larger runners of our most popular sizes so users can start using larger runners right away.

The default runner group is called "Default Larger Runners" and can be managed by Organization or Enterprise admins. To begin using these runners, simply add the label corresponding to the runner of your choice to your workflow file.

Description Label Image
4-cores Ubuntu Runner ubuntu-latest-4-cores Ubuntu – Latest
8-cores Ubuntu Runner ubuntu-latest-8-cores Ubuntu – Latest
16-cores Ubuntu Runner ubuntu-latest-16-cores Ubuntu – Latest
8-cores Windows Runner windows-latest-8-cores Windows Server – Latest

Note that this change only applies to customers who are onboarded to the beta on October 20, 2022 and later.

Interested in learning more about larger hosted runners? Read the announcement here or sign up for the beta here

See more

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.

You can now use the enhanced OIDC support to configure the subject claim format within the OIDC tokens, by defining a customization template at either org or repo levels. Once the configuration is completed, the new OIDC tokens generated during each deployment will follow the custom format.

This enables organization & repository admins to standardize OIDC configuration across their cloud deployment workflows that suits their compliance & security needs.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more

We've made exciting design improvements to GitHub Actions to promote better discoverability and accessibility. The improvements include:

  • An improved navigation experience that makes it easier to search workflows and workflow runs.
  • Added structure to better represent the hierarchy between caller and called reusable workflows.
  • A better mobile experience that is more consistent and supports multiple viewports.

Workflow run

For questions or to share your feedback, visit the GitHub Actions community.

See more

GitHub now supports using the -latest image label on your larger hosted runners. With the -latest label developers can be sure that their workflows use the latest available GA image in GitHub Actions.
latestimagelabel

In general the -latest tag is used for the latest OS image version that is GA. You can find more information about the different image versions in our runner-images repository.

Interested in learning more about larger hosted runners? Read the announcement here or sign up for the beta here.

See more

24-July-2023 Update: Our telemetry shows significant usage of these commands so we have decided to postpone the removal. To learn more, visit the latest changelog post.

To avoid untrusted logged data to use save-stateand set-output workflow commands without the intention of the workflow author we have introduced a new set of environment files to manage state and output.

Starting today runner version 2.298.2 will begin to warn you if you use the save-state or set-output commands via stdout. We are monitoring telemetry for the usage of these commands and plan to fully disable them on 31st May 2023. Starting 1st June 2023 workflows using save-state or set-output commands via stdout will fail with an error. Our telemetry shows significant usage of these commands. Given the number of impacted customers we are postponing the removal.

Patching your actions and workflows

If you are using self-hosted runners make sure they are updated to version 2.297.0 or greater.

Action authors who are using the toolkit should update the @actions/core package to v1.10.0 or greater to get the updated saveState and setOutput functions.

Action and workflow authors who are using save-state or set-output via stdout should update to use the new environment files.

Examples

A workflow using save-state or set-output like the following

- name: Save state
run: echo "::save-state name={name}::{value}"

- name: Set output
run: echo "::set-output name={name}::{value}"

should be updated to write to the new GITHUB_STATE and GITHUB_OUTPUT environment files:

- name: Save state
run: echo "{name}={value}" >> $GITHUB_STATE

- name: Set output
run: echo "{name}={value}" >> $GITHUB_OUTPUT
See more

Actions on GitHub Mobile

Actions are coming to GitHub Mobile! You can now view and manage your pull requests on the go.

Tapping on checks when viewing a pull request now leads to a vastly improved experience, including the ability to view a workflow-run, its jobs and even the logs of completed steps inside.

A run did not go as planned? No problem. GitHub Mobile now supports re-running single jobs, failed jobs as well as entire workflows directly from your mobile device. For checks that are already running, support for cancellation has been added as well.


Read more about GitHub Mobile and send us your feedback to help us improve.

See more

macOS 12 became generally available on GitHub-hosted runners in June 2022. Over the next 10 weeks, jobs using the macos-latest runner label will migrate from macOS 11 to 12. During migration, you can determine if your job has migrated by viewing the Runner Image information in the Set up job step of your logs.

Start using GitHub Actions to build and publish apps for the Apple ecosystem by updating your jobs to include runs-on: macos-latest

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

The macOS 12 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 macOS 12, please let us know by creating an issue in the runner image repository.

See more

Actions runner support for Windows ARM hardware, is now in public beta . This provides teams with the capability to run self-hosted Windows workflows in a Windows ARM64 runtime.

There are some limitations of the current beta product to be aware of:

  • Windows ARM runners are currently using nodejs's "unofficial" win-arm64 builds
  • Some first party actions will not work until a win-arm64 version of that language is released:
    • setup-node
    • Some first party actions don't support the arm64 architecture:
    • setup-python -issue tracking it here

For additional information on how to set up a self-hosted Windows ARM64 runner, please refer to our documentation. If you have any feedback or questions for Actions self-hosted Windows ARM support, you can submit an issue in the runner repository.

See more

Additional information has been added to the payload of github.event for scheduled runs. Before this change, github.event for scheduled runs would only include the cron schedule. This change adds information about the repository, organization, and enterprise (when available).

For questions, visit the GitHub Actions community.

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

See more