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

GitHub Actions: Job summary updates

We are making changes to job summaries and logs in GitHub Actions that will impact customers using self-hosted runners. Over the next six months, customers using self-hosted runners will need to ensure machines have appropriate network access to communicate with the GitHub hosts below so that job summaries and logs emitted from Actions workflows can work as expected.

  • results-receiver.actions.githubusercontent.com
  • productionresultssa*.blob.core.windows.net

After July 31, 2023, if you are using self-hosted runners and have not updated your network access settings to allow the aforementioned hosts, your job summaries and logs may not display correctly.

For more details see
Communication between self-hosted runners and GitHub.

For questions, visit the GitHub Actions community.

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

See more

GitHub Actions: OpenID Connect token now supports more claims for configuring granular cloud access

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.
Each OIDC token includes standard claims like the audience, issuer, subject and many more custom claims that uniquely define the workflow job that generated the token. These claims can be used to define fine grained trust policies to control the access to specific cloud roles and resources.

  • We now support more custom claims within the token : actor_id, repository_id, repository_owner_id
    workflow_ref, workflow_sha and job_workflow_sha – to help uniquely verify the source of a workflow job, even if the job references a reusable workflow.
  • We are also adding these new attributes as default environment variables and also to github context

These changes enable developers to define more advanced access policies using OpenID connect and do more secure cloud deployments at scale with GitHub Actions.

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

See more

GitHub Actions – Support for configuration variables in workflows

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

GitHub Actions – Support for organization-wide required workflows 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 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

GitHub Actions: SBOMs now attached to hosted runner image releases for Ubuntu & Windows

GitHub Actions hosted runner images are now more secure than ever, with the ability to see exactly what software is pre-installed on the image that was used by the runner during your build. GitHub now attaches a software bill of materials (SBOM) as an asset to each image release for Ubuntu and Windows. Support for Mac runners is targeted for Q1 2023.

In the context of GitHub Actions hosted runners, an SBOM details the software pre-installed on the virtual machine that is running your Actions workflows. This is useful in the situation where there is a vulnerability detected, you will be able to quickly tell if you are affected or not. If you are building artifacts, you can include this SBOM in your bill of materials for a comprehensive list of everything that went into creating your software.

To check out the new files, head over to the runner-images repository release page now or check out our docs for more information.

See more

GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA

The actions and reusable workflows from private repositories can now be shared with other private repositories within the same organization, user account, or enterprise.
See managing the repository settings and managing the enterprise repository settings to allow access to workflows in other repositories.

We have also added the API support to configure Actions share policy. Refer to API support or API support for Enterprise for more details.

Learn more about Sharing actions and workflows from your private repository, Sharing actions and workflows with your organization, and Sharing Actions and workflows with your enterprise.

See more

Extending Checks Retention Policies to GHES

Previously, data generated from Checks were not managed by a retention policy and would therefore grow unbounded. A recent change was made to GitHub.com that archives checks data after 400 days and deletes records 30 days after they are archived.

This change will be extended to GitHub Enterprise Server (GHES) version 3.8 with additional features that will allow administrators to:

  • Enable/disable checks retention
  • Set a custom retention threshold
  • Set a custom hard-delete threshold

This pertains to all Checks data, including those that are generated from GitHub Actions and the Statuses API.

For questions, visit the GitHub community or get started with Checks API today.

See more

GitHub Actions workflow notifications in Slack and Microsoft Teams

We are excited to announce that GitHub app in Slack and Microsoft Teams now supports GitHub Actions workflow notifications.

image

You can now subscribe to your repository and get notified about GitHub Actions workflow run status from your channel or personal app.
/github subscribe owner/repo workflows

  • You will get notified when a new workflow run is triggered. And you can track the live status of the jobs.
  • You can track the approval notifications as a reply in the thread and you can approve the notifications directly from channel/personal app.
  • Once the workflow is completed, you will get a update as a reply in the thread so that you can complete context and history about the workflow run.
  • If something fails, you can choose to rerun the workflow in place and you can also enable debug logs if needed.

Workflow notification filters

Getting notified about each and every workflow run can be noisy. So, we are providing you capability to filter the notifications based on your requirement. You can filter your actions workflows notifications based on name, event, actor and/or branch. You can filter the notifications as below.

/github subscribe owner/repo workflows:{name:"your workflow name" event:"workflow event" branch:"branch name" actor:"actor name"}

  • name: Name of your workflow
  • event: The event on which the workflow is triggered. View the list of all available events.
  • actor: The person who triggered or responsible for running of the workflow.
  • branch: The branch on which the workflow is running. Only in the cases where pull_request event is included, the branch will be the target branch the pull request is created for.

Note: When you configure workflow notifications without passing any filters, it is configured by default for workflows triggered via pull requests targeting your default branch.

For more information, please visit the GitHub app guidance for Slack and Microsoft Teams.

See more

GitHub Actions: Larger Runners using Ubuntu-latest label will now use Ubuntu-22.04

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

Ubuntu-22.04 is now the default version for the ubuntu-latest label for GitHub Actions standard runners workflows. Larger runners will now use the Ubuntu-22.04 as the -latest version starting 15 December 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

Webhook enhancements for environment protection rules

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

Introducing GitHub Actions Importer

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

GitHub Actions: Require approval for running workflows from private forks

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

GitHub Actions: Ubuntu-latest workflows will use Ubuntu-22.04

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

GitHub Actions: Restrict workflows to specific runners using runner group names

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
View more changes