GitLab FI
GitLab is a web manager for Git repositories, similar to the well-known service GitHub . In addition to managing repositories (which are called projects here), GitLab can do the same Wiki and Issue tracking .
Terms of use
- it is forbidden to change your name even though GitLab allows it
- it is forbidden to change the group path
- repositories are not designed to embed very large files
- the size of one repository has a hard limit of 3 GiB, after exceeding 2 GiB in total a notification e-mail will be sent automatically
( Project → Settings → Housekeeping can reduce the size of individual repositories) - users have a global limit of 100 repositories , which can be increased on request
- pay attention to compliance operating rules
Login
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 login and password, the account will be created automatically after the first login.
External accounts
GitLab allows you to create a type of account that you cannot own or create projects. They can only contribute to projects to which they are given explicit access. These accounts are referred to as external . They can be used to make projects accessible to researchers and colleagues from other institutions, opponents or consultants of final theses, etc.
It is not possible to create external accounts directly in GitLab FI, FI employees (group members
fi-int
) may, however, create, manage and block external accounts in
external account management application in the Faculty Administration. Documentation and help can be found directly in the application.
Account validity
The GitLab account associated with the faculty account is valid only if the faculty account is active and unblocked. If the faculty account is blocked or expired, access to GitLab , including SSH keys , will also be blocked.
SSH key
If you want to work with the repository from your computer without having to enter a password every time, you can upload a public SSH key to your profile. Follow the instructions , here are just tips especially for Linux systems.
Creating an SSH key
Program
ssh-keygen
may ask for a password while creating the key. It is not mandatory, using a key without a password is then easier, however, a key with a password is more secure.
Using a key without a password
You can test the functionality of the key with 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
(file may not already exist):
Host gitlab gitlab.fi.muni.cz
HostName gitlab.fi.muni.cz
IdentityFile cesta_k_PRIVATNIMU_klici
The meaning of individual lines see
ssh_config(5)
. Try that command
ssh git@gitlab
has the same output as above without explicit key specification.
Using a password key
If you use this type of key as if it were without a password, every operation with GitLab will require a password for the key, which brings almost no advantages over normal login. With the help of the SSH agent, the key can be unlocked only once and then used repeatedly:
ssh-agent $SHELL
ssh-add ~/.ssh/id_gitlab
The first command starts the agent, which then starts
a new shell from the variable
$SHELL
. If your shell does not set this variable, enter the path to the program instead (e.g.
/bin/sh
). Exiting the shell also terminates the agent. For more information on commands, see the manual pages for
ssh-agent(1)
and
ssh-add(1)
.
Please note that in the older version of this documentation and on the various discussion forums, you can find the procedure that uses the command
eval $(ssh-agent -c)
or similar. We do not recommend using this procedure because it does not guarantee the correct termination of the agent.
Kerberos
GitLab allows you to log in to the interface and clone repositories using Kerberos tickets .
Use at Nymph stations
After logging in to the graphical environment of the computers
nymfe*
the user automatically receives a Kerberos ticket, which can be verified by a command
klist
:
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
Login
When logging in to Mozilla Firefox and Google Chrome (or Chromium), you can use the Kerberos Spnego button instead of entering a password with a valid ticket.Cloning
Use the address from Clone with KRB5 when cloning the repository.Synchronization
Commandsgit pull
andgit push
they will also work without a password with a valid ticket.
Tip
The ticket can be requested explicitly by command
kinit
. This can be useful for remote SSH access with SSH key authentication (eg on Ais), when the ticket is not created automatically.
Use from Aisa, Anxur or Aura servers
This login mechanism can generally be used on other UNIX machines that have Kerberos for the domain
FI.MUNI.CZ
configured.
Login
1. Login with password
If you enter a password when logging in to the server, then you should have a ticket available immediately. Try the command:
login@aisa$ klist
2. Login without password
Login without a password (eg using an SSH key) does not create a ticket. If you do not have another, type the command:
login@aisa$ kinit
After entering the password, verify with
klist
that you have a ticket.Working with Git
You can now use operations in Git that work with Kerberos authentication ( Cloning and Synchronization above).
Ticket renewal
If the ticket expires, the operations will stop working. For security reasons, GitLab reports a non-existent repository for each unauthorized access (even though it actually exists), so the error message may be a bit unexpected.
In any case, check with
klist
that you have a valid ticket, and if not, create a new commandkinit
.
Setting up your own computer
This option can only be used for machines in the FI network. See also Restrictions on access to the FI network .
Kerberos
To use Kerberos authentication on your own computer, you must have the tools for this authentication mechanism installed, such as from packageskrb5-user
(Ubuntu, Debian) orkrb5-workstation
(RHEL, CentOS, Fedora). To obtain a ticket, use the command:user@machine:~$ kinit login@FI.MUNI.CZ
Git
Git may require a password when cloning and synchronizing, which will result in an error when authenticating with KerberosHTTP Basic: Access denied
.
This can be solved with the following command:# nastavení pro uživatele user@machine:~$ git config --global http.emptyAuth true # nastavení pro celý systém user@machine:~$ sudo git config --system http.emptyAuth true
Mozilla Firefox
Enter in the address barabout:config
. Locate the key in the configurationnetwork.negotiate-auth.trusted-uris
and add valuefi.muni.cz
.Chromium
Launch the browser with the parameter--auth-server-whitelist=*.fi.muni.cz
. It may be helpful to create your own script that will run Chromium with this parameter and place it in/usr/local/bin
.
Documentation of services and functions
Documentation on GitLab functions can be found on the page help . We especially recommend
- basics of use (project creation, samples)
- project access control
- repository migration
- git
Repository sharing
If you want to make the repository available to other people beyond the "visibility" of the project ( Private , Internal or Public ), you can set them as members of the project, see adding members .
If you want to make a private or internal project available to a person without a faculty account and that person only needs access to download the project (ie does not need access to Issues, wikis, etc.), you can use Deploy keys (basically read-only access to the project using an SSH key). If access to other services or the opportunity to contribute to the project is required, the project must be published or an external account must be created for the person (ask the administrators).
Email replies
Faculty GitLab has the Reply by E-mail feature enabled, which allows you to reply to comments, "issues" and "milestones" directly by e-mail. However, several rules are important for proper operation:
- reply directly to the received e-mail using the function
Reply
, do not write a new e-mail - write your answer only above the citation or preferably delete the citation, as GitLab may not delete the citation correctly
- if you digitally sign your e-mails, it is better not to add a signature to the GitLab reply
Markdown can be used in the e-mail and attachments can be added, which will then appear as attachments in the reply in GitLab.
Backup
Git Repositories
User and group repositories are automatically backed up regularly as git bundles . Backup takes place early every morning. Request to restore a mistakenly deleted repository at gitlabnA_UBty72@fiF645Q3X9Q.muniWuGSVRzWd.cz .
The repository usually cannot be restored directly to GitLab, but we will provide bundles with a full backup and possibly other files with an incremental backup. This backup can be restored as follows:
Files
Assume a full backup in the file
repo.9RhwIP.0.bundle
and two incremental file backupsrepo.9RhwIP.1.bundle
andrepo.9RhwIP.2.bundle
.Restore a full backup
Create a clone of the repository from a full backup to a directoryrepo
:git clone --mirror repo.9RhwIP.0.bundle repo
Incremental backups
Move the full backup so that you can use the cycle:
Restore incremental backups:mv -i repo.9RhwIP.0.bundle repo.9RhwIP.bundle
for bundle in repo.9RhwIP.*.bundle; do git -C repo remote set-url origin "${PWD}/${bundle}" git -C repo remote update done
Restore to GitLab FI
If you want to return the repository to GitLab FI, create a new project for it and run the following commands:git -C repo remote set-url origin ${url_repozitáře} git -C repo push --all git -C repo push --tags
Issues, Milestones,…
Other project components (eg Issues) are backed up together with the GitLab database. However, restoring these backups is difficult and only the overall state of the database can be restored.
Therefore, these backups are for recovery purposes only in the event of a total outage. Complete renewal of individual projects (except for repositories, see above) is not possible.
See the document for information on backing up other systems Backup to FI .
Other interesting features
The Faculty of Informatics has a license for the version GitLab Ultimate which contains all the options including Starter and Premium versions. On the linked page you will find a list and comparison of versions. Of these, the following could be of interest to users at the Faculty of Informatics:
CI / CD
Automation of some parts of the development, eg automatic testing, assembly or deployment of the production version of the project.
See also description , official documentation and documentation for FI users .Issue Board
Issues add-on with a clearer interface.
See also description , a official documentation .GitLab Pages
Website for a project with a static generator over CI / CD.
See also description , official documentation and documentation for FI users .Repository Mirroring
Starter Automatic mirroring of Git repositories from other services.
See also official documentation .Security Dashboard
Ultimate Tools for monitoring and solving security aspects of the project.
See also official documentation .Improved basic features
Ultimate
- Setting up one or more people to solve a problem ( Multiple Assignees for Issues )
- Dependencies between problems ( Related Issues )
- Rules for
git push
( Push Rules ) - Sublevel labels ( Scoped Labels )