Git tag & branches permissions management
(elaboration of this can be seen in story #8352)
At repository level
On "Permission" tab, git admin can decide to use either the default, repository wide, permission settings (current mode) or to activate the "per tags/branches" setting described bellow.
Regarding following proposal please note that:
Example 1: default setup
- Read to Contributors
- Write to Developers
- Rewind to nobody
Read
====
Select the user groups allow to read: Contributors
Write
=====
Branches
--------
Pattern | Write | Rewind |
--------|------------|--------|
* | Developers | - |
Tags
----
Pattern | Write | Rewind |
--------|------------|--------|
* | Developers | - |
Corresponding gitolite:
repo mozilla/thunderbird
R = @Contributors
RW refs/heads/.* = @Developers
RW refs/tags/.* = @Developers
Example 2: 'official' tags to Integrators
Read
====
Select the user groups allow to read: Contributors
Write
=====
Branches
--------
Pattern | Write | Rewind |
--------|------------|--------|
* | Developers | - |
Tags
----
Pattern | Write | Rewind |
------------|-------------|--------|
official/* | Integrators | - |
* | Developers | - |
Corresponding gitolite conf
repo mozilla/thunderbird
R = @Contributors
RW refs/heads/.* = @Developers
RW refs/tags/official/.* = @Integrators
- refs/tags/official/.* = @all
RW refs/tags/.* = @Developers
Example 3: 'dev' branches are authorized to Contributors
Read
====
Select the user groups allow to read: Contributors
Write
=====
Branches
--------
Pattern | Write | Rewind |
--------|--------------------------|--------|
dev/* | Contributors, Developers | |
* | Developers | - |
Tags
----
Pattern | Write | Rewind |
------------|-------------|--------|
official/* | Integrators | - |
* | Developers | - |
Corresponding gitolite conf
repo mozilla/thunderbird
R = @Contributors
RW refs/heads/dev/.* = @Contributors @Developers
- refs/heads/dev/.* = @all
RW refs/heads/.* = @Developers
RW refs/tags/official/.* = @Integrators
- refs/tags/official/.* = @all
RW refs/tags/.* = @Developers
Post notes
- We are likely to propose a "group based UI" (like it's done in tracker field permissions) because sometimes you just want to know what a group can do
- Permissions are always explicit, in example n°3 even if developers have access to refs/heads/.* they must be explicitly declared for refs/heads/dev/.*
- Consequence, for example n°2 and n°3, integrators can only create official tags, they are note allowed to commit in any branch or to create any tag. If we want to grant them this, we need to declare them.
Tracability & auditability
An event is added in project history when the pattern or associated group change
At project level
- git admin can define a default pattern rule that will apply to all newly create repository
- this default value is only used at repository creation
- if pattern become refts/tags/REF/* after a while, repository already created must be updated manually
- this value is inherited at project creation
- so If I defined a pattern ref in my main template, all projects will have it by default (unless git admin explicitly change it
Site admin have a fine grain control on git permissions
Overall strategy
In Tuleap ways of doing things, project administrators have 100% control and can change everything in their project.
Hence, adding a fine grain control by site administrator only of git tag pattern at project level is against Tuleap rules.
So we propose below an alternative:
- project and git admin can modify patterns
- but site administrator can be notified of such changes
Site admin notification
In site administration, I can select one of several project event (ex: git_permissions_update, git_tag_update) and associate email addresses.
As soon as one project modify a git permission or a git tag pattern, configured emails will be notified.