GitLab user account

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.

Automatic provisioning

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 (SSO) 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.

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.

Manual registration

As a last resort solution, users may go through a manual account request, using the manual account request link, 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.

Attention

  • Account requests not validated within a month will be automatically deleted,

  • account requests associated to non-institutional emails (such as Yahoo, Gmail or others) will not be accepted.

New users may have a different status depending on whether their account was created via SSO (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

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.

Troubleshooting

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.

Account and projects management

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.

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.

Invited users should prefer SSO when registering, to avoid going through manual registration.

Account “end of life”

Deactivation

After 90 days of inactivity, an account is deactivated. It will not be deleted: to reactivate it, simply log in again.

Block

A user account may be blocked only by a service administrator: please contact us through our user support.

Blocking a user has the following effects:

  • User will not be able to login

  • User will not be able to access git repositories

  • Personal projects will be left

  • Owned groups will be left

An account may always be unblocked, their data will remain intact.

Delete

A user account may be deleted

Deleting an account is a permanent action. Issues, merge requests, and groups linked to them will be transferred to a system-wide Ghost-user.

Important

We suggest to:

  • delete a user when all the activity of the user account concerns the collaboration that has ended,

  • block a user when it is needed to limit quickly the account access, but avoid data loss.