GitLab

Git is a software for version management of data. It is primarily intended to manage text files such as source code, latex files or scripts. With GitLab (https://gitlab.gwdg.de), the GWDG provides a service to easily manage so-called Git repositories. In addition to version management, GitLab also offers management, bug tracking and wiki functionalities. Furthermore, when working with multiple contributers, changes can be checked via “merge requests”. GitLab is very similar to the well-known commercial service github.

Further information on git and capabilities can be found here. 

All employees and students of the University of Göttingen as well as employees of the Max Planck Society are entitled to use the system.

Students and employees of the University of Göttingen as well as customers with a GWDG account simply log in as usual with their e-mail address and password. Employees of the Max Planck Society who do not have a GWDG account can register at https://gwdg.de with their institute's e-mail address.

In justified individual cases, it is also possible to give external users access to GitLab. Please contact support@gwdg.de for further information.

Users can create up to 50 GitLab projects. If you need a higher number of projects, please contact support@gwdg.de.

Git repositories are not designed to store large binary formats (images, office files, multimedia files). Please use GWDG ownCloud for these purposes.

The storage space of individual projects is currently not limited. If we notice an improper or abusive use of GWDG GitLab, we will contact you and work out a suitable solution. We reserve the right to temporarily block write access to suspicious projects.

Keeping track of dependencies across many projects is tedious. Our central Renovate service checks your project every two hours and opens a merge request whenever a dependency has a newer version. You then review it like any other MR. Each project is processed in its own short-lived container, so projects never see each other’s code.

To get started, invite the @renovate-bot user to your project as Developer. On the next run you’ll get a merge request “Configure Renovate”, which adds a renovate.json. Once you merge it, Renovate starts opening update MRs, and a Dependency Dashboard issue shows an overview (if issues are enabled in your project).

Please invite the bot only as Developer, never Maintainer. Developer is enough to open MRs, while Maintainer would let it merge into protected branches and read your CI/CD secrets. Also protect your default branch (Maintainers only), so every change from the bot goes through your review.

Public registries work out of the box. For registries that require a login, the bot can’t use your project’s CI/CD variables. In that case, run your own Renovate job inside your project’s pipeline, and don’t invite the bot as well, so you don’t get duplicate MRs.

To stop Renovate, simply remove the bot from your project.

Since switching to SSO-only, private projects can no longer be accessed via http(s) using the account password. There are three possible solutions for this:

1. (recommended!) Use of SSH. You can read about how to set it up here. At first login with your new SSH key, you will be asked to verify the integrity of the server. The fingerprint may be found here. Note that you will have to change the remote origin of your local repositories to use the SSH-url, either using the command git remote set-url origin git@gitlab.gwdg.de:Path/to/project.git or directly editing the url-field in .git/config.
2. Use a Token. In your account settings, you may generate a “personal access token” with the scopes you need. These tokens have a maximum lifetime of one year and you may use them like a password, once prompted for it. There are also token created in a group-context or in a project and are usually used in special contexts.
3. Set a password. You may also set a password inside GitLab. We don't suggest this method.

On Windows, an unexpected error may occur where an SSH connection works (for example, when testing with ssh -T git@gitlab.gwdg.de), but Git commands fail. The issue may be related to a P: drive, causing Git to unexpectedly look in the wrong directory for the .ssh configuration folder, possibly trying to use the wrong SSH keys and thus resulting in an authentication error.

The solution is to configure Git so that it uses the “correct,” i.e., local, configuration folder. You can do this as follows:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe -F C:/Users/%USERNAME%/.ssh/config"