The goal of this documentation is to describe the specific features of the Inria's GitLab instance. For general GitLab documentation (projects or groups administration, user account settings, permissions, available tools and workflows), look at the online documentation on our server or on gitlab server. These are links to the documentation of GitLab's Community Edition, which is the version which is installed at Inria.
All users with an Inria ldap account have immediate access to this GitLab with their Inria account, by login in the iLDAP login tab. They have standard GitLab permissions: create projects, groups, and administer them.
All users without an Inria account can create an account. They will receive a confirmation mail, and after their account is confirmed, they get an external account. Then they can login in the Standard login tab. They won't be able to create projects nor groups, but can be invited by Inria members to participate in project(s).
This logic is similar to the InriaForge'logic regarding permissions of Inria members versus external users, the difference being that the InriaForge accounts database is separated from the Inria ldap accounts database, whereas GitLab supports dual authentication (ldap or external).
Note that for Inria members, the corresponding GitLab account is activated upon the first connection. So, to activate your accounts and allow projects or group administrators to add you to projects or groups, you need to login to the GitLab at least once.
Currently the maximum number of projects a user can create is 50.
Before submitting any ticket to the support, check that your question is not already answered in our FAQ or in this documentation.
Then, you can submit a support ticket at the inria helpdesk portal (inria account is mandatory). On this portal, select "IT support request", then "ask for a fix" or "service request", and then select "services for research", then "GitLab". You can also submit a support ticket by mail at address sed-gitlab.helpdesk-prc at inria.fr (this is the way to go if you don't have an inria account).
When submitting your request, don't forget to provide accurate details of what's going wrong. Read, for example, How to Report Bugs Effectively.
Migrating a project from another GitLab instance.
To do that, you have to export your project from the other GitLab instance and import it to this instance. But You need to check that the import/export format are compatible. In case of import/export formats mismatch, we cannot give any guarantee of what will be imported or if it will work at all, though there are some reports of people successfully importing a project exported in format 0.1.4 to a GitLab instance expecting format 0.1.5.
Important notice: before doing the import, make sure that all the user accounts referenced from the project in the previous GitLab instance are re-created identically in this GitLab instance before importing the project. This is not mandatory for the git history data, where the commiter is just a string, but it is mandatory for all GitLab specific tools such as issues, comments, etc. Some of the records for which no corresponding user account are found during import will be attributed the the account which performed the import instead, and some of these records will simply disappear (eg. issues raised or belonging to an nonexistent account simply disappear). Do not forget that for Inria members, for their accounts to be activated in GitLab, they need to login at least once to GitLab.
users can create up to 50 projects
project size are limited to 2GB
GitLab's integrated continuous integration is enabled by default on all projects, but we do not currently provide support for this. More specifically we do not yet provide support for interfacing GitLab with Inria's continuous integration platform.