Gitlab Master FAQ: Difference between revisions

From pCT
m (→‎Stop docker container: docker container needs to be stopped before it can be removed)
 
Line 50: Line 50:


==== Stop docker container ====
==== Stop docker container ====
Stop, note that container will not be deleted
Stop, note that container will not be deleted, but it disappears from the list of active containers, use <code>--all</code> to list all containers
  docker container stop gitlab-runner-projectname
  docker container stop gitlab-runner-projectname


If it should be removed, this needs to be explicitly done (also in one go without stop)
Once the container is stopped, it can also be removed:
  docker container rm gitlab-runner-projectname
  docker container rm gitlab-runner-projectname


Can also be restarted
or, it can be restarted again:
  docker container stop gitlab-runner-projectname
  docker container stop gitlab-runner-projectname



Latest revision as of 10:18, 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

  1. Create a R/W repository access token in the target repository
  2. 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
  3. 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).
  4. 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, but it disappears from the list of active containers, use --all to list all containers

docker container stop gitlab-runner-projectname

Once the container is stopped, it can also be removed:

docker container rm gitlab-runner-projectname

or, it can be restarted again:

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.

  1. Create new repository in the pCT group or ask for creation, lets call it newPackage
  2. Fork the repository to your user space
  3. Clone the package you want to import
     git clone <some_external_link> newPackage # we give it the new name
     cd newPackage
  4. Redirect upstream URL to the fork in your gitlab user space
     git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git
  5. Now make a forced push (option -f) to import the repository to your fork
     git push -f origin
  6. Create merge request to branch import (if not existing, master or any other appropriate branch) by following the instructions Pull/Merge request