• General
• Software Source
• Configuration
• Users, Projects, Groups and Roles
• Known Issues
• GitLab Runner
• Harbor Integration

General

DevOps-as-a-Service provides GitLab as an optional part of the toolchain. It covers the following built-in DevOps features according to the Service Description:

• Source Code Management
• Continuous Integration / Delivery

Because the built-in registry feature is not enabled at the moment, GitLab doesn't cover the functions Artifact Repository / Docker Registry. For this, Harbor has to be used.

GitLab contains lightweight Issue tracking and Wiki functions. Because these functions are not an appropriate replacement for full-featured issue tracking and wiki systems like Jira, YouTrack, Confluence or XWiki, they are deactivated by default.

The following information only includes relevant information regarding provisioning the service within DevOps-as-a-Service. It's not a documentation how to use GitLab. For this, we recommend to study the comprehensive GitLab documentation at https://docs.gitlab.com/.

Software Source

GitLab is provided as Community Edition (CE) https://gitlab.com/gitlab-org/gitlab.

Thus only those GitLab features are provided which are bundled into the Community Edition. See also GitLab Feature Comparison and GitLab Features for a documentation and comparison of the different editions aka tiers. 

Configuration

The following relevant configuration aspects apply:

• Users with system administration permissions remain in the DevOps-as-a-Service team (like for the other tools). The Owner role within a group is the highest role a user of a customer can get, see also "Users, Projects, Groups and Roles"
• GitLab is integrated in the Single-Sign-On domain (SSO) of a specific DevOps-as-a-Service instance
• The management of users and groups is performed exclusively using the self-service portal of DevOps-as-a-Service
• The built-in registry feature is not enabled

Users, Projects, Groups and Roles

The management of users, groups and the assignment of users to groups in GitLab is performed exclusively using the self-service portal of DevOps-as-a-Service. 

• When a user is created in the self-service portal and assigned to GitLab, then this user is created in GitLab automatically. Corresponding actions occur when locking or deleting a user.
• When a new project is created in the self-service portal, then a so called "group" is created in GitLab automatically. Corresponding actions occur when renaming or deleting a project.
• When a user is assigned to a project in the self-service portal, then this user is assigned to a group in GitLab according to the following mapping:

Regarding Group Permissions in GitLab, see https://docs.gitlab.com/user/permissions/#group-members-permissions.

Subgroups are created by the users itself. The subgroups inherit the users and roles of the superordinate group.

The following configuration options are disabled. Use the self-service portal instead: 

• Creation of users
• Changing the user name
• Creation or deletion of groups
• User management for other users (name, deletion)

Known Issues

There are some known issues for using GitLab within DevOps-as-a-Service, especially in relation to the central user and project management in the self-service portal. These issues are not real errors, but rather provide assistance on how to avoid inconsistencies between GitLab and the central user management using the self-service portal.

GitLab Runner

GitLab Runners are not an integrated part of the GitLab offering. Runners can be provided by one of these options:

• Runners are provided by DevOps-as-a-Service as a contract option
• Customer provides and maintains its own runners

Harbor Integration

To configure the Harbor integration, follow these instructions.