• 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 DevOps 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 DevOps Portal of DevOps-as-a-Service. 

• When a user is created in the DevOps 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 DevOps 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 DevOps 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 DevOps 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 DevOps 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 DevOps 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.