GitLab permissions documentation: https://docs.gitlab.com/ee/user/permissions.html
Developer access was initially chosen by principal of least privilege; it gave people equivalent access as pre-GitLab, and kept the migration scope lower. Now that our use of GitLab features is increasing, there is access which we should allow, such as Manage CI/CD variables. Drupal.org is still the canonical source for projects and maintainers, we should ensure the project metadata set on Drupal.org can’t be overridden. And we also need to understand the scope of new services we provide - can they be abused, such as excessive cost, spam, time spent supporting them? Nothing stands out as a blocker in the additional permissions, need to go through them one-by-one and double check.
Issue fork drupalorg-3196581
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
drummThis is not as straightforward as we had hoped.
Default branch - the default branch can be changed, which does not trigger a repository synchronization event. The default branch is used very little on Drupal.org, we can reduce our dependency on it. The project Git instructions can be revised to not use the default branch. Otherwise, it is only Drupal.org’s UI to change the default branch. If needed, we could sync the default branch on every push event to keep it in sync.
Maintainers - maintainers can be updated in GitLab, when Drupal.org is the source of truth here. We could block the requests that actually do the updates, like we do for the “leave project” links. This is non-ideal, it would not be obvious why updating the members page doesn't work. We could receive webhook events from GitLab to sync maintainers back to Drupal.org. This is also non-ideal since “Edit project”, “Administer maintainers”, “Maintain issues”, and “Administer releases” access will still be on the project page, and there is no longer one place to manage all access. This would let maintainers decide on granting only GitLab developer access to some members.
Project features and integrations - this is a bigger issue, lots can be changed, including the project name and path.
Comment #4
ranjithraj CreditAttribution: ranjithraj at Free Software Movement of India commentedWe can work with GitLab team and configure feature flags to disable permissions to change project name and path for maintainers role.
Comment #5
drummFeature flags in GitLab seem to be mostly for testing and rolling out functionality, not long-term changes. I did find Create project-level policies framework for deny, which looks like a good match for what we want, and something already planned by GitLab.
In the meantime, we should be able to do this with some load balancer rules restricting what pages can be accessed. It is very non-ideal, but will work.
Comment #9
KarinG👍 I'd love to be able to use Gitlab -> Settings -> Webhooks
Comment #10
PasqualleFinally I understand what is this issue about
Comment #11
drummThis bulk update is now running in batches. Code used is:
Comment #13
drummThis is now complete.
Comment #14
KarinGAwesome! I can see Gitlab -> Settings -> Webhooks now. Thank you!