Gitlab is a collaborative code management and software development project service based on the Git system. Our instance is provided to IN2P3 members, to academic users members of the federation eduGAIN and their collaborators, for a professional use only. The Gitlab platform is deployed in its Core version.
In case of problem, please contact our user support.
Quality of service¶
We provide this service on a best effort basis.
There are 3 levels of visibility for a project (and the code that it contains):
- Private: the project is visible and accessible only by its members and explicitly authorized groups, as well as groups from which the project originates;
- Internal: the project is visible and may be cloned by any logged user;
- Public: the project can be cloned without any authentication. It will also be listed on the public access directory (
By default, every new project is private but can inherit its parent groups visibility.
It is possible to give access to your projects to other Gitlab platform users, through the “Members” menu. If the account already exists, the new “member” may be added directly with the desired access rights level. If the user does not have an account yet, he will need to create one.
An invitation may also be sent directly by email. Please select, when possible, institutional addresses and use personal addresses (such as Yahoo, Gmail or other) only as a last resort. The reasons for this are explained in the next paragraph.
How to Sign-up¶
- academic users MUST register using eduGAIN federation, by clicking on
- other users may register by clicking
A good number of institutional domains are listed in the federation: please check the presence of your institutional tutelage on the eduGAIN technical page
Connecting with EduGAIN allows an automatic validation of your account the first time you connect to the service. EduGAIN can also be used for connecting to others services provided by the CC-IN2P3 such as ATRIUM or Box.
The accounts that are not created through the eduGAIN mechanism will be initially blocked, pending the manual validation process operated by the Gitlab platform administrators.
A “responsible” (the project maintainer or the user’s supervisor) must confirm the validation request to user support, specifying the username or e-mail associated with the account.
- If the pending account e-mail is institutional, the administrators will be able to give access to all the service functionalities.
- If the pending account email is not institutional, he will be able to collaborate on other projects, but he will not be able to create personal projects (status external).
The recommended way to interact with a git repository (project) is to use SSH. You can follow this documentation to help configure your SSH key.
When an account is created using the standard
[Sign-up] method, the user won’t be able to use Shibboleth authentication.
To be able to do so, you should configure it in your profile:
Profile Settings > Account > Social sign-in
The goal is to use the Single Sign On method proposed by the Identity federations.
When registering with Shibboleth, GitLab builds the username field using the first part of the e-mail address up to the
This may create duplicates with already registered usernames from the user organizations. To avoid it you have to:
- register using the
[Sign-up]option and choosing a different username;
- enable Shibboleth for that account.
The continuous integration platform is based on GitLab. You must configure your GitLab project to use a Runner; thus each commit or push triggers the execution of continuous integration pipelines.
Information concerning continuous integration (pipelines, jobs, environments, etc.) is displayed in the “CI/CD” menu of the GitLab vertical menu. For any issue you may contact our user support.
Uploading large files¶
GitLab is not made to store large binary files. To manage files, such as audio, video, graphics files or virtual machines images, GitLab supports “git lfs”.