Gitlab #

We are a group of software engineers with a shared need for hosting code for our small and mid-sized clients who do not have their own repositories. Since CGI did not offer a similar service to meet our needs, we decided to host our own self-managed GitLab instance.
Our user base and the number of projects are growing daily, and we are excited to have you as part of CGI GitLab Berlin. However, please keep in mind that this GitLab instance is an internal project without dedicated funding. As a result, it is supported on a best-effort basis, and only the features of the free version are available.
Thank you for joining! 💖

Tier #

Go to our Gitlab:

https://gitlab.cgi-berlin.cloud

For all detailed information visit the official Gitlab docs:

https://docs.gitlab.com/ee/README.html

Registration #

Due to the instance’s intended use by our CGI partner, we have disabled the registration functionality for our GitLab instance. To access the platform, kindly select the Sign in with CGI credential option during login. Your account will be automatically created and granted upon successful login.

Access tokens #

As we are using OTP, you cannot use your username/password to access repositories or anything else like pulling/pushing Docker images. For all operations you can set up access tokens with dedicated permissions. The access tokens are used as password from now on.

For access to Git repositories you can also upload an SSH key.

For more information visit:

https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

and

https://docs.gitlab.com/ee/ssh/README.html

Groups and projects #

You have full permissions to create groups and projects. Initially you can only discover public and internal projects. If you want to join a group or project, please ask the owner to invite you. You have to complete registration before someone can invite you.

In general groups are a way to build logical clusters of projects. For example, if you are developing a microservice application it makes sense to group the services into a Gitlab group. This has also the advantage that you can assign permissions to groups instead of projects. This makes it easy to add new project without handling permissions all over again. Groups can also contain subgroups if needed.

Projects are representing a Git repository. The can exist alone or under a group. Using a group is always recommended.

For more information about groups visit:

https://docs.gitlab.com/ee/user/group/

For more information about projects visit:

https://docs.gitlab.com/ee/user/project/

Permissions #

When giving permissions to someone please consider the principle of least privileges. For a full overview of permissions visit:

https://docs.gitlab.com/ee/user/permissions.html

CI / CD #

The CI/CD pipelines are integrated with autoscaling, meaning worker nodes are added and removed automatically.

Before starting with pipelines, please make yourself familiar with the docs to get an idea how this works. As worker resources are provisioned dynamically it’s crucial that you understand and use advances techniques like caching. Omitting caches entirely or just inefficiently will have a great impact on both, cloud cost and performance of your jobs.

Pipelines are defined by having .gitlab-ci.yml file in your project. The spec can be found here:

https://docs.gitlab.com/ee/ci/yaml/README.html

Please consider the docs about caching and implement it accordingly:

https://docs.gitlab.com/ee/ci/caching/

For more information visit:

https://docs.gitlab.com/ee/ci/README.html

Building Docker images with kaniko #

As building images using the legacy Docker in Docker approach is no longer supported, you can use kaniko for building an image with GitLab CI/CD.

Consider the following minimal example. We are building a Docker image and pushing it to the integrated container registry.

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.23.2-debug
    entrypoint: [""]
  script:
    - /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"

Note that we are using predefined environment variables. See: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

For more information visit:

https://docs.gitlab.com/ee/ci/docker/using_kaniko.html https://github.com/GoogleContainerTools/kaniko

Container registry #

Gitlab has an integrated container registry which is fully integrated into CI/CD. For more information visit:

https://docs.gitlab.com/ee/user/packages/container_registry/

Gitlab features #

Gitlab Pages #

Gitlab Pages is a feature that allows users to publish static websites from GitLab repositories, and learn about its benefits, use cases, and requirements.

For security reasons, we have made the decision to permanently deactivate this feature.

Integrations #

Jira #

Other notable features #

Issues #

https://docs.gitlab.com/ee/user/project/issues/

Wiki #

https://docs.gitlab.com/ee/user/project/wiki/

Snippets #

https://docs.gitlab.com/ee/user/snippets.html

Packages #

https://docs.gitlab.com/ee/user/packages/

Contacts #

• Contact email: gitlabberlin.de@cgi.com
• Contact persons