Creating GitLab groups, projects and users
Agile Collective's GitLab instance (gitlab.agile.coop) now contains 350+ projects, 120+ users and 80+ groups. It is important for security and usability that projects, users and groups are created with the correct permissions and settings.
Groups
Groups should be internal to ensure that logged in users can see the group and create projects in it.
Give the group a descriptive name, but shorten this as much as possible for the URL slug.
Group descriptions and avatars are nice to have, but not essential.
The Agile Collective (agile) group should always be set as a maintainer on the group. This ensures that all Agile Collective users have access and can make changes to projects in the group. To do this, once the group has been created, go to 'Members', click 'Invite group' and search for the agile group. Set the access level to 'Maintainer' and click 'Invite'. The Agile Collective group should now be listed under 'Groups'.
Projects
Projects should be private to ensure that only users with explicit permissions to access the project. As long as the project is in a group with the Agile Collective group added as maintainers then all Agile Collective users will have access to the project.
If you want the project to be publicly available, make the project public and set the group to Agile Collective public repos (agile-public).
Give the projects a short but descriptive name, select the appropriate group for the project or create a new one and set the project slug to something short but distinctive.
A project description and avatar are nice to have, but not essential. These can be set after the project has been created at 'Settings' > 'General'.
Old projects should be archived. There is a problem when there are multiple repos for a site (usually because it's been redeveloped) and people searching GitLab for the site find an old site repo rather than the current one. To deal with this, when a repo becomes defunct, add a description saying why this is with a link to the new repo and archive the repo. To archive a repo go to 'Settings' > 'General' > 'Advanced' and click 'Archive project'.
Use deploy keys when a server or service needs access to a project repo. When deploying a site to a server add the public SSH of the deploy / admin user as a read only deploy key. This can be set at 'Settings' > 'Repository' > 'Deploy Keys'.
Users
Agile Collective users
Set the account names and email as appropriate. The projects limit should be something large; 1000 is good. Once the account is created, the new user will be able to set a password and add SSH keys, although it's possible to masquerade as the user and set these if necessary.
Only sysadmins and members of the Tech Circle should be admin users. Regular users can create groups and projects, but only admin users can create user accounts. If there's a good reason for other users to have admin permissions in GitLab this will be looked on favourably.
Once the new user has been created, add them as a maintainer of the Agile Collective group. This will give the user access to all projects except for personal ones.
Freelancer and 3rd party users
Freelancer and 3rd party users should be created as external users. This ensures they only see the groups and projects they've been explicitly granted permissions on and means they can't create new projects.
When creating an account set the name and username to something identifiable so others can check who the user is. If necessary add an admin note.
Ideally, 3rd party users will only be granted developer permissions on individual projects, but sometimes it might make sense to grant permissions on a group or make them maintainers of a project.
Last updated: