What if my question is not answered here?
Open an issue in this project and ask away. If your issue is confidential, this can be indicated when writing the issue.
How can I create groups?
Users cannot directly create top-level groups. In general a top-level group should represent some autonomous unit within the University. Examples of top-level groups include: colleges, departments and divisions within a larger department. To request a group, open an issue in this project. We need to have a human-friendly name for the group, a suggested "short name" for the group and at least two initial admins for the group.
Note: all group admins must have already signed in to the Developer Hub and accepted the terms and conditions.
How can I create a group within an existing top-level group?
In general, we leave it to the managers of top-level groups to determine policy of how subgroups are created. The managers list of the top-level group may be public. (See, for example, the membership of the UIS group.) You may want to try contacting one of the top-level group owners in the first instance.
UIS is "special" in this regard in that the people who own the top-level UIS group overlap with the admins of the site. Rather than having a UIS-specific support project, UIS members can also request groups under the UIS namespace by raising an issue in this project. As the service matures we hope to make UIS less "special". See also the dedicated wiki page for UIS users.
How can I get a "Robot" account?
A "robot" account is an account which is not directly associated with an individual. These accounts are often used to integrate Continuous Integration/Deployment solutions with your source control or to access the GitLab API to integrate with an external tool.
The Developer Hub supports deploy keys which can be used to give access on a per-project basis to its repository. If a deploy key does not suit your needs, open an issue in this project and we can create a robot account for you.
There are some conventions associated with robot account users:
- They are named
{group}-{tag}-bot. For example:uis-support-bot. - They are configured as an external user.
- They must have a valid role email address associated with them. An initial password reset token is emailed to this address when created.
- We recommend that the robot user is configured with 2FA enabled. This helps guard against some of the dangers of having an account with shared access credentials.
How can I get an additional administrator account?
Administrators of institution-wide groups may wish not to use their day-to-day account for group-wide administration because they feel they have too much incidental visibility into the group. For top-level group owners, we're willing to give out additional administrator accounts.
There are some conventions associated with administrator accounts:
- They are tied to a single named user.
- They are named
{group}-admin-{crsid}. For example:uis-admin-spqr2. - They must have a valid email address associated with them which is not of the form
{crsid}@cam.ac.uk. We would recommend either a institutional address or the use of sub-addressing. For example:{crsid}+gitlab-{group}-admin@cam.ac.uk. This is because two GitLab users cannot share an email address. - As an account intended for group-wide administration, we recommend that the user is configured with 2FA enabled.
- GitLab admins may opt to disable the account if the named user associated with the account ceases to administer the related group.
How can I invite external collaborators?
An "external collaborator" is someone who you wish to give access to a Developer Hub project but who does not have an active Raven account. We grant external collaborator accounts on a case-by-case basis. Open an issue in this project if you want an external collaborator account created. We will need a human-friendly name for the collaborator and an email address.
External collaborator users have usernames of the form external-{...}. If you have any strong opinions on what the username should be, tell us. Otherwise we'll generate it from the local part of the external user's email address.
Is there any support for migrating from the git.uis.cam.ac.uk service?
Due to the way the git.uis.cam.ac.uk service is administered, local admin users have a great deal of flexibility in how they configure access policies for repos. At this moment in time we do not have an automated means to ingest access policies and construct a matching set of permissions.
For importing individual repositories, GitLab supports mirroring repositories between git.uis. You can set up GitLab to either sync changes from git.uis to the GitLab repo or sync changes to the GitLab repo to git.uis. See the mirroring documentation for more details.
A one-off mirror can be performed by changing the remote of a local clone of the repository and using git push --mirror:
$ cd path/to/repo
$ git remote set-url origin git@gitlab.developers.cam.ac.uk:/path/to/repo
$ git push --mirror originThe git.uis service also supports redirecting users to the Developer Hub once a repository is migrated. See the documentation on git.uis for more information.
Is Service Desk/New Issue by Email support available
Due to a technical issue we have disabled this feature. We're working to re-enable it. For the moment only "Reply to issue by email" is available.
As of 22 Jan, 2019, yes!
gitlab-runner isn't working for me
Firstly, check the upstream FAQ to see if your issue is already known about.
Within Cambridge we've also seen an issue running gitlab-runner on Windows within a folder whose name contains a space. Related upstream issue: https://gitlab.com/gitlab-org/gitlab-runner/issues/3422.
Is the GitLab Pages feature available?
No. Our GitLab install is based on the official GitLab Helm chart for deployment on a Kubernetes cluster. As such we're limited by the same limitations as the helm chart. The main user-facing limitation is that the GitLab Pages feature is unavailable. Work to enable GitLab pages is being tracked in the upstream helm chart repository.
I'm getting emails about "Auto DevOps" being disabled.
Auto DevOps is a feature of GitLab whereby it automatically attempts to run a CI pipeline with sensible defaults for software projects. If the pipeline fails the first time it is run, Auto DevOps is automatically disabled for your project. If you have no interest in Auto DevOps you can disable it for a project or for all projects within a group.
Is my data safe?
We have implemented appropriate data safety and integrity measures such as snapshots and backups.
What data can we store on this service?
We recommend that you do not store any data above Level 2 classification on this service.
How long will the service last?
We have identified on-going funding sources for the service and have no immediate plans for its retirement.
Is the service be stable? How will I know of any downtime?
The GitLab management team can only commit to a "best effort" SLA at this time. That being said, the management team actively use GitLab to manage the entire workflow of their team and so they are strongly incentivised to ensure its stability.
We have added the service to the UIS status line at https://status.uis.cam.ac.uk/. Announcements of service outage/maintenance will be made using this status line service and via a banner message within GitLab itself.
How can I sign in with GitHub and/or import projects from GitHub?
Log into GitLab via Raven, click your avatar in the top-right and navigate to "Settings > Account > Social Sign-In". Click "connect" next to the GitHub icon. You will then be redirected to GitHub which will confirm your permission for the GitLab to access some details from your GitHub account.
After connecting your account to GitHub you can also sign in with your GitHub account from the front page. To import projects from GitHub, follow the GitLab documentation for importing projects.
How can I use Google, GitLab or GitHub to sign in?
You may associate your GitLab account with an external account from your account settings. After you have associated an account, you can use the buttons on the sign in page to sign in with different providers. External users can also use this mechanism.
Does the "invite by email" feature work?
Yes, but it probably isn't the feature you're looking for. The invite by email feature sends an email inviting someone to visit the site and create a GitLab account. Since self-sign up is currently disabled for this instance, the email is useless. We cannot yet disable this feature in the UI and it's only use is to send a confusing email to someone. It is best avoided.
How can I link assets to releases?
GitLab Releases allow you to tag a particular revision of your project as a "release" and provide release notes, source code and links to built assets.
Assets may be added to a release, either by uploading the to GitLab (but must not exceed 10MB) or by linking them (if they are hosted somewhere else).
For larger releases we recommend that the built assets be hosted elsewhere. For libraries we recommend that they be hosted on the appropriate community package hosting facilities for the library's primary language. Examples of these include PyPI, npm, NuGet, Ruby Gems and Rust crates.
End-user applications can be hosted on platform-specific app stores. For example: Ubuntu PPAs or The Google Play Store.
For other type of assets, we recommend to upload them to Google Drive.