FAQ - Software Engineering Services (GitLab)

Each GitLab Account (via SSO) can create 50 projects within GitLab.

https://blog.rwth-aachen.de/itc/2023/04/26/gitlab/ (opens in new tab)

After login, a new account was generated because your contact email address from IdM Selfservice (opens in new tab) and the primary email address of your actual GitLab account are different.

However, the old account still exists. You can solve the problem on your own with the following steps:

1.     Set the primary email address stored in your original account as the contact email address in Selfservice.
2.     Delete the new account by yourself (git-ce: https://git-ce.rwth-aachen.de/-/profile/account (opens in new tab) // git.rwth: https://git-ce.rwth-aachen.de/-/profile/account (opens in new tab))
3.     Wait for a synchronization time of about 20 minutes
4.     Now you can log back into the original account

* If you do not know the mail-address for 1., please contact the IT-ServiceDesk

Note: Afterwards, you can change your email addresses again as you wish, since a new ID has been saved in your GitLab account.

The Login via Github is intended only for external project partners who can't authenticate via Shibboleth. Please use the Github Login only when there is no possibility to authenticate via Shibboleth, because the account will otherwise be flagged as external and the right to create projects will be revoked.

Login via DFN-AAI

This is related to the change of the login from 03/05/2023:

https://blog.rwth-aachen.de/itc/2023/04/26/gitlab/ (opens in new tab)

If the error occurs, it means that your contact mail address from the Selfservice (opens in new tab), is not set as primary mail address in GitLab, but as e.g.: secondary mail address.

You can solve the issue yourself by changing the contact mail address in Selfservice (opens in new tab) to the current primary address of your GitLab account, waiting for a synchronization period of 20 minutes, and then logging in again.

Note: This action is only necessary once to store a new ID in GitLab. You can change all mail addresses again afterwards.

Login via GitHub

The error may be caused by the fact that you have logged in via GitHub. The login via RWTH Single Sign-On does not work if the contact email address in the Identity Management of RWTH (opens in new tab) is identical to the email address from GitHub.

If you are able to log in via GitHub, please try to activate the login via the RWTH Single Sign-On on your own:

1. log in via GitHub, if possible.
2. click on the avatar icon in the top right corner of your dashboard.
3. click "Edit Profile" in the menu that pops up.
4. click "Account" in the navigation on the left.
5. in the "Social sign-in" section, click on the "DFN-AAI Single Sign-On" button to sign in using RWTH Single Sign-On.

You can then log in using both GitHub and the RWTH Single Sign-On.

To be able to create projects and/or groups, you need to be additionally unlocked. To do so, please tell us your GitLab username (you can find it by clicking on the avatar icon in the upper right corner, behind the @).
We will grant the appropriate permissions.

For security reasons, e-mail addresses from the @outlook.com or @hotmail.com domains cannot be used as contact e-mail addresses in IdM Selfservice or for GitHub accounts.

To resolve the issue, use an e-mail address from approved mail domains. 

When changing the contact e-mail address in the selfservice, the system needs approx. 20 minutes to synchronize your data. You can then log in again.

When signing in using the Single Sign-On (SSO) you may receive the error message "Return parameter is not included in the positive list".

If this occurs, you should clear your browser's cache before trying to sign in again.

Once a group permission has been set, it is not possible to grant individual user permissions (that deviate from the set group permission) to members of the group.

Users can change their displayed username by themselves via "Profile → Account". Please be aware of the fact that by changing the username, the namespace will automatically be altered as well. As a consequence, all links to already existing projects will be altered too.

When git-cloning, users need to use their username from GitLab (not the email and not the Shibboleth username!) and a specific access token, that needs to be set in advance (user settings - access token), to log in. The username (format: ab123456) and the associated password can not be used in this case.

As a group, any number of projects can be created.The number of projects of a group does not affect the quota of each group member.

You can conventionally authenticate with a username and password to use GitLab push and pull. This password needs to be set in the GitLab userprofile though. As soon as a password has been set, push & pull will work out via https.

DSA keys are not supported by OpenSSH 7.0 and newer Versions but not rejected by GitLab. That leads to an error.

A RSA key is to be used instead of a DSA Key.

First, you need an App to generate two factor auth codes. A list of Apps with code generator

Google Authenticator
Play Store: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=de (opens in new tab)
iTunes: https://itunes.apple.com/de/app/google-authenticator/id388497605?mt=8 (opens in new tab)

Authy
Play Store: https://play.google.com/store/apps/details?id=com.authy.authy&hl=de (opens in new tab)
iTunes: https://itunes.apple.com/de/app/authy/id494168017?mt=8 (opens in new tab)

After the install of the app, go to your GitLab profile (https://git.rwth-aachen.de/-/profile/account (opens in new tab)) and activate the two factor authentification.

You can find your Username

• In the usermenu on top right (just behind the @)
• On the site https://git.rwth-aachen.de/-/profile/account (opens in new tab)   // https://git-ce.rwth-aachen.de/-/profile/account (opens in new tab) ("Change Username")

Currently we do not offer a GitLab Runner for all users. To install your own GitLab Runner on your computer or server, please follow the official GitLab Runner instructions (opens in new tab).

Git LFS is active by default on both GitLab instances of RWTH Aachen University in all repositories. A tutorial on git LFS can be found here

In order to restore the images, you have to follow the next steps:

1. Clone Wiki Repo (in the GUI under Wiki → "Clone Repository" at the top right, then execute the command shown)
2. Export repo (in the GUI under Settings → General → Extensions → Export project)
3. Unpack the generated export
4. Copy and push the files and directories from the uploads folder from the export to the uploads directory of the locally cloned wiki

5. Adjust the paths in all * .md files and make a backup at the same time:

6. Now "push" the changed files back into the repository. Ignore the .bak files

7. Check wiki in GUI

If you have not logged in to your account for two years, your account will be deactivated, and you will be sent an e-mail with the subject “Your Account has been deactivated”.

To reactivate your account, you simply need to log in to GitLab.

For a short period of time, git-ce and git.rwth can still be used.

The exact date for the migration from git-ce has not yet been determined. We will notify you as soon as a date is set.

When migrating from git.rwth to git.nrw, please note that git.nrw has similar terms of use and that the quota limits cannot be exceeded.

If your projects exceed this quota, it is possible to increase the project limit either before or during the migration.

If you need to increase your quota on git.nrw, please use the contact form (opens in new tab).

The following guides are available:

Migration to git.nrw

Migration to another GitLab (opens in new tab)

Please contact the owner of the project you are collaborating on. They will let you know which target system the project will be migrated to and when.

If the project is migrated to git.nrw, you can use the git.nrw guest management system. Instructions can be found on the page Inviting guests to git.nrw.

Yes, a current guide on DOIs in GitLab is available on the website Assigning DOIs to GitLab Repositories (opens in new tab)

The Keep latest artifacts feature was disabled to ensure sustainable storage management in GitLab and to prevent excessive storage consumption caused by outdated or unnecessary artifacts.

Previously, the most recently created artifacts (for example, builds or releases) were retained automatically, even if they were more than 90 days old, regardless of the default retention period.

Effective immediately, the default retention period of 90 days applies to all artifacts, including the most recently created ones. 

This means:

• All artifacts older than 90 days are automatically deleted.
• There is no longer an exception for the latest artifacts.

If you have configured a custom expiration date for your artifacts, as described on the page Artifacts with an expiry (opens in new tab), this change does not affect you.