Gitlab Master FAQ: Difference between revisions

Revision as of 10:15, 10 March 2021

Main Page -> Documentation -> Gitlab Master FAQ

This is a collection of frequently asked Gitlab questions for project maintainers

Please edit this page and add your question, or send email to pCT@uib.no

Mirror a repository

GitLab supports mirroring of a repository, the GitLab version provided by UiB supports mirroring by push. That means, repository content is pushed to another repository.

The set this up

Create a R/W repository access token in the target repository
In the source repository choose Settings -> Repository and expand Mirroring repositories
Git repository URL: https://oauth2@git.app.uib.no/group/project

Mirror direction: Push (this is fixed in the current version of GitLab)

Authentication method: Password (this is fixed in the current version of GitLab)

Password: the access token
Choose options, whether to prohibit diverging refs, and which branches to mirror. In most cases the mirroring should not be done for all branches but only the protected ones (which represent the stable development).
Click Mirror repository

GitLab takes care of automatically pushing changes to mirror repository. Alternatively, update can be triggered from the Web interface

Example link

   https://oauth2@git.app.uib.no/pct/development/pct-online

Setup GitLab CI

Configuring CI

Add specific runner

The CI is executed by a so-called runner, usually a GitLab service also provides a few shared runners. As they might be limited in capacity and availability, specific runners can be set up. Specific runners make use of resources you can control.

If you have access to a resources providing docker, the runner can be set up with a few lines.

External links in the GitLab documentation

Launch docker container

Create the docker volume for the configuration of the runner, this volume is mounted in the container executing the runner

docker volume create gitlab-runner-config-projectname

Start the runner in a container

docker run -d --restart always -v /var/run/docker.sock:/var/run/docker.sock -v gitlab-runner-config-projectname:/etc/gitlab-runner --name gitlab-runner-projectname gitlab/gitlab-runner:latest

Register

Launch a container with command register, the container comes with a pseudo tty connected stdin (options -it) and is deleted when done (option--rm)

docker run --rm -it -v gitlab-runner-config-projectname:/etc/gitlab-runner gitlab/gitlab-runner:latest register

Follow the instructions and enter URL of GitLab service and registration token, name of the instance and a few other options.

Stop docker container

Stop, note that container will not be deleted

docker container stop gitlab-runner-projectname

If it should be removed, this needs to be explicitly done (also in one go without stop)

docker container rm gitlab-runner-projectname

Can also be restarted

docker container stop gitlab-runner-projectname

Limit number of cores used by the runner

Use option --cpuset-cpus to assign dedicated CPUs to the container. There is also an option --cpus to specify a fraction of cores to be used, but this will not effect the nproc command in the container.

To utilize all but 2 cores of the host system, e.g. start with the calculated value:

 cpus=`nproc`; docker run --cpuset-cpus="0-$((cpus - 3))" ...

In the container, the nproc command can be used to retrieve the number number of cores, e.g. to pass it to the build system.

Importing an external package

The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package.

Here is a proposed workflow for importing a package which is already hosted in git.

Create new repository in the pCT group or ask for creation, lets call it newPackage
Fork the repository to your user space

Clone the package you want to import

 git clone <some_external_link> newPackage # we give it the new name

 cd newPackage

Redirect upstream URL to the fork in your gitlab user space

 git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git

Now make a forced push (option -f) to import the repository to your fork
```
 git push -f origin
```
Create merge request to branch import (if not existing, master or any other appropriate branch) by following the instructions Pull/Merge request

@@ Line 58: / Line 58: @@
 Can also be restarted
   docker container stop gitlab-runner-projectname
+==== Limit number of cores used by the runner ====
+Use option <code>--cpuset-cpus</code> to assign dedicated CPUs to the container. There is also an option <code>--cpus</code> to specify a fraction of cores to be used, but this will not effect the <code>nproc</code> command in the container.
+To utilize all but 2 cores of the host system, e.g. start with the calculated value:
+  cpus=`nproc`; docker run --cpuset-cpus="0-$((cpus - 3))" ...
+In the container, the <code>nproc</code> command can be used to retrieve the number number of cores, e.g. to pass it to the build system.
 === Importing an external package ===