This article describes the ways in which an organization owner can restrict the creation of repositories in their GitHub Enterprise Cloud organization.
Note that organization owners implicitly bypass all policies and can always create any type of repository.
Also note that Repository Policies are additive, and multiple policies can be combined to achieve more complex behaviors.
The most straightforward way to limit repository creation is to simply disable the ability for members to create repositories at all.
Under the "Member privileges" section of the organization settings, under the "Repository creation" heading, disable the checkboxes for "Private" and "Internal" and click "Save".
Note that these must be enabled to conditionally allow specific members to create repositories.
Disabling this setting will mean no one but owners can create repositories, regardless of any additional policies which might otherwise grant permission.
Often you'll want to enable certain teams within your organization to create repositories, but restrict most other members from doing so.
First, ensure that the team you wish to allow has already been created. Next, you'll need to create a Repository Policy.
Under the "Policies" section in the organization settings, click on "Repositories" and then "New Policy".
On the policy creation page, you'll want to choose a descriptive name for your policy and set the Enforcement to Active.
Next, select the Team you'd like to allow to create repositories from the "Add Actors" dropdown. You may add as many Teams as you want to be able to create repositories.
Next, select "All Repositories" from the dropdown under the "Target repositories" heading.
Finally, check the "Restrict Creation" checkbox and click "Create".
Note that you will need to enable the creation of repositories in the Member Privileges settings for this policy to take effect.
See the "Enable / Disable All Creation" section above for details, but check the checkboxes of the repository types you'd like to allow.
To allow a specific Team to create repositories of a particular visibility and restrict others, you'll want to create another Repository Policy.
Under the "Policies" section in the organization settings, click on "Repositories" and then "New Policy".
On the policy creation page, you'll want to choose a descriptive name for your policy and set the Enforcement to Active.
Next, select the Team you'd like to allow to create repositories of the chosen visibility from the "Add Actors" dropdown. You may add as many Teams as you want.
Next, select "All Repositories" from the dropdown under the "Target repositories" heading.
Next, check the "Restrict Visibility" checkbox and select the type of repository you users NOT in the specified team to use. Members of the chosen Team(s) will be able to bypass this policy and will be able to create the type of repository that is not checked. Note that "Public" repositories don't exist in our GitHub Enterprise Cloud tenant.
Finally, click "Create".
The example above will force all repositories to be Private, unless a member of the Managers team is creating the repository / changing the visibility. Therfore, in this example, Managers are the only users who will be able to create Internal visibility repositories.
Note that you will need to enable the creation of both repository types in the Member Privileges settings for this policy to take effect.
See the "Enable / Disable All Creation" section above for details, and check both the checkboxes.
To allow the creation of a repository so long as it follows a naming convention, we can again use a Repository Policy.
Under the "Policies" section in the organization settings, click on "Repositories" and then "New Policy".
On the policy creation page, you'll want to choose a descriptive name for your policy and set the Enforcement to Active.
If you'd like to allow a Team to disregard the required naming convention, you may add the Team to the Allow List by selecting them under the "Add Actors" dropdown.
Next, select "All Repositories" from the dropdown under the "Target repositories" heading.
Next, check the "Restrict names" checkbox and choose either "Must Match" or "Must Not Match" from the dropdown, and supply a regular expression.
You can use the pattern testing utility to valid your expression.
Finally click "Create".
The above example will ensure that all repositories are prefixed with "ncstate-".
This example gets a bit complicated, and requires some maintenance when adding new Teams, but works to enforce a naming convention for each Team in your organization.
There are two approaches to accomplishing this goal: reserved prefixes and explicit allowed prefixes.
This approach combines a policy which applies a general naming prefix to ensure conformity, while reserving specific tags for an individual team.
For example, you may have a general policy which applies to everyone which restricts repository names to match a pattern of "^ncstate\-[a-z]{3}\-".
This requires all repositories to start with "ncstate-", followed by a three letter section with a dash, and then any value.
Then, for each team you'd create a policy with a Must Not Match pattern for the specific prefix that Team should use, and add the Team to the Allow List.
To continue with our example, you may have an "ABC" team, and the Must Not Match policy would be "^ncstate\-abc\-", with the ABC Team on the Allow List.
This would require all repositories to be created with the general form of "ncstate-aaa\-", but only the ABC Team would be able to use the specific "ncstate-abc-" prefix.
Note that other valid patterns would be allowed, as long as it is not reserved for a Team, so it doesn't require an exact prefix, but gets close enough that most users should play by the rules.
This is the most complex pattern, and requires upkeep when new Teams are created, but ensures that a Team can only use the specific pattern.
For each Team, create a Repository Policy that restricts the naming convention to the desired pattern, and add all Teams EXCEPT the desired Team to the Allow List.
Repeat for every Team, and each Team will only be able to create repositories that match their specific pattern.
Note that any new Teams will not be able to create repositories until all these policies are updated, since they will be required to match multiple conflicting patterns.
For example, having Teams A, B, and C, you would have the following policies:
- Policy A = Allow B, C, must match "^Team-A"
- Policy B = Allow A, C, must match "^Team-B"
- Policy C = Allow A, B, must match "^Team-C"