|
 |
88b334 |
# Best practices for the usage of the CentOS namespace on gitlab
|
|
|
88b334 |
|
|
|
88b334 |
This document highlights the best practices SIGs interested in using the CentOS namespace on gitlab.com
|
|
|
88b334 |
should follow.
|
|
|
88b334 |
|
|
|
88b334 |
## Login in
|
|
|
88b334 |
|
|
|
88b334 |
To login via ACO on gitlab.com, you must use the following link:
|
|
|
88b334 |
|
|
|
88b334 |
## Content
|
|
|
88b334 |
|
|
|
88b334 |
Any and all content hosted on gitlab.com should follow the Requirements the CentOS project has specified
|
|
|
88b334 |
for SIGs: [https://wiki.centos.org/SpecialInterestGroup#Requirements](https://wiki.centos.org/SpecialInterestGroup#Requirements)
|
|
|
88b334 |
|
|
|
88b334 |
## Access
|
|
|
88b334 |
|
|
|
88b334 |
It is expected that access levels are managed via groups on accounts.centos.org (ACO). There are different
|
|
|
88b334 |
ways this can be achieved.
|
|
|
88b334 |
|
|
|
88b334 |
### Simple case
|
|
|
88b334 |
|
|
|
88b334 |
For SIGs who are fine with everyone getting the same level of access, a single group can be created on
|
|
|
88b334 |
https://accounts.centos.org where all the SIG members will be added. This group can then be mapped to that
|
|
|
88b334 |
SIG’s namespace under gitlab.com/centos and be given `owner` access level.
|
|
|
88b334 |
|
|
|
88b334 |
This means, everyone added to this group on accounts.centos.org will be granted `owner` access to each and
|
|
|
88b334 |
every project placed under that SIG’s namespace. This also means, that anyone **not** in this group will have
|
|
|
88b334 |
no access at all.
|
|
|
88b334 |
|
|
|
88b334 |
### More complex case
|
|
|
88b334 |
|
|
|
88b334 |
For SIGs who want or need a more fine tuned model, it is recommended that they create a `groups` namespace under
|
|
|
88b334 |
the SIG’s namespace. In the group namespace will be placed all the groups needed by the SIG and each of this
|
|
|
88b334 |
group will be mapped to a corresponding group on ACO. There should be no project under the `groups` namespace.
|
|
|
88b334 |
The groups can then be given access to any project and the access level of the group can be picked on a
|
|
|
88b334 |
per-project basis.
|
|
|
88b334 |
|
|
|
88b334 |
Here is an example of the structure recommended for the complex case:
|
|
|
88b334 |
|
|
|
88b334 |
```
|
|
|
88b334 |
SIG's namespace
|
|
|
88b334 |
│
|
|
|
88b334 |
├── groups
|
|
|
88b334 |
│ ├── group1-developers [grp1]
|
|
|
88b334 |
│ ├── group2-maintainers [grp2]
|
|
|
88b334 |
│ └── sig [sg]
|
|
|
88b334 |
│
|
|
|
88b334 |
├── rpms
|
|
|
88b334 |
│ └── pkg [grp1+grp2]
|
|
|
88b334 |
│
|
|
|
88b334 |
├── src
|
|
|
88b334 |
│ └──source_tree [grp1]
|
|
|
88b334 |
│
|
|
|
88b334 |
└── sig [sg]
|
|
|
88b334 |
```
|
|
|
88b334 |
|
|
|
88b334 |
## Group membership refresh
|
|
|
88b334 |
|
|
|
88b334 |
To login via ACO on gitlab.com, you must use the following link:
|
|
|
88b334 |
|
|
|
88b334 |
Group memberships are refreshed upon login into gitlab.com. So if someone is added to a group in ACO, they
|
|
|
88b334 |
will need to visit that link again: XXX to have their membership refreshed.
|
|
|
88b334 |
|
|
|
88b334 |
## Group names
|
|
|
88b334 |
|
|
|
88b334 |
It is expected that groups on ACO that are created to manage access on gitlab.com should follow the
|
|
|
88b334 |
corresponding pattern: `<sig>-gitlab-<name>`
|
|
|
88b334 |
|
|
|
88b334 |
Some examples:
|
|
|
88b334 |
|
|
|
88b334 |
- hyperscale-gitlab-maintainers
|
|
|
88b334 |
- automotive-gitlab-kernel-maintainer
|
|
|
88b334 |
- automotive-gitlab-sig-owner
|
|
|
88b334 |
- docs-gitlab-members
|
|
|
88b334 |
- …
|
|
|
88b334 |
|
|
|
88b334 |
## Requesting a namespace or a group
|
|
|
88b334 |
|
|
|
88b334 |
To request a namespace under gitlab.com/centos or the creation of a group on ACO, simply open a ticket at:
|
|
|
88b334 |
[https://pagure.io/centos-infra/](https://pagure.io/centos-infra/)
|
|
|
88b334 |
|