actions

We changed the GitHub Actions self-hosted runner group default access to disable "Allow public repositories." This change impacts runner groups created before Sep 4, 2020 and changes those runner groups to a more secure default.

GitHub does not recommend the use of self-hosted runners with public repositories. If you are aware of the risks, and you choose to run workflows on your public repositories, you can update your runner group access to “Allow public repositories.”

Learn more about managing access to self-hosted runners.

You can now change the maximum retention days for artifacts and logs in GitHub Actions, allowing you to better manage your storage space and to comply with your organizational retention policies.

With custom retention days, you can delete artifacts and logs sooner than the existing default of 90 days. Optionally, for private, internal and GitHub Enterprise repositories, you can retain artifacts and logs for over a year.

Retention days can be defined in the Actions Settings or in the YAML at an enterprise, organization, repository, or an individual artifact level.

Here’s an example of changing retention days in Actions Settings and in the YAML:

- uses: actions/upload-artifact
  with:
    name: my-artifact
    path: ./my_path
    retention-days: 30

Learn more about custom artifacts and log retention days and visit the GitHub Actions community forum for questions.

You can now fine-tune access to external actions. These updated settings make it easier to achieve your security and compliance goals with GitHub Actions.

• You can limit external actions to just those created by GitHub, those in the Marketplace that were created by verified authors, or a combination
• You can optionally list specific external actions. Wildcards, tags, and SHAs enable flexibility and specificity

Learn more about external action policies

For questions please visit the GitHub Actions community forum

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

Starting today you can temporarily disable a GitHub Actions workflow either in the UI or through the API. With this functionality you can stop a workflow from being triggered without having to delete the file from the repo. Later you can easily re-enable it again from the UI or through the API.

This new functionality can be useful in some situations, for example:

• An error on a workflow is producing too many or wrong requests impacting external services negatively.
• You want to temporarily pause a workflow that is not critical and is consuming too many minutes on your account.
• You want to pause a workflow that is doing requests to a service that is down.
• You are working on a fork and you don't need all the functionality of some workflows it includes (e.g. scheduled workflows).

For questions please visit the GitHub Actions community forum

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

You can now use images from private registries in job and service containers.

Job and Service containers in GitHub Actions allow you to containerize your CI environment and make databases, caches, or other services available to your tests. Previously those containers had to come from a public container registry which limited the usefulness for some customers. Additionally, we had numerous requests from the GitHub community forums for private registry support.

Here’s an example of using private images from Docker Hub and GitHub Container Registry:

jobs:
  build:
    container:
      image: octocat/ci-image:latest
      credentials:
        username: mona
        password: ${{ secrets.docker_hub_password}}
    services:
      db:
        image:  ghcr.io/octocat/testdb:latest
        credentials:
          username: ${{ github.repository_owner }}
          password: ${{ secrets.ghcr_password }}

For questions, visit the GitHub Actions community forum.

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

Logs for GitHub Actions have gotten a significant update. Some major enhancements and new features include:

• Styling changes to improve readability
• An improved search experience for large logs
• Auto-scrolling and expansion if a step fails
• Redesigned errors and warnings
• Clickable URLs
• Support for more colors
• Full-screen mode

Check out our detailed blog post on the new Logs Experience for more information.

For questions please visit the GitHub Actions community forum

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

Account and billing admins can now provide a list of email addresses to receive billing notifications, including threshold notifications for Actions and Packages.

The email addresses may belong to users such as repo admins, individuals who are not actually part of your GitHub organization (e.g. in the procurement department at your company), or even be distribution lists.

Visit the documentation on how to set a billing email to learn more.

You can now create reusable actions using shell scripts and even mix multiple shell languages in the same action. You probably have a lot of shell script to automate many tasks, now you can easily turn them into an action and reuse them for different workflows. Sometimes it’s easier to just write a shell script than JavaScript or Docker. Now you don’t have to worry about wrapping your scripts in Docker containers.

Here’s an example of how you can use composite run steps actions:

workflow.yml:

jobs:
  build:
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v2
    - uses: octocat/say-hello@v1
      with: 
        name: OctoCat

octocat/say-hello/action.yml:

inputs:
  name: 
    description: 'Your name'
    default: 'No name provided'
runs:
  using: "composite"
  steps: 
    - run: echo Hello ${{ inputs.name }}.
      shell: bash
    - run: echo "Nice to meet you!"
      shell: pwsh

Learn more about composite run steps and visit the GitHub Actions community forum for questions.

We’ve made some changes in GitHub Actions to better support communities who have chosen to move away from using master as their default branch name.

We have updated all of our starter workflows to use a new $default-branch macro rather than the previously hardcoded master. You can take advantage of this feature in your custom starter workflow templates as well.

In addition, we have renamed the default branch for most of the GitHub-authored actions from master to main. All of your workflows that reference the old branch name will still work. However, you’ll see a prompt to change to the new name when you edit the workflow on the web.

This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch. To learn more about the changes we’re making, see github/renaming.

We have released the ability to delete completed workflow runs in the Actions tab. If you have write access to the repository, you can now see a new option to delete the workflow run in the dropdown menu.

You'll be advised that deleting a workflow run could prevent existing PRs from being able to be merged. This can happen if you have protected branch rules requiring certain status checks to pass.

You can now create workflows that are manually triggered with the new workflow_dispatch event.
You will then see a ‘Run workflow’ button on the Actions tab, enabling you to easily trigger a run.
You can choose which branch the workflow is run on.
In addition, you can optionally specify inputs, which GitHub will present as form elements in the UI. Workflow dispatch inputs are specified with the same format as action inputs.

For example:

on: 
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'  

The triggered workflow receives the inputs in the github.event context.

For example:

jobs:
  printInputs:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo "Log level: ${{ github.event.inputs.logLevel }}"
        echo "Tags: ${{ github.event.inputs.tags }}" 

If you have any questions or thoughts about these changes, we recommend asking in our GitHub Community Forum’s Actions Board!

You can now create workflow templates, making it easier to promote best practices and consistency across your organization.

• Workflow templates are defined in a .github repository, enabling you to leverage all the power of GitHub’s collaborative capabilities and providing full auditability
• You can optionally define rules for which repositories are a best fit for the templates

Learn more about workflow templates

For questions please visit the GitHub Actions community forum

You can now re-run all jobs after a successful run. Previously, it was only possible to re-run all jobs if one or more jobs failed.

For questions, visit the GitHub Actions community

The GitHub Actions runner now sets the CI=true environment variable by default.

Learn more about GitHub Actions default environment variables