GitLab FI
GitLab is a web-based Git repository manager, similar to the well-known GitHub service. In addition to managing repositories (which are called projects here), GitLab can also do Wiki and Issue tracking.
Usage rules
- It is forbidden to change the group path.
- Repositories are not intended for uploading very large files.
- The size of a single repository has a hard limit of 3 GiB, exceeding 2 GiB in total will automatically send a warning email.
The size of individual repositories can be reduced by Project → Settings → Housekeeping. - There is a global limit of 100 repositories for users. The limit can be increased on request.
- Make sure to follow the operating rules.
If you have an active account with the School of Computer Science, 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 accounts 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 accounts. They can be used to make projects available to researchers and colleagues from other institutions, thesis opponents or advisors, etc.
It is not possible to create external accounts directly in FI GitLab, but FI staff (members of the group
fi-int
) can create, manage and block external accounts in the
external account management application in the Faculty Administration. Documentation and help can be found directly in the application.
Account validity
A GitLab account associated with a faculty account is only valid if the faculty account is active and unblocked. If the faculty account is blocked or terminated, access to GitLab , including SSH keys, will also be blocked.
SSH key
If you want to work with the repository from your own computer without having to enter a password each time, you can upload a public SSH key to your profile. Follow the instructions, here we only give tips especially for Linux systems.
Creating an SSH key
The
ssh-keygen
program may ask for a password during key creation. This is not mandatory, using a key without a password is easier then, 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
(the file may not exist yet):
Host gitlab gitlab.fi.muni.cz
HostName gitlab.fi.muni.cz
IdentityFile cesta_k_PRIVATNIMU_klici
For the meaning of each line, see
ssh_config(5)
. Test that the
ssh git@gitlab
command has the same output as above without explicitly specifying the key.
Using a key with a password
If you use this type of key as if it were without a password, every GitLab operation will require a password for the key, which offers almost no advantage over normal login. With the SSH agent, the key can only be unlocked once and then used repeatedly:
ssh-agent $SHELL
ssh-add ~/.ssh/id_gitlab
The first command launches the agent, which then launches a
new shell from the variable
$SHELL
. If your shell does not set this variable, enter the program path instead (e.g.
/bin/sh
). Exiting the shell also exits the agent. For more information on commands, see the man pages for
ssh-agent(1)
a
ssh-add(1)
.
Note that in older versions of this documentation and on various discussion forums, you may find a procedure that uses the
eval $(ssh-agent -c)
command or a similar command. We do not recommend using this procedure because it does not guarantee correct agent termination.
Kerberos
GitLab allows logging into the interface and cloning repositories using Kerberos tickets.
Use on Nymfe and Musa stations
After logging into the graphical desktop environment
nymfe* nebo musa*
the user automatically receives a Kerberos ticket, which can be verified with the 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 with Mozilla Firefox and Google Chrome (or Chromium), the Kerberos Spnego button can be used with a valid ticket instead of entering a password.Cloning
When cloning the repository, use the address from Clone with KRB5.Sync
The commandsgit pull
andgit push
will also work without a password with a valid ticket.
Tip
A ticket can be requested explicitly with the
kinit
command. This can be useful for remote SSH access with SSH key authentication (e.g. on Aisu), where a ticket is not automatically created.
Use from Aisa, Anxur or Aura servers
This login mechanism can generally be used from other UNIX machines on which Kerberos is configured for the
FI.MUNI.CZ
domain.
Login
1. Password login
If you enter a password when logging into the server, then you should have a ticket immediately available. Try the command:
login@aisa$ klist
2. Login without password
Logging in without a password (e.g. using an SSH key) will not create a ticket. If you don't have one, type the command:
login@aisa$ kinit
After entering your password, use
klist
to verify that you have a ticket.Working with Git
Now you can use operations in Git that work with Kerberos authentication (Clone and Sync above).
Renewing a ticket
If the ticket expires, the operations will stop working. For security reasons, GitLab reports a non-existent repository for each unauthorized access (even if it actually exists), so the error message may be a bit unexpected.
Anyway, check with
klist
that you have a valid ticket, and if not, create a new one withkinit
.
Setting up your own computer
This option can only be used for machines on the FI network. See also Restricting access to the FI network.
Kerberos
To use Kerberos authentication on your own machine, you must have installed tools for this authentication mechanism, e.g. from thekrb5-user
(Ubuntu, Debian) orkrb5-workstation
(RHEL, CentOS, Fedora) packages. To obtain a ticket, use the following command:user@machine:~$ kinit login@FI.MUNI.CZ
Git
Git may require a password during cloning and synchronization, which will result in an error when using Kerberos authenticationHTTP Basic: Access denied
.
This can be resolved by using 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
Typeabout:config
in the address bar . In the configuration, look for the keynetwork.negotiate-auth.trusted-uris
and add the valuefi.muni.cz
.Chromium
Run the browser with the parameter--auth-server-whitelist=*.fi.muni.cz
. It may be useful to create a custom script that runs Chromium with this parameter and place it in/usr/local/bin
.
Documentation for GitLab features can be found on the help page. In particular, we recommend
- basics of use (creating a project, demos)
- project access control
- migrating repositories
- 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 (i.e. does not need access to Issues, wiki, etc.), you can use Deploy keys (basically read-only access to the project using 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 the person (check with the maintainers).
Email replies
The Faculty GitLab has a Reply by Email feature enabled that allows you to reply to comments, "issues" and "milestones" directly by email. However, it is important to follow a few rules for proper functioning:
- reply directly to the inbox using the
Reply
function , do not write a new email - write your reply only above the quote or preferably delete the quote, as GitLab may not remove the quote correctly
- if you digitally sign your emails, do not add a signature to your GitLab reply
Markdown can be used in the email and attachments can be added, these will then appear as attachments in the GitLab reply.
Backup
Git Repositories
User and group repositories are automatically backed up as
git bundles on a regular basis. Backups take place early every day. To restore a repository that has been accidentally deleted, contact
gitlabo1ZkroqI7@fikh-q_8lfb.muniKKbBIXSTZ.cz
.
It is usually not possible to restore a repository directly to GitLab, but we will provide a bundle with a full backup and possibly additional files with incremental backups. This backup can be restored as follows:
Files
Consider a full backup in the
repo.9RhwIP.0.bundle
file and two incremental backups in therepo.9RhwIP.1.bundle
andrepo.9RhwIP.2.bundle
files.Restoration of full deposit
Create a clone of the repository from the full backup in therepo
directory :git clone --mirror repo.9RhwIP.0.bundle repo
Incremental advances
Move the full backup to use the loop:
Restore the 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
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 (e.g. Issues) are backed up with the GitLab database. However, restoring these backups is difficult and only the overall state of the database can be restored.
For this reason, these backups are only for the purpose of restoring during a total outage. Complete restoration of individual projects (except for repositories, see above) is not possible.
For information on backing up other systems, see the document Backing up to FI.
Other interesting features
The Faculty of Informatics has licensed a version of GitLab Ultimate that includes all features including Starter and Premium versions. The linked page lists and compares the versions. Of these, the following might be of interest to users in the Faculty of Informatics:
CI/CD
Automation of some parts of development, e.g. automatic testing, build or deployment of a production version of a project.
See also the description, official documentation and user documentation at FI.Issue Board
Issues add-on with a clearer interface.
See also description, and official documentation.Wiki
Repository for Markdown or AsciiDoc documentation for the project.
See also the official documentation.GitLab Pages
Website for a project with a static generator over CI/CD.
See also the description, official documentation, and user documentation on FI.Mirroring Repositories
Starter Automatically mirror Git repositories from other services.
See also the official documentation.
Security Dashboard
Ultimate Tools for monitoring and addressing security aspects of a project.
See also the official documentation.
Enhanced basic function options
Ultimate
- Setting up single and multiple assignees for issues (Multiple Assignees for Issues)
- Dependencies between issues ( Related Issues)
-
Rules for
git push
(Push Rules) - Scoped Labels (Scoped Labels)