Page History

<div style="background-color: yellow; border: 2px solid red; margin: 4px; padding: 2px; font-weight: bold; text-align: center;">
This page was moved to <a href="https://kb.wisc.edu/134116">kb.wisc.edu/134116</a>
<br>
Click in the link above if you are not automatically redirected in 10 seconds.
</br>
</div>
<meta http-equiv="refresh" content="5; URL='https://kb.wisc.edu/134116'" />

The DoIT GitLab instance (https://git.doit.wisc.edu/) is available to SMPH groups to host your codebase, track issues, collaborate on code, and continuously build, test, and deploy your app with built-in GitLab CI/CD. For a general overview of the service from an SMPH perspective, see the GitLab service page for SMPH. 

...

This instance is licensed at the Ultimate tier. See https://about.gitlab.com/features/.

Note that Service Desk for GitLab projects is now available. It is turned on by default. This allows others to create confidential issues in your project without an account by posting to a special email list. You can disable this feature by going to Settings → General → Service Desk.

What are some best practices and guidelines for SMPH users of GitLab?

...

Subgroup owners can create groups and projects. Members with the Developer role can create projects. See How to Create GitLab Groups and Projects for details on how.

What permissions or role should I

...

grant  someone when I add them to my group or project?

Key permissions for groups:

...

More information about GitLab permissions can be found at https://git.doit.wisc.edu/help/user/permissions. 

Note: Permissions can only be increased for sub-groups; you cannot further restrict a person's role. See below. 

Can I restrict someone from inheriting a more powerful role?

No. GitLab only supports increasing permissions with sub-groups; you can’t remove roles that they inherit from a parent group. See https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership. You may notice that there are several members of your group that you don't recognize. These are members of SMPH IT that are responsible for security, administration, or management of the SMPH area of GitLab.

Can GitLab be used for research?

Researchers may use GitLab to manage the source code for projects but they should not use it to store research data, especially sensitive and restricted. It the work is in the public domain, it can be under the SMPH (Public). If the work is proprietary, private, or unpublished it can be under SMPH as long as it is viewable only to appropriate authenticated users and appropriate controls are in place. See SMPH GitLab – Public, Internal, Sensitive, and Restricted Data Guidelines, DoIT GitLab for Research, and DoIT GitLab Projects for more information.

...

Can external people collaborate? What about UWH employees?

Yes, but they will need a NetID. The current recommendation is to invite vendors and external collaborators to a relevant Manifest group that allows external invites. If your department already has an appropriate group, you can invite them to that group. If your department does not, you can the SMPH Application Support team and ask them to invite the person to the SMPH External Collaborators group. Once the person accepts the invite, they are given an opportunity to create a NetID if they do not already have one. For more information, see Manifest - Using a Manifest Group to Invite People to Create Identities (NetIDs).

There is a special case for UW Health employees, who often have a UW NetID but do not have an @wisc.edu email address. They will need to be able to use MFA Duo also, in order to log into GitLab with their NetID. Once that’s set up, just let the DoIT Shared Tools team know the user’s NetID and they can add it to their list of NetIDs that are allowed access, even though they’re not UW-Madison staff.  They can then log in and create their account. After that, you can invite them to the project you want them to access with whatever permission level you choose.

How do I migrate my project to GitLab?

...