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:
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 GeneralPermissions 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.
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.
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-amd64sudo chmod +x /usr/local/bin/gitlab-runnersudo gitlab-runner install --user=ci --working-directory=/buildssudo gitlab-runner startsudo 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-amd64sudo chmod +x /usr/local/bin/gitlab-runnergitlab-runner install --working-directory /Users/cigitlab-runner startgitlab-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 accountgitlab-runner install -u ".\ci" -p "ci" -d "C:\Users\ci"gitlab-runner startgitlab-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!) :
$ 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.
becomes clear when the "gitlab-ci tag" concept is understood.
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.
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.