GitLab FI

Terms of use

• It is forbidden to changethe group path.
• Repositories are not intended for uploading very large files.
• There is a strict limit of 3 GiB on the size of a single repository; once the total size exceeds 2 GiB, an email notification will be sent automatically.
  The size of individual repositories can be reduced via Project → Settings → Housekeeping.
• There is a global limit of 100 repositories per user. This limit can be increased on request.
• Please ensure you comply with the operating rules.

If you have an active account at the Faculty of Informatics, you can log in using LDAP authentication at the following URL:

https://gitlab.fi.muni.cz/

Enter your faculty username and password; your account will be created automatically after you log in for the first time.

External accounts

GitLab allows you to create a type of account that cannot own or create projects. They can only contribute to projects to which they are explicitly granted access. These accounts are referred to as external accounts. They can be used to grant access to projects for researchers and colleagues from other institutions, examiners or consultants for final theses, etc.

Account validity

A GitLab account linked to a faculty account is only valid if the faculty account is active and not blocked. If the faculty account is blocked or deactivated, access to GitLab, including SSH keys, will also be blocked.

SSH key

If you wish to work with a repository from your computer without having to enter your password every time, you can upload a public SSH key to your profile. Please follow the instructions; here we will only provide tips, particularly for Linux systems.

Creating an SSH key

ssh-keygen may ask you to enter a password whilst generating the key. This is not mandatory – using a key without a password is simpler – but a key with a password is more secure.

Using a key without a password

You can test whether the key is working by using the command

ssh -i $cesta_k_PRIVATNIMU_klici git@gitlab.fi.muni.cz

The output of the command should be similar to the following:

Welcome to GitLab, (Jmeno, Prijmeni)
Connection to gitlab.fi.muni.cz closed.

Add the following lines to~/.ssh/config (the file may not exist yet):

Host gitlab gitlab.fi.muni.cz
    HostName gitlab.fi.muni.cz
    IdentityFile cesta_k_PRIVATNIMU_klici

For an explanation of each line, see ssh_config(5). Check that the command `ssh git@gitlab ` produces the same output as above even without explicitly specifying the key.

Using a key with a password

If you use this type of key as if it had no password, every operation with GitLab will require the key’s password, which offers almost no advantages over a standard login. With the help of an SSH agent, the key can be unlocked just once and then used repeatedly:

ssh-agent $SHELL
ssh-add ~/.ssh/id_gitlab

The first command starts the agent, which then launches a new shell using the `$SHELL` variable. If your shell does not set this variable, enter the path to the programme instead (e.g. `/bin/sh`). Exiting the shell will also terminate the agent. For more information on the commands, see the man pages for ssh-agent(1) and ssh-add(1).

Please note that in older versions of this documentation and on various discussion forums, you may find a procedure that uses the command `eval $(ssh-agent -c) ` or something similar. We do not recommend using this procedure, as it does not guarantee that the agent will terminate correctly.

Kerberos

GitLab allows you to log in to the interface and clone repositories using Kerberos tickets.

Use on Nymfe workstations

After logging into the graphical environment on the computers nymfe* , the user automatically receives a Kerberos ticket, which can be verified using the commandklist:

login@nymfe01:~$ klist
Ticket cache: FILE:/tmp/krb5cc_15291
Default principal: login@FI.MUNI.CZ

Valid starting       Expires              Service principal
12/17/2019 16:16:56  12/18/2019 16:16:51  krbtgt/FI.MUNI.CZ@FI.MUNI.CZ

Use from the Aisa, Anxur, Aura or Arachne servers

This login mechanism can generally also be used from other UNIX machines on which Kerberos is configured for theFI.MUNI.CZ domain.

Configuring your own computer

This option is only available for machines on the FI network. See also Restrictions on access to the FI network.

Documentation on GitLab’s features can be found on the help page. In particular, we recommend

• the basics of using GitLab (creating a project, examples)
• project access control
• repository migration
• git

Sharing a repository

If you wish to make a repository accessible to other people beyond the project’s ‘visibility’ settings (Private, Internal or Public), you can add them asmembers of the project; see adding members.

If you wish to grant access to a private or internal project to someone without a faculty account, and that person only needs access to download the project (i.e. they do not need access to Issues, the wiki, etc.), you can use Deploy keys (essentially read-only access to the project via an SSH key). If access to other services or the ability to contribute to the project is required, the project must be made public or an external account must be created for that person (please contact the administrators).

Email replies

The Faculty GitLab has the ‘Reply by Email’ feature enabled, which allows you to reply to comments, ‘issues’ and ‘milestones’ directly via email. However, for this to work correctly, it is important to follow a few rules:

• reply directly to the email you have received using the ‘Reply ’ function; do not write a new email
• write your reply only above the quoted text, or preferably delete the quote altogether, as GitLab may not remove it correctly
• if you digitally sign your emails, it is best not to include your signature when replying to GitLab

You can use Markdown in your email and add attachments; these will then appear as attachments in your reply on GitLab.

Backup

Git Repositories

Both user and group repositories are automatically backed up on a regular basis as git bundles . Backups are carried out early every morning. To request the restoration of a repository that has been accidentally deleted, please contact gitlab@fi.muni.cz .

It is not usually possible to restore a repository directly to GitLab, but we will provide a bundle containing a full backup and, where applicable, additional files containing an incremental backup. This backup can be restored as follows:

Issues, Milestones, …

Other project components (e.g. Issues) are backed up alongside the GitLab database. However, restoring these backups is complex and only the overall state of the database can be restored.

For this reason, these backups are intended solely for recovery in the event of a total outage. A complete recovery of individual projects (excluding repositories, see above) is not possible.

For information on backing up other systems, please refer to the document Backing up at FI.

Other useful features

The Faculty of Informatics holds a licence for the GitLab Ultimate version, which includes all features, including those of the Starter and Premium versions. You will find a list and comparison of the versions on the linked page. Of these, the following may be of interest to users at the Faculty of Informatics:

Further links and guides

• GitLab documentation
• an overview of some GUI clients for Git
• List of GUI applications with native GitLab support
• GitLab Git Cheat Sheet
• GitHub Git Cheat Sheet