GitLab

Configuration settings for backing up repositories from GitLab.

Warning

Known limitations:

• Issues are not backed up

• SCM Backup supports GitLab.com (the SaaS option, see Pricing) only, the self-managed options are not supported!

  ⇒ see Why doesn’t SCM Backup support backing up local installations of [hoster X]?

• if you backup private GitLab repos, you need to create a new access token once a year (because they expire after 365 days, see Authentication below)

Sources

For the basics, please read the Sources section first.

For GitLab, the hoster entry in the config file needs to look like this:

hoster: gitlab

Authentication

Without authentication, SCM Backup can only backup your public repositories.

In this case, it shows a warning:

To backup your private repositories as well, you need to authenticate:

• To backup a user’s repositories, you need to authenticate with that user.

• To backup a group’s repositories, you need to authenticate with a user who has sufficient permissions to that group’s repositories.

Create a personal access token for SCM Backup for that user:

1. Ensure that you’re logged into GitLab with the correct user, then click this link to go to the “Personal Access Tokens” page.

   Click on “Add new token” ⇒ the token’s name and the correct scopes should be pre-filled.

   Warning

   Note that the token has an expiration date, and the maximum you can set is 365 days.

   (this was changed in GitLab 16.0, previously it was possible to have tokens that never expire)

   The default value is much less than that (at the time of writing this, it was a month), so be sure to change the default value.

2. Put the username and the token into the authName and password properties of the source in the config file.

   Example:

   sources:
   
     - title: some_title
       hoster: gitlab
       type: org
       name: your_group_name
       authName: your_user_name
       password: your_token
   

   This will backup the repositories of the group your_group_name, but authenticate with the user your_user_name.

Wikis and rate limits

Unfortunately, the “main” API call doesn’t return whether a project has a wiki.

To determine if there’s a wiki which needs to be backed up, SCM Backup has to do the following for each project that the API call returns:

1. check if the “wiki” feature is activated for the current project (this is the only information about the wiki that the Project API returns)

2. if yes, make a separate call to the Wikis API to check if this wiki has at least one page

Note

This means one additional API call per project with enabled wiki…even if the wiki doesn’t have a single page.

When you have lots of repos, this has two effects concerning GitLab’s rate limits:

• SCM Backup pauses after each wiki API call to avoid hitting the limit of 10 requests per second per IP address

  ⇒ the more repos you have, the more time will the whole API calling take

• There’s another limit of 600 API calls per minute altogether.

  ⇒ you may hit that limit when you have hundreds of repos and a fast Internet connection.

Both issues can be avoided by disabling the wiki feature in all projects that don’t actually use the wiki:

Your repository ⇒ Settings ⇒ General ⇒ expand Visibility, project features, permissions ⇒ scroll down to Wiki and disable it ⇒ scroll down and click Save Changes.