Skip to content

GitHub Actions: Enhancements to OpenID Connect support to enable secure cloud deployments at scale

OpenID Connect (OIDC) support in GitHub Actions is now enhanced to support secure cloud deployments at scale.

Org & repo admins can use the new OIDC API support to:

  • enable a standard OIDC configuration across their cloud deployment workflows by customizing the subject claim format.
  • ensure additional compliance & security for their OIDC based deployments by appending the issuer url with their enterprise slug
  • configure advanced OIDC policies by using the additional OIDC token claims like repository_id and repo_visibility.

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

In May we shipped a setting for including the pull request title in the default commit message presented to users when squash merging a pull request. We just shipped more options for customizing the default commit message, including using the pull request's description! You can also now customize the default commit messages for merge commit merges. The goal is more predictable, consistent, and useful commit messages for your pull requests, which translate to a more useful Git commit history.

How it works

From repository settings, a maintainer or admin can choose the default format for commit messages produced when merging pull requests:

This selection is used to form a default commit message that gets presented to users on the pull request page when merging a pull request. For example, assume Default to pull request title and description is selected and a user clicks to merge a pull request with this description:

The default commit message will include the pull request's title and description:

The user can then accept this commit message or make changes before merging.


For merge commit merging:

  • Default message: pull request number and head branch on the first line; pull request title on the third line
  • Pull request title: pull request title and number on the first line
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

For squash merging:

  • Default message: commit title and commit message (if the pull request contains a single commit), or the pull request title and number and list of commits (if the pull request contains multiple commits)
  • Pull request title: pull request title and number on the first line
  • Pull request title and commit details: pull request title and number on the first line; commit message (if a single commit) or list of commits (if multiple commits)
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

Additional details

If no message is provided when merging a pull request using the REST API or GraphQL mutation, a default commit message will be formed based on the selected message format and merge method.

The default message format can be managed using the Create a repository or Update a repository REST APIs. See the merge_commit_title, merge_commit_message, and squash_merge_commit_title, squash_merge_commit_message parameters.


We want to hear from you! Tell us what you think and how we can make it better:

Learn more

Learn more about configuring merge commit merging and configuring squash merging.

See more

With this update, organization admins can manage billing settings for codespaces that are created for organization controlled repositories. Admins can choose to opt-in to the organization covering the bill for GitHub Codespaces, enable Codespaces access only for select members of the organization, allow for all organization members, or also include outside collaborators. See the screenshot below, and documentation for Enabling GitHub Codespaces for your organization for more details.

Organization Settings Billing UI

Note: The functionality of this interface remains the same. The label was updated to "Billing" where it used to be labeled "User permissions" to increase clarity. There are no changes required to your settings as a result of this update.

Any GitHub user who can clone a repository and has access to Codespaces will be able to create a codespace for it. To manage who can clone a repository in your Organization see Managing teams and people with access to your repository.

See more