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

You can now specify input types for manually triggered workflows allowing you to provide a better experience to users of your workflow. In addition to the default string type, we now support choice, boolean, and environment.

name: Mixed inputs

on:
  workflow_dispatch:
    inputs:
      name:
        type: choice
        description: Who to greet
        options: 
        - monalisa
        - cschleiden
      message:
        required: true
      use-emoji:
        type: boolean
        description: Include 🎉🤣 emojis
      environment:
        type: environment

jobs:
  greet:
    runs-on: ubuntu-latest

    steps:
    - name: Send greeting
      run: echo "${{ github.event.inputs.message }} ${{ fromJSON('["", "🥳"]')[github.event.inputs.use-emoji == 'true'] }} ${{ github.event.inputs.name }}"

Learn more about workflow inputs.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions now supports OpenID Connect (OIDC) for secure deployments to cloud, which uses short-lived tokens that are automatically rotated for each deployment.
This enables:

  • Seamless authentication between Cloud Providers and GitHub without the need for storing any long-lived cloud secrets in GitHub
  • Cloud Admins can rely on the security mechanisms of their cloud provider to ensure that GitHub Actions workflows get the minimal access for cloud resources. There is no duplication of secret management in GitHub and the cloud.

How this works:

  1. Developers set up OIDC trust on their cloud roles to manage access between their deployment workflows and cloud resources.
  2. In each deployment, GitHub Actions workflow presents an autogenerated OIDC JWT token to the cloud provider
  3. Cloud provider validates the claims in the OIDC token against the cloud role definition and provides a cloud access token to connect and deploy to the Cloud only during the workflow run.

image

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

See more

As part of our ongoing efforts to keep GitHub-hosted runners updated and secure, the Windows 2016 virtual environment will be removed from GitHub Actions on March 15, 2022. We recommend you change jobs using runs-on: windows-2016 to use runs-on: windows-latest which will ensure you're always running on the latest version of Windows Server.

If you need to pin your job to a specific version of Windows Server, you can see the full list of supported versions and instructions here: supported-runners-and-hardware-resources

To raise awareness of the upcoming removal, we will temporarily fail jobs using Windows 2016 for two short 'brownout' periods. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:

  • December 1, 2021 4:00pm UTC – 10:00pm UTC
  • February 7, 2022 4:00pm UTC – 10:00pm UTC

Once deprecated, the Windows 2016 image is now excluded from the service level agreement and warranty therefore it is recommended that you move to a supported version of Windows before March 15, 2022.

You can learn more about our software and image guidelines for GitHub-hosted runners in the virtual environment repository. Please contact support if you experience any issues due to this change.

See more

Managing self-hosted runners within an enterprise no longer requires personal access tokens with the admin:enterprise scope. Tighten down the permissions on your token by using the manage_runners:enterprise scope instead. A token with this scope can be used to authenticate to use many endpoints to manage your enterprise's self-hosted runners.

Learn more about self-hosted runners for your Actions workflows.

See more

In March we made a change in GitHub Actions that forced workflows triggered by Dependabot to run with a read-only token. This change was made to protect your repositories from potentially malicious dependencies in the same way we prevent pull requests from forks from having privileged access to your repository. We received a lot of feedback from you on how this impacted your workflows and while it was great to be in a safe configuration by default, you wanted to have the option to continue working as you had prior to this change.

In April we introduced the permissions key in the Actions workflow config which enables you to control which permissions are given to a particular workflow or job.

Starting October 11, 2021 workflow runs on push and pull_request events triggered by Dependabot will begin to respect the permissions specified in your workflows putting you back in control of how you manage automatic dependency updates. The default token permissions will remain read-only.

In addition to the permissions change we are working to enable workflows triggered by Dependabot to use Dependabot secrets. This change will enable you to use those secrets to pull dependencies from private repositories.

Learn more about the permissions key in Actions workflows

For questions, visit the GitHub Actions community

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

See more

Now available in public beta, you can reuse entire workflows as if they were an action. Instead of copying and pasting workflow definitions across repositories, you can now reference an existing workflow with a single line of configuration.

Reusing workflows are great for reducing configuration. Here’s a few examples:

  • Create a workflow for building your homegrown framework so your users can quickly setup CI
  • Create a workflow to deploy to production, and reference it from each repository of your microservice application
  • Create a workflow to roll up end-of-sprint metrics, and encourage every team to add it to their repository

Learn more about reusing workflows.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

macOS Big Sur (11) became generally available on GitHub-hosted runners in August 2021. Over the next 8 weeks, jobs using the macos-latest runner label will migrate from Catalina (10.15) to Big Sur (11). 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.

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 11 Big Sur runner image has different tools and tool versions than macOS 10.15 Catalina. See the full list of changed software.

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

See more

GitHub will stop supporting API Authentication via Query Parameters with Actions on October 6th 2021 at 14:00 UTC. If you are passing credentials via query or path parameters, GitHub will respond with client errors. Please refer to this blog post for details on authenticating API requests to GitHub using the Authorization header.

Removal

  • October 6 2021 at 14:00 UTC
See more

GitHub Actions now supports ephemeral (i.e. single job) self-hosted runners and a new workflow_job webhook to make autoscaling your runners easier. After a job is run, ephemeral runners are automatically unregistered from the service, allowing you to do any required post-job management.

Ephemeral runners are a good choice for self-managed environments where you need each job to run on a clean image. A runner is configured as ephemeral by adding the optional --ephemeral parameter during configuration. Learn more about registering ephemeral runners.

Example ephemeral runner registration:

$ ./config.sh --url https://github.com/octo-org --token example-token --ephemeral

Combine ephemeral runners with the new workflow_job webhook to automatically scale your self-hosted runners in response to your Actions job requests, including the runner labels from the runs-on: key from your workflow. Learn more about the workflow_job webhook and how to use it to autoscale your self-hosted runners.

Get started with automating the configuration of your self-hosted runners by following this automation guide in the runner repo.

See more

GitHub Actions now has an updated management experience for your self-hosted runners that makes it easier to manage runner groups and see the status of your runners. New Runners and Runner groups pages give you flexibility to get a summary view of your runners, or deep dive into a specific runner to edit it or see what job it may be currently running. You'll find both of these experiences in the Actions settings page of your repository or organization.

Runner List

Similarly, a new Runner groups page gives you a cleaner view of all the runner groups you've created, and how many runners are included in each one.

Runner Groups List

Learn more about self-hosting your runners for GitHub Actions.
Learn more about managing access to your runners with runner groups.

See more

You can now use setup-node action to cache dependencies for projects with monorepo and pnpm package manager. Use the optional cache-dependency-path field to specify the path to dependency file(s).

steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
  with:
    node-version: 14
    cache: npm
    cache-dependency-path: 'sub-project/package-lock.json'

For questions, visit the setup-node repository and GitHub Actions community.

See more

Deployment review notifications for your GitHub Actions environments can now be tracked end-to-end using the GitHub app for Microsoft Teams or Slack. You will be notified when a review is pending on your environment, when an approval is completed and you can see the real time status of your deployment.

The following capabilities have been added to our Microsoft Teams and Slack applications:

  1. Deployment review pending notifications for your environments being deployed through GitHub Actions workflow.
  2. Deployment review completed notifications for your environments being deployed through GitHub Actions workflow.
  3. Deployment status notifications for your environments.

For more information visit the GitHub app guidance for Microsoft Teams or for Slack

See more