The Actions Tab Gets a New Look

The Actions tab is getting an exciting new look and many new features based on feedback from our users. Today you will see the following improvements:

  • Runs are now organized by the workflows that currently exist on the repository. To see older runs – like those from workflows with a different name or new ones from a branch, you can check out the “All workflows” filter.
  • In addition to linking your runs to their respective pull requests, there’s now the option to cancel a run that’s in progress as well as view the workflow file within the context of that run.
  • The “New workflow” button takes you back to the “Get started with GitHub Actions” page.
  • With a few performance tweaks, the tab now loads even faster!

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

Team Synchronization (general availability)

Team Synchronization is now generally available for GitHub Enterprise Cloud organizations. With team synchronization, Enterprise Cloud organizations can synchronize Azure Active Directory (Azure AD) group membership to GitHub teams. We will make this functionality available for enterprise account SAML integrations and extend support to additional identity providers in the near future.

Learn more about team synchronization across GitHub and Azure AD

See more

UI changes in GitHub Actions checks

GitHub Actions uses the Checks API for representing and storing information about job executions. These checks appear in many places in the GitHub UI such as the merge box of a pull request, or when clicking on a status icon next to a commit message. Among other things this allows users to configure protected branch rules based on GitHub Actions checks.

At the same time, Actions can be triggered not just when somebody pushes code to GitHub but when many other events occur. In these cases, GitHub Actions looks for workflow files in the default branch of the repository and creates and associates the checks with the SHA of the latest commit. This allows for debugging the workflow file, but also means that these checks, not created by a push event, appear in places such as the merge box in a pull request.

We have found that this can be noisy and not relevant in the context of a pull request. It can also cause friction when protected branch rules are enabled. As of today, we’re deploying a change to remove checks generated due to events other than push and pull_request from the context of pull requests or in the calculation of commit statuses. These checks will be available in the Actions tab for observability.

This change only affects checks created after September 18.

If you have any questions or thoughts about these changes, let us know in the GitHub Community Forum’s Actions board.

See more
View all changes