On this page
- Initial setup
- Onboarding a Subsystem Maintainer
- Using the Drupal.org Maintainers UI
- Using the GitLab User Management UI
- Adding a new provisional committer with commit access
- Process A: Add the user to an existing branch match
- Process B: Limiting the new committer to a branch tag that does not currently exist
- Upgrading a provisional Maintainer to a full committer
- Using the Drupal.org Maintainers UI
- Using the GitLab UI
- Deleting tags as a full Maintainer
[Archive] Adding and removing a Subsystem or Topic maintainer
Using the GitLab UI for these tasks is no longer needed. This page is kept for reference only.
Instead, use Add or remove a Subsystem or Topic maintainer
Initial setup
-
In GitLab as a user with the Maintainer permissions (this is currently any approved core committer) navigate to Settings > Repository.

-
Expand Protected Branches and click “Add a new protected branch".

-
Set the branch name to *.
Ensure “Create wildcard *” is used for the Branch name.
Set Allowed to Merge to “Maintainers”.
Set Allowed to push and merge to “Maintainers”.The remaining values should be set to disabled in order to keep the repository operating as close to as it has been operated to date. A followup issue may be created by the Core Committers to enforce a stricter policy upon themselves going forward.
-
The final result should look as follows.

While maintainers have historically had the permission to force push, D.O. Hooks have prevented this as all D.O. branches present have an open release in them. Force push can be enabled if deemed useful without impacting the end result of restricting subsystem maintainers. Changing this option will not overriding existing commit hooks.
-
Click the Protect button.
-
Navigate to Protected tags and click Add Tag.

-
Set the tag name to “*”.
Ensure Create wildcard * is selected.
Set “Allowed to create” to “Maintainers”. -
The final version should looks as below.

-
Click the Protect button.
Only users with the Maintainers role may now push/delete/merge code or create/delete tags.
Onboarding a Subsystem Maintainer
Two options are currently available depending upon what the Drupal Core team decides to utilize.
Using the Drupal.org Maintainers UI
The first option is using the D.O. Users UI. Users will be listed on the D.O. project page.
-
As a user with the role “Administer maintainers” in the Drupal Core project navigate to https://www.drupal.org/project/drupal and click “Maintainers”.

-
Add a new user (or select an existing user) and check the permission for “Write to VCS”

While D.O. wording currently indicates this user will be allowed to commit code, unless they are granted the Administer maintainers role they will be added to GttLab with the Developer role. The developer role has been restricted from committing code in the Setup phase of this documentation.
-
Save the user update.

The User will now be a Developer in GitLab.
Using the GitLab User Management UI
Users added using only this method may not appear on the Drupal.org project page.
-
Open the project in GitLab and navigate to Manage > Members.

-
Click Invite Members.

-
Fill out the form inviting subsystem maintainers as needed.
Ensure the role is Developer.
-
Select Invite.
The user now has the developer role. The Developer role has been restricted from committing code in the Setup phase of this documentation.
Initial setup
-
In GitLab as a user with the Maintainer permissions (this is currently any approved core committer) navigate to Settings > Repository.

-
Expand Protected Branches and click “Add a new protected branch".

-
Set the branch name to *.
Ensure “Create wildcard *” is used for the Branch name.
Set Allowed to Merge to “Maintainers”.
Set Allowed to push and merge to “Maintainers”.The remaining values should be set to disabled in order to keep the repository operating as close to as it has been operated to date. A followup issue may be created by the Core Committers to enforce a stricter policy upon themselves going forward.
-
The final result should look as follows.

While maintainers have historically had the permission to force push, D.O. Hooks have prevented this as all D.O. branches present have an open release in them. Force push can be enabled if deemed useful without impacting the end result of restricting subsystem maintainers. Changing this option will not overriding existing commit hooks.
-
Click the Protect button.
-
Navigate to Protected tags and click Add Tag.

-
Set the tag name to “*”.
Ensure Create wildcard * is selected.
Set “Allowed to create” to “Maintainers”. -
The final version should looks as below.

-
Click the Protect button.
Only users with the Maintainers role may now push/delete/merge code or create/delete tags.
Onboarding a Subsystem Maintainer
Two options are currently available depending upon what the Drupal Core team decides to utilize.
Using the Drupal.org Maintainers UI
The first option is using the D.O. Users UI. Users will be listed on the D.O. project page.
-
As a user with the role “Administer maintainers” in the Drupal Core project navigate to https://www.drupal.org/project/drupal and click “Maintainers”.

-
Add a new user (or select an existing user) and check the permission for “Write to VCS”

While D.O. wording currently indicates this user will be allowed to commit code, unless they are granted the Administer maintainers role they will be added to GttLab with the Developer role. The developer role has been restricted from committing code in the Setup phase of this documentation.
-
Save the user update.

The User will now be a Developer in GitLab.
Using the GitLab User Management UI
Users added using only this method may not appear on the Drupal.org project page.
-
Open the project in GitLab and navigate to Manage > Members.

-
Click Invite Members.

-
Fill out the form inviting subsystem maintainers as needed.
Ensure the role is Developer.
-
Select Invite.
The user now has the developer role. The Developer role has been restricted from committing code in the Setup phase of this documentation.
Adding a new provisional committer with commit access
This is also used when a Subsystem Maintainer becomes a provisional core committer.
-
If not already done follow the steps in “Onboarding a Subsystem maintainer“.
-
Navigate to Settings > Repository in GitLab.
-
Expand out Protected Branches.
- If adding the user to an existing branch match (such as * ) start process A, otherwise proceed to process B.
Process A: Add the user to an existing branch match
-
Locating the existing branch tag and under Allowed to merge and Allowed to push and merge search for the new provisional committer.

-
The final should look similar to the following.

It is saved automatically.
Process B: Limiting the new committer to a branch tag that does not currently exist
-
Add a new Protected Branch.
-
Search for the new Provisional committer in the “Allowed to merge” and “Allowed to push and merge” windows.

Disable all other options. The core team can consider changing this policy at a future date.
-
The final page should appear similar to the following.

-
Click Protect
The user now has the ability to commit/merge code to the appropriate branches without being granted the ability to manage project settings or add additional users.
Upgrading a provisional Maintainer to a full committer
Using the Drupal.org Maintainers UI
-
As a user with the role “Administer maintainers” in the Drupal Core project navigate to https://www.drupal.org/project/drupal and click “Maintainers”.
-
Locate (or add) the new Provisional maintainer with at least the Write to VCS and Administer Maintainers roles.

These roles will (currently) grant the user the Maintainer role in GitLab.
-
Open the project in GitLab and navigate to Settings > Repository.

-
Navigate to Protected Branches and locate the branch restriction with the Maintainer.

-
Click to deselect the account on both “Allowed to merge” and “allowed to push and merge”.
-
A save is not required, the change will take effect immediately.
The user is now a maintainer and the manual additional of commit privileges has been removed.
Using the GitLab UI
-
Open the project in GitLab and navigate to Manage > members.

-
Locate the Subsystem Maintainer account and choose “Maintainer”.

-
Navigate to Settings > Repository.

-
Navigate to Protected Branches and locate the branch restriction with the Maintainer.

-
Click to deselect the account on both “Allowed to merge” and “allowed to push and merge”.
-
A save is not required, the change will take effect immediately.
The user is now a maintainer and the manual addition of commit privileges has been removed.
Deleting tags as a full Maintainer
When protected tags are enabled the ability to delete tags via GIT Push is disabled in GitLab. A maintainer may still delete tags however it must be done via the GitLab UI or API.
-
Open the project in GitLab and navigate to Code > Tags.

-
Locate the tag you desire to delete and click.

-
A popup window will ask you to confirm deleting the protected tag. Follow the instructions and click “Yes, delete protected tag”.

The tag will be deleted and a new version can be submitted.
Help improve this page
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion