Pre-defined organization roles that grant access to all repositories

Organization owners can now grant a user or team access to all of the repositories in their org with a single click. Five new pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them.

Pre-defined roles ship natively with GitHub. We will add more pre-defined roles over time that support common personas like “CI/CD Admin” or “Security Manager”.

A screenshot showing the five new roles in the organization settings

Introducing pre-defined roles and organization-wide repository permissioning

These five new roles showcase an expansion of organization roles – the ability to also include repository-level base roles (like read) and permissions (like close issue). When granted, the recipient has those privileges on all of the repositories in the organization, current and future. While organization owners cannot yet create organization roles that include repository permissions, that will be supported in the coming months.

A screenshot of the Triage role expanded to show the repository permissions included in the role

This new functionality of organization roles helps organizations replace automation that watches for new repository creation and adds the right users or team to every repository.

UI updates to show role assignments

When users and teams are assigned access across all repositories, this is called out in the team and repository view rather than list all of the accesses.

A screenshot showing that this team has access to all of the repositories in the organization. Below it is a listing of the repositories that the team has been given specific access to.

In addition, the Roles Management view in the organization settings has been updated to show indirect assignments – these are roles that a user or team recieves due to a team that they are a member of. This provides a full accounting of all organization roles that a user or team has within the organization.

A screenshot showing a user that has been granted two roles. One is directly assigned, and has a remove button on the right hand side of the row. The other is indirectly assigned via a team named org-member-parent-team, and does not have a remove option.

The APIs for organization role management have been updated to support these pre-defined roles. You’ll find a base_role field in the description of the organization role, which is the repository role (like read) that is included in the organization role.

You can learn more about organization roles at “Using organization roles“.

Dependabot migration to GitHub Actions for Enterprise Cloud and Free, Pro, and Teams accounts with Actions enabled

Over the next few weeks, jobs generating Dependabot pull requests will start running as GitHub Actions workflows on Github.com accounts with GitHub Actions enabled. This migration will include faster Dependabot runs, increased troubleshooting visibility, self-hosted runner support, and other performance and feature benefits. No additional steps are required, and you should not experience service disruptions during the migration. By the beginning of September, repositories with GitHub Actions enabled should expect to see the jobs that generate Dependabot pull requests run as GitHub Actions workflows.

Running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

Are you so excited for the Dependabot performance benefits that you want to get started today? You can optionally enroll your repositories and/or organizations before the migration begins! Get started by opting in to run Dependabot PR jobs as GitHub Actions workflows here.

If your organization has disabled GitHub Actions by policy, Dependabot will continue to run on the legacy compute provider. If you want to use Dependabot on GitHub Actions, an organization administrator must update your configuration before opting in to run Dependabot on GitHub Actions.

Check out our docs to learn more about Dependabot on GitHub Actions. For additional information, check out our blog post or previous changelog.

See more

Code security configurations are now GA

Code security configurations are now generally available (GA)!

Code security configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories.

Since the beta release on April 2, 2024, we’ve launched several improvements, including configuration enforcement and an API.

We have sunset the old organization-level code security settings UI experience along with the API parameters that complemented it.

All new changes to security settings must happen through the new code security configurations expereince. Organizations that were previously opted out of the experience have been opted back in. All default settings for new repositories have been migrated to a configuration called “Legacy” and automatically applied to new repos.

Learn more about code security configurations, the configurations REST API, or send us your feedback.

See more
View all changes