Skip to content



The IGWN GitLab instance is available at

All IGWN members are eligible for GitLab accounts, see below.

Host keys

The SSH host keys used for GitLab were updated on 30 April 2024 to be signed by the newly created UWM certificate authority. So that your ssh client automatically accepts keys signed by this certificate authority please add the following to your known_hosts file:

@cert-authority * ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKQJ2hQgggD8AS3DJSTfMFp83PvKx/P5gdwxgnqYQXVmsoWEmWrdq717vd1GGpCG5e2/aiBJ5ci7/fLO/LBvOZE= UWM_SSH_CERT_AUTHORITY

You may also need to remove the existing entry for from your known_hosts file. This can be done using:

ssh-keygen -R

For completeness, the specific fingerprints of the keys are:

256 SHA256:RdfTUwLNyFhuwrkRpV0dyuURs4dYGMAK/NpcgnTX4m8 (ECDSA)
256 SHA256:Rmg83x7sO+y61xu/kFU8eU1QL2o7e9bWJjrA5Tu3Kb4 (ED25519)
3072 SHA256:Oqqggzp0CXfFf8ee8D63VcIYdITlzclZrLVOIQUFoJs (RSA)

Getting set up

Create an account

  1. Browse to, if you are not logged in, or do not have an account, you will be redirected to a login prompt that looks like this: login prompt

  2. Click on the LIGO-Virgo-KAGRA sign-in button. If you do not have an existing account, one will automatically be created for you with the default username <firstname>.<lastname> copied from your LIGO.ORG or gw-astronomy (KAGRA) identity.

    Your account

    Older GitLab accounts may have a dash, rather than a dot, in your account name. This is an account local to that was created from your LIGO.ORG username, but it is not your LIGO account itself!

Change your username

You can change your username at

Add an SSH key

In order to clone Git repositories using SSH (recommended), you should create and upload an SSH key to your GitLab account.

For instructions, see

Set a GitLab password

If you wish to be able to clone Git repositories over HTTPS, you must set a password at

Use a strong, unique password

As with all websites for credentials, you should use a strong, unique password to secure your account. Do not use the same password as for your collaboration identity.

Configure email addresses and notifications

GitLab will send e-mail notifications in response to events on projects you manage or participate in. By default, they will be sent to your collaboration e-mail address; for members of LIGO or Virgo, this is <firstname>.<lastname>; for KAGRA members this is the address which was originally registered at If you prefer an alternative, you can add additional e-mail addresses, verify them by clicking on the link sent to you by e-mail, and change your notification address. Additionally, you can customize the events which cause notification e-mails.


By default, your own activity will not generate a "self-notification". If you want to test the behavior of GitLab e-mail, you may want to enable Receive notifications about your own activity.

When an issue is created in a project that you control, you will receive a notification e-mail according to your notification settings. Each issue has an associated "discussion" to identify a proper solution. You can add to this discussion by replying to the notification e-mail or by clicking on the link in the e-mail and commenting via your web browser.

Replying to email notifications

When replying by e-mail, do not modify the reply address as it contains a unique tag that allows GitLab to identify you in the discussion. It does not use your From: address to identify you because it can be easily faked.

Available features

The IGWN GitLab instance is GitLab Ultimate, providing access to almost every feature available from GitLab.

Some specific features are highlighted below.

GitLab CI/CD

Provided with the GitLab instance is a fully-featured continuous integration system, allowing projects to define an automated pipeline to build, test, deploy, and monitor the project during development and deployment.

For more details, see GitLab CI.

GitLab Pages

GitLab Pages is a feature of GitLab that allows you to automatically generate websites based upon your projects. A typical use case is to automatically generate documentation.

A given's project webspace will appear at the following URLs

  • https://<group/user>{<subgroup>/}<project>

    This URI is the best supported option by GitLab and the one we recommend. <group/user> namespace is your username if the project appears under your GitLab space, or the group's name if it is in a shared space.

    Example: this guide uses GitLab Pages

    The source documentation for this guide lives at

    where computing is the group namespace, and guide is the project name, so GitLab Pages hosts the output at

    Example: subgroup pages

    The project that configues IGWN Software Metapackages lives in the computing/packaging subgroup at

    where computing is the top-level group, packaging is the subgroup name, and metapcakages is the project name. It's GitLab Pages site is hosted at


    This URI is provided via a workaround that doesn't appear to work uniformly, particularly with respect to whether users type a trailing slash after the project. You should use it primarily if the namespace/username has a period in it. Users with periods in their username must either use the address or the alternative

GitLab Pages are public by default

By default GitLab Pages sites are public, requiring no authorisation, however access control can be enabled per project. For details see

Service Desk

The GitLab Service Desk is a feature primarily aimed at allowing external users -- anyone not in the IGWN community -- to create and track issues via e-mail. Each new project on the has Service Desk enabled by default; older projects will need to turn it on by selecting "Issues => Service Desk" on the left-hand-side when viewing the project. Each project will receive an e-mail address like contact+lscsoft/

Custom email aliases can be created

If desired, it is possible to create an email alias such as with the domain name. This is a more convienent email address to distribute to people than the generated email address, e.g.,

If you are interested in having an alternative/alias email address for your report/project Service Desk, please create a helpdesk ticket, with this request.

When a user e-mails that address:

  • a new issue is created and the user receives a confirmation e-mail

  • that issue is marked as confidential so that only specifically listed members of the project can see the issue

  • all correspondence from the user appears to come from "GitLab Support Bot" even when it has been submitted via email by a LIGO/Virgo/KAGRA member.

    If you have a GitLab account, don't use the Service Desk

    It is recommended that account holders create issues via the web interface - the web interface provides a much richer feature set than email correspondence and will likely result in better support from the Computing team.

    Service desk should be primarily reserved for enabling interactions with individuals who cannot be granted a account.