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