Skip to content

D
doc

faq

Last edited by POLI Christian
Page history

Table of Contents generated with DocToc

FAQ - Frequently Asked Questions

How to not have to type a password for every git operation

First of all to avoid having to type login/password each type, the best is to use git over ssh rather than git over https (see below for git over http)

On your local computer:

  • git relies on ssh for the connexion to the gitlab's git server

  • ssh uses your ssh private key to authenticate to the gitlab's git server

  • your ssh private key is stored in your home, on your local computer's hard disk. This ssh private needs to be crypted, so that if your local computer is breached or stollen, the key cannot be used. This is the reason why it is crypted with a so-called "passphrase". This passphrase is actually a password, but you are encouraged to use something longer and more complex than a password (beacuse if this passphrase is "cracked", it can lead to a breach on many servers, so from the security point of view, it is critical)

Up to now, everything works correctly, but you have to type your ssh passphrase each time you connect by ssh, thus at each git operation involving the remote git server (push, pulls, ...)

The ssh-agent's role is to avoid that: it is a software running in background on your local computer. Each time your local ssh client needs to connect to a server, if it detects a running ssh-agent, it first tries to get the decrypted ssh private key from it. The first time, the ssh-agent asks for the passphrase to decrypt the key, then keeps the decrypted key in memory as long as you don't log out of your local computer.

This is the ssh-agent that allows not having to enter the passphrase at each ssh connection.

By default ssh client is installed with a command line ssh-agent, but modern operating systems / graphical environments come with integrated "keyrings" which can act as ssh-agents (and can as well manage other kind of secrets, such as passwords, gpg keys, etc.):

  • for OS X: Keychain

  • for linux / gnome: gnome-keyring

  • for linux / kde: kde-wallet

  • for other linux desktop environments, or for windows: ?

These "keyrings" work as follows: When you login on your local computer, your login password is automatically used to unlock the secrets stored in the keyring, of which the ssh keys are part.

Thus to be able to perform connected git operations (push, pull, ...) without having to type any password you need:

  • to use git over ssh

  • to have a ssh keypair protected by a passphrase

  • to use a command line or graphical ssh-agent

Note: it is also possible to do passwordless operations with git over http by using a personal access token:

  • create a personal access token in your gitlab user settings, with permissions "read_repository" (only these permissions).

  • when cloning the repository, use customize the URL as follows: https://:@gitlab.inria.fr/<end_of_url>

How to convert a user account from internal to external

When a user is leaving Inria, the gitlab account cannot be used anymore. Two situations can occur:

The user is still at Inria

Before leaving Inria:

  • open a ticket requesting to convert the account, providing the external email that will be used as identifier and for password recovery.
  • the user ask for password recovery using the new identifier when the account has been converted and provide a new password.

The user has already left Inria

  • Only an Inria administrator of a project the user was contributing to can ask for the account conversion.
  • The administrator open a ticket requesting to convert the account, providing the external email that will be used as identifier and for password recovery.
  • the user ask for password recovery using the new identifier when the account has been converted and provide a new password.

How to activate a commit email hook

Gitlab's model is that instead of setting up a centralized commit email hook per project, it is rather up to the users to choose his/her notification level per project. All users can set their 'global' notification level setting in their account settings. Then they can override this default global notification level per project on top of the project details page, with the little bell (This way, a project cannot impose a notification level to its members).

If you still want something similar to the old commit email hooks, then in your project configuration, section "Integrations/Project services", activate the "Emails on push" service. Then, unfortunately, you need to enter the explicit list of recipients. We haven't found a way to configure this such that the list of project members is automatically used as the recipients list

How to rewrite history

As documented in https://gitlab.inria.fr/help/user/permissions project members with roles Developer or Master or Owner are allowed to force push to non protected branches. If you want to rewrite history of a protected branch, You need first to switch the branch to non-protected (only Master or Owner can do that), do the force-push, then revert the branch to protected.

How to add users of an INRIA ildap group (eg. team members) to a gitlab group

Open a ticket, specifying the INRIA ildap group name, the gitlab group name, and the access level (GUEST, REPORTER, DEVELOPER, MASTER, OWNER) that you wish to give to added members. We will run a script which adds existing gitlab users matching the ildap group members to the gitlab group. Be aware that inria members need to connect at least one time to gitlab for their account to be created.

Provided you are in the INRIA network and have access to ldap://ildap.inria.fr, you can search for a groupname with a command such as:

$ ldapsearch -x -H "ldap://ildap.inria.fr" -b "ou=groups,dc=inria,dc=fr" | grep -i <team name>

For verification purposes you can check the list of ildap group members with a command such as:

$ ldapsearch -x -H "ldap://ildap.inria.fr" -b "ou=People,dc=inria,dc=fr" "(inriaGroupMemberOf=cn=<ldap group name>,ou=groups,dc=inria,dc=fr)"

How to use the continuous integration (CI) service?

Besides using Inria's Continuous Integration platform ci.inria.fr, you can use gitlab's integrated CI pipelines. This tool is more suited to the execution of simple and lightweight tasks, than for complex deployment pipelines.

You will need to set up a CI runner (small tool in charge of running the CI tasks themselves) and then register the runner with your project.

Enabling CI on a gitlab project

  • Go to your project's settings
  • In the General Permissions tab, search for "Pipelines", and check the permission is not "Disabled"
  • Then a CI / CD tab should now appears in the settings
  • In this CI / CD tab, you will find the url and the registration token you will need later, when adding a specific runner.

Installing runners

To perform the actual build, you need to install GitLab Runner. Runners can run anywhere : you can use a virtual machine on ci.inria.fr to host your GitLab runner.

See :

Installation example on a GNU/linux slave from ci.inria.fr ("ci" user account)

sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
sudo gitlab-runner install --user=ci --working-directory=/builds
sudo gitlab-runner start
sudo gitlab-runner status # should return "service is running"

Installation example on a macOS slave from ci.inria.fr ("ci" user account)

sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
gitlab-runner install --working-directory /builds
gitlab-runner start
gitlab-runner status # should return "service is running"

Installation example on a Windows slave from ci.inria.fr ("ci" user account)

# Follow https://docs.gitlab.com/runner/install/windows.html then when installing the service prefer the following to use the existing "ci" user account
gitlab-runner install -u ".\ci" -p "ci" -d "C:\Users\ci"
gitlab-runner start
gitlab-runner status # should return "service is running"

Register a runner in your project

On the virtual machine where you installed the gitlab CI runner, run (as root or sudo if the gitlab-runner program has been installed with sudo, remove sudo from the following if not) :

$ sudo gitlab-runner register

Use the gitlab URL and the registration token found in the "Pipelines" page when asked.

In order to answer when asked

Please enter the gitlab-ci tags for this runner (comma separated):

it is important to know that "gitlab-ci tags" are NOT git tags. The tags you enter here are useful to specify conditional execution in the configuration file .gitlab-ci.yml.
See :

for more details.

The next question

Whether to run untagged builds [true/false]:

becomes clear when the "gitlab-ci tag" concept is understood.

When asked

Please enter the executor:

you should answer shell (or docker but then see the related subsection below)

At the end of this step, your runner should appear in the Settings > Pipelines tab of your project.

Use existing runners

If you don't want to manage runners yourself you can use some existing ones provided by ci.inria.fr where jobs can be executed in docker containers. Please contact the support team for more information.

Configurating CI tasks

Finally, configure the tasks to run by creating a .gitlab-ci.yml file at the root of your project.
Follow the official documentation at https://docs.gitlab.com/ce/ci/yaml/ to create this file.

Using a docker executor

It has been reported that there are DNS issues with docker running on the INRIA CI's VMs (due to bad interaction between dnsmasq and docker, see https://stackoverflow.com/questions/49998099/dns-not-working-within-docker-containers-when-host-uses-dnsmasq-and-googles-dns). This can be solved by adding network_mode = "host" in the configuration. Eg. /etc/gitlab-runner/config.toml:

concurrent = 1
check_interval = 0

[[runners]]
name = "ci.inria"
url = " [ https://gitlab.inria.fr/ | https://gitlab.inria.fr/ ] "
token = "..."
executor = "docker"
[runners.docker]
network_mode = "host"
tls_verify = false
image = "alpine:latest"
privileged = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
[runners.cache]

Git-LFS is not activated

The git-lfs feature is not activated. To version data or binary files, an option is to use git-annex on Inria Forge. Please have a look at the following links:

Why isn't git-LFS activated? We observe that many users are trying to use git/gitlab to store huge volumes of data such as experimental datasets, experimental results, binary blobs, big data, etc. Git is not designed to handle such usage, and git-lfs would be the good answer, but because we do not have yet a working, production ready, quota system for gitlab, and because we do not yet have a clear strategy about how to manage such storage, we do not want to encourage such usages, and thus we decided to not enable git-lfs.

Merge Request development model and external contributors

This Inria Gitlab instance offers accounts both to Inria members (who login using their Inria LDAP credentials) and to external users (who can register accounts at this location: https://gitlab-account.inria.fr/). The external (non-inria) users are limited to join existing projects, but cannot create projects on their own.

This limitation for external users has an important result: from the Gitlab point of view, forking a project is creating a project, thus external users cannot fork projects.

As a result, the well-known MR (Merge Request) development model cannot be used directly with external users, but some workarounds can be used in some situations.

The MR development model works as follows:

  • A restricted core development team is member of a project and has commit access to the development tree
  • Some contributor starts contributing by forking the project ("fork" button). When their contribution is ready, they open a new merge request (in the "new" menu).
  • Someone from the core development team can then accept (or refuse) the Merge Request to be merged into the main development tree

This development model has several benefits:

  • It limits the access to the main development tree to a small group of trusted core developers.
  • It allows the core development team to control finely which contributions to merge or not.
  • In particular, it shields the project and forces all contributions to pass through a validation workflow, such as ensuring that the Continuous Integration passes, or that all intellectual property constraints are satisfied, before merging some development.
  • With tools such as Github or Gitlab, the web user interface for merge requests is very user friendly.

So, here are some possible workarounds to this development model when using the Inria Gitlab with external contributors:

  • Use pull-requests mechanisms at the git level, rather than at the Gitlab level. This is the way that the Linux kernel has been developed for a long time now. Instead of submitting a MR with the Gitlab interface, contributors send patches by email.
  • For projects with few known external contributors, it is possible for Inria members to create forks on behalf of the external contributors, then transfer ownership of these forks to the contributors. Here is a possible worklow:
  • create a new group to handle the forks of your external collaborators
  • take care to remain the only owner/master of the group in order to control the creation/destruction of forks
  • create a fork from the original project with as destination the newly created group. By default the name of the project will be the same as the original project, e.g. https://gitlab.inria.fr/ForksOfFoo/bar
  • then rename this forked project through Settings -> General -> Advanced Settings, e.g. https://gitlab.inria.fr/ForksOfFoo/bar-jdoe
  • finally add your collaborator master on that fork
  • For projects with few known and trusted external contributors, these contributors can be added to the project but develop in their own branches. There are some basic mechanisms in Gitlab to ensure they don't override their permissions: if these users have role developer, they won't be allowed to push to protected branches (master, by default). Details on Gitlab permissions can be found here: https://gitlab.inria.fr/help/user/permissions.md.

If these workarounds do not fit well with what you need and you absolutely want to use the standard MR development model with external contributors, the only solution is to use another tool than the Inria Gitlab.