GitLab

Service description

GitLab is a collaborative code management and software development project service based on the Git system. The CC-IN2P3 instance is provided to IN2P3 members, to academic users whose organization is part of the eduGAIN federation and their collaborators, for a professional use only. The GitLab platform is self-hosted (ie. no third party cloud services are is use) deployed in its Community version. By default, every new user-created project is private but can inherit its parent groups visibility. Project access and visibility follow the rules defined in the GitLab official documentation.

In case of problem, please contact our user support.

Compliance with the terms of use

We may disable or remove accounts or projects that do not comply with the terms of use, in particular with respect to intellectual property rights.

For any information on features, upgrades or service support, please refer to the gitlab-maintenance project. This is not a ticketing system: for any request, continue to contact our user support.

Account registration

The CC-IN2P3 GitLab instance is accessible at https://gitlab.in2p3.fr. When not logged in, users will be presented with the GitLab sign up page where all instructions regarding account registration and user log in methods are presented.

New academic users MUST register for a GitLab account by clicking on the CC-IN2P3 Single Sign On button, using either their CC-IN2P3 account or any account from the eduGAIN federation. Using the single sign on mechanism ensures that your account request is processed automatically and access to the GitLab platform granted without further delay or action. Please refer to the identity federation paragraph for all information on this method of authentication.

Attention

Please refrain from using multiple eduGAIN accounts to register because you would then end up with multiple GitLab accounts that cannot be merged. If you need to switch your GitLab account to another eduGAIN identity, please contact our user support.

As a last resort solution, users may go through a manual account request, using the manual account request link, that is present in the third item of the dropdown menu, from the sign up page.

Accounts that are requested manually will be initially blocked, pending for the manual validation by GitLab platform administrators. When a user finds his registration pending validation, a “responsible” (eg. the project maintainer or the user’s supervisor) must confirm the legitimacy of account request to user support, specifying the username or e-mail associated with the account.

Account requests not validated within a month will be automatically cleared out.

Important

It is possible that an account created via eduGAIN is not operational: the account exists, but is “temporary”, with a hash as username. If you find yourself in this situation, contact user support; changing the name, email etc., in the hope of using it won’t work: it will never be possible to reconnect once the session has expired.

By default new users will have a different status depending on whether their account was created via Single Sign On (external = false) or not (external = true).

  • external = false: no usage restriction is applied.

  • external = true: the creation of new projects or groups of projects is restricted to the namespaces of which they are members, to the exclusion of their personal namespace. Failure of such an attempt will be characterized by the following, somewhat cryptic, GitLab message:

404: Namespace not valid

Note

In general, and to ease project ownership management, we strongly suggest the use the personal namespace only if absolutely necessary. The “external” restriction may be removed upon request to our user support.

Invite collaborators

It is possible to give access to your projects to other GitLab platform users, through the Project Information > 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 a GitLab account yet, an email invitation will be sent to the provided address in order to create one. Please use, whenever possible, institutional email addresses and use personal addresses (such as Yahoo, Gmail or others) only as a last resort. Invited users should also prefer using Single Sign On when registering.

SSH configuration

The recommended way to interact with a git repository (project) is to use SSH. You may follow this help configure your SSH key.

Enable SSO authentication

When an account is created using the manual registration form, the user will not be able to use the SSO authentication. To be able to do so, you should configure it in your profile:

Preferences > Account > Service sign-in

Account duplicates

When registering with SSO, GitLab builds the username field using the first part of the e-mail address up to the @ character. This may create duplicates with already registered usernames from the user organizations. To avoid it you have to:

  • register using the Username/Password form and choosing a different username,

  • enable SSO for that account.

Handling large files

Git is not very efficient at managing large binary files (> few MBs) which have the additional drawback of not being “differentiable”. To manage such files, such as audio, video, graphics files or virtual machines images, GitLab supports “git lfs”.

Continuous Integration/Deployment

GitLab provides a continuous integration and deployment toolchain called GitLab CI. Information concerning continuous integration (pipelines, jobs, environments, etc.) is displayed in the “CI/CD” menu of the GitLab vertical menu.

The IN2P3 Gitlab instance provides its users with a set of Gitlab runners in order for them to run their CI/CD jobs. However, these “public” are shared among several thousand Gitlab users and their ressources are strictly limited. Moreover, the confidentiality of the code and data processed by these CI jobs is not assured since the underlying ressources are inherently shared among CI users. Lastly, each job resources are constricted to some extent, ensuring faire resource usage and limiting abuses.

Note

Each job can use up to 4 vCPU and 2GB of memory.

These runners are made available for free to all the users of the IN2P3 Gitlab instance, to be used for learning purposes and grap the basics of Gitlab CI. Of course, any use case dealing with extensive software integration or production workloads, that require specific runner configuration or higher resources should always imply the setup of a dedicated Gitlab CI infrastructure.

You can easily deploy and use your own Gitlab CI infrastructure for your projects. More information is available on the Gitlab documentation. In the event when you do not have access to the necessary computing ressources to set up such an infrastructure, and your project is part of a collaboration or laboratory supported by IN2P3, you may request resources on the CC-IN2P3 infrastructure. You would then be able to deploy, configure and maintain your own CI infrastructure as you see fit, for your projects.

For any issue you may contact our user support.

GitLab static web pages

The CC-IN2P3 GitLab instance provides static web pages, the so-called “GitLab Pages”. Such a page will have the following URL:

https://<user.id>.pages.in2p3.fr/<project-name>/

Advanced pages features

The following features are supported:

  • Custom domains: it requires the purchase of a DNS name and proper configuration on your part.

  • HTTPS certificates: static or automatic with Letsencrypt.

  • Access control: may limit access to only authenticated members of your project (at least Guest).

Additional advanced features may require interaction with our user support.

Attention

GitLab Pages is intended to host static, small and simple web pages. The main usecase is documentation (the Wiki may also be used in that fashion). Any other usecase would probably be best served through more classical webhosting. In that case and if you’re a IN2P3 user or member of a IN2P3 collaboration don’t hesitate to ask our user support.