GitLab Soft Launch Meeting Notes, 16^th January 2019, UIS

A selection of items arising in the Q&A at the end of the session has been included at the end of this document.

This meeting is to introduce the GitLab service which is part of the new University Developer Hub.

The GitLab team can be contacted by opening an issue on the support project. If there is a problem opening an issue, the role address gitlab-team@developers.cam.ac.uk can also be used.

The Developer Hub is intended to be a community building tool for Software Developers in the University.

It is still in its infancy but we're looking for early feedback on services and to build an initial community.

GitLab is an online platform which is intended to have the majority of tools required for modern software development.

GitLab is resourced by the Technology Development Fund until August 2019. Our aim is for it to be chest funded post August if utility can be demonstrated.

You can start playing with GitLab right away. The URL is https://gitlab.developers.cam.ac.uk/. You can log in via Raven and create repositories within a personal namespace. If you'd like to get a group under the UIS group, open an issue on the support project.

Our deployed GitLab instance is GitLab Ultimate. This has the maximum number of features available in a self-hosted instance.

Historical Context

Some of the following is taken from Tony Finch's notes on the current git service.

Git is a free version control system which can be used to track changes to a shared code base, share those changes with other developers and merge those changes into the shared code base.

UIS (then UCS) first launched a git service in 2013. It's currently managed by Tony Finch with assistance by Rich Wareham.

Using some statistics from the end of 2017, the current git service at git.uis.cam.ac.uk

• serves around 40 research groups and institutions;
• has around 500 users of which around 100 are active each month;
• hosts around 1000 repositories of which around 300 to 400 are active each month; and
• handles just shy of 2000 commits per month.

Although the service has been both popular and robust, it can be somewhat intimidating to users. Group management can, Lookup integration aside, require action by local admins.

The following features of the git service proved to be very good ideas:

• Delegated administration. The administrators of a given institution or research group's top-level "folder" had complete control over how repositories within their top-level folder was managed. (We call these top-level folders "accounts".)
• Light touch in deciding who had an account. If you viewed yourself as an autonomous group, we let you have a folder.

We're hoping to take those ideas forward. Some things which proved difficult with the current service:

• Group management. There is some Lookup integration but there are still too many times where adding/removing members to a group required emailing a local admin.
• User management. Adding users to an account required emailing a local admin.
• Cross-institution sharing. Beyond making a repository completely public, it was fiddly to share work across top-level accounts.

The GitLab service should help address some of those difficulties.

Where we are

We've secured the resources to deploy an "alpha" GitLab service. This service is resourced by the TDF until August 2019 after which we're seeking chest funding.

In the alpha phase we

• build a prototype of the service;
• test the prototype with users; and
• demonstrate that the service is technically possible.

We use our experience building prototypes in the alpha to:

• find problems with the design of the service and decide how to solve them;
• make some estimates about how much the service will cost; and
• identify the biggest risks for the beta stage, as early as possible.

By the end of alpha we aim to know:

• whether to move the service into the beta phase; and
• what we need to build in beta if we move into beta.

Although the service is alpha we are still intending it to be robust. We do not intend to delete data if we move to beta. We will perform appropriate data integrity measures such as snapshots and backups during the alpha phase.

The GitLab service is now live. We have a single top-level UIS group for UIS members and other autonomous bodies within the University can request top-level groups if the self-identify as an autonomous body. If you'd like to get a group, open an issue on the support project.

What we'd like from you

We want users within and without UIS to exercise our GitLab deployment and its features. We expect bugs and we expect policy questions to be raised which we don't have answers to. As such we want "tame users" who understand what stage this service is at and that some features may be missing or have bugs.

By adopting GitLab early, you'll have a chance to provide early feedback about what works for you and what doesn't. We aim to mold the future of the service based on this early feedback.

At the moment we have a fairly vanilla deployment with very little custom configuration. As the service progresses we'll add configuration where appropriate in response to user need.

How do I migrate repositories from git.uis?

We have no automated migration support at the moment. Because we gave local admins such flexibility to define permission models, it's non-trivial to migrate permissions over with complete fidelity.

Project owners may configure repository mirroring to either a) push changes made on GitLab back to git.uis or b) pull changes from git.uis into GitLab. Which direction owners choose depend on which repository they want to be "canonical".

More information can be found in the Developer Hub documentation.

Key GitLab Features

Repository Hosting

Like the current git service you can host shared or personal git repositories.

Delegated Group Management

Groups can contain subgroups. Owners of a group can manage membership of the group and subgroups themselves without involving a local admin.

Protected Branches

Branches in a project repository can be marked as "protected" to disable, amongst other things, force-pushes re-writing history or code being merged if it has not been reviewed or does not pass tests.

Merge Requests and Code Review

Collaborators on a project can submit their changes as a Merge Request. Depending on how the project is managed, a Merge Request can also be reviewed by another collaborator and feedback given in the Merge Request. The owners of a project may designate certain branches as requiring Code Review before changes are merged in.

Wikis

Projects can have associated wikis.

Flexible Permissions model

Users can be granted different levels of access to projects. Projects can be made publicly readable or restricted to people who can log into the GitLab service. (To a first approximation, this is the set of people with a Raven account and selected external collaborators.)

External Collaborators

An external person can be given a login and access to a project. External collaborators can optionally be given the same read rights as a Raven account holder on a case-by-case basis.

Continuous Integration and Deployment

GitLab comes with a flexible CI/CD system which can be used to run tests and/or deploy your code on every commit and/or merge request.

Resources

• GitLab help on the Developer Hub
• GitLab features list
• GitLab overview on LinkedIn Learning
• Git for teams on LinkedIn Learning

Q&A session

Can I use cloud-hosted CI tools like codecov.io?

In the specific case of codecov.io, yes. The codecov documentation includes information on integrating with self-hosted GitLab instances.

For other cloud-hosted CI tools you will need to check the documentation for that tool. Our self-hosted GitLab instance is often called "GitLab CE/EE" to distinguish it from the cloud-hosted gitlab.com.

If the service does not become chest funded, what will happen?

Ultimately, we would have to close the service. We do not intend to do this overnight. There will be advance warning and time to migrate to a cloud-hosted service or, if the intention is to deploy a different service, to the new service.

Will there be a migration step between "alpha" and "beta" stages?

We do not intend there to be service disruption between the alpha and beta phases. Those labels are used for project management purposes primarily. We intend the service to remain the same instance if we transition except that the label at the top will change.

Will the GitLab service replace git.uis.cam.ac.uk?

The intention is for GitLab to replace git.uis.cam.ac.uk. There is no proposed timescale for this.

What about GitHub Enterprise?

A cross-institution group were tasked with investigating git repository hosting solutions. GitHub Enterprise was, at that time, unable to make a repository entirely public which was seen as an essential requirement for a University service. This was not the only downside but it was the most significant.

Are there project management tools?

There are many project management tools provided in our GitLab instance. Information on them is available on the help page.

We do not currently offer any user support for the tools. We are interested in gathering feedback on their utility.

Can I use GitLab as a service desk frontend?

At the moment, we do not support creating issues via email or the associated service desk feature. This is for technical reasons related to University email provision and may be surmountable. We are keen to know if this feature is a priority for users.

How do I migrate robot users?

Robot users which require read-only access to a repository may use a deploy key. Robot users which interact directly with the GitLab API may need to have a robot account created. We can do this on a case-by-case basis. Open an issue if you believe you need a true robot user.