GitLab#
Getting Help and Administrators#
If you need help with the GitLab, you can ask
via email to the Administrators.
Namespaces#
Each user has a personal namespace in the CTAO gitlab. Additionally, there are groups which also may contain subgroups.
Contrary to how you might intuitively think about groups in an organization, GitLab subgroups always contain all members of their parent groups, you might only add additional people compared to the parent group or raise the permission level of users compared to the default permissions.
Organizing Projects#
CI/CD Systems#
To build, test and run code, CTAO has access to two CI systems: GitLab CI/CD and Jenkins.
GitLab CI/CD#
GitLab CI/CD is directly integrated with GitLab, however to actually run CI/CD jobs, a project needs access to CI runners.
DESY provides a CI runner based on the Kubernetes executor, meaning it executes CI jobs on Linux in Docker containers. This runner is available to all projects and is chosen by default if no further settings are made. For security reasons, CI jobs using this runner cannot run arbitrary docker commands. Docker images can be build and uploaded into a registry using Kaniko. Example configuration can be found in the python-template-repository.
By default, CI pipelines run on push events to the repository. Merge request builds are not enabled by default. Since merge request builds are special in the sense that they don’t simply test the local code in the branch but the result of the merge, it is recommended to enable them.
Just enabling Merge Request builds however would result in duplicated work, since under normal circumstances the merge request build is very similar to the push event build for the same branch.
It is thus recommended to build on pushes to the main branch, merge request builds and tag creation. A configuration example for this can be found in both the cpp-template-repository and the python-template-repository.
The CI/CD of projects should:
Perform static checks of the code, including for the coding style
Build the project, including documentation
Run the unit tests
Upload coverage report and trigger the analysis of the quality gate (Sonarqube) server.
Building docker containers
Additional steps, e.g. for release builds could be:
Publish the documentation to gitlab pages
Publishing build artifacts, e.g. uploading python packages to PyPI and tagged containers to a registry.
Refer to the template repositories for example configurations.