Wikimedia Release Engineering Team/GitLab/Features
Appearance
Below is a list of features in GitLab Enterprise Edition that may be useful but are not available in the GitLab Community Edition.
This table is sorted by importance/likelihood of need.
Feature | Description | Docs | Workaround available | Notes |
---|---|---|---|---|
Merge approvals | Merge request approvals enable enforced code review by requiring specified people to approve a merge request before it can be merged. | docs | ✔ | This feature, in some form, is making it's way to CE.
See also: "Merge Trains". tl;dr: marge-bot is in use by other large projects and may cover most of the use cases here. |
Contribution Analytics | Get an overview of merge requests and push events for a group. | docs | ✔ | Applies to groups of projects - some of this info is available on a per-project basis, and could be likely be recreated from API at the group level. Usage examples in the docs mention incentivizing volume of commits, which is generally an anti-pattern.
|
Code Review Analytics | Displays a table of open merge requests that have at least one non-author comment. Review time is measured from the time the first comment was submitted. | docs | ✔ | Could be useful for surfacing reviews that need attention and driving down cycle time.
|
Merge Trains | A queued list of merge requests, each waiting to be merged into the target branch. Many MRs can be added to the train. Each MR runs its own merged results pipeline, which includes the changes from all of the other requests in front of it on the train. | docs | ✔ | Zuul gives us this already, but it's cross project as well. marge-bot is in use by other large projects and may cover most of the use cases here. |
Merge Request Dependencies | If a merge request “depends on” another, then it cannot be merged until its dependency is itself merged. | docs | ✔ | Important for our workflows, but can be re-implemented as a CI job. |
Code Quality | Evaluates changes against Code Climate engines. | docs | ✔ (we do this differently) | We evaluate code quality in CI at present, and would continue doing so. |
Productivity Analytics | Visualize typical merge request (MR) lifetime and statistics. | docs | ✔ | Currently gather this information via Bitergia. |
Code Owners | Use a CODEOWNERS file to define who owns specific files or paths in a repository, allowing other users to understand who is responsible for each file or path. | docs | ✔ | This can be worked around via CI and Merge Requests (see above). |
Built-in and custom project templates | docs | ✔ | This is one way to disable wikis easily without having to make some CI job that does it, but a CI job was suggested by GitLab as how they would do it. | |
Credentials Management | docs | Unclear of need. | Self-managed only. Management of user's ssh keys and their access. Not entirely clear at what level. In CE an admin can see and delete user's pubkeys.
| |
Multiple approvers in code review | Rules to require multiple approvers before a merge request can land | docs | ✔ | This can be worked around via CI and Merge Requests (see above). |
CI/CD Pipelines Dashboard | Provides a summary of each project’s operational health, including pipeline and alert status. | docs | Unclear of need. | Probably useful for an overview of CI pipelines for each project, but may be partially relate to deploy / monitoring features we're unlikely to use. |
Create and remove admins based on an LDAP group | Specify a group CN for admin_group and all members of the LDAP group will be given administrator privileges | docs | ✔ | Not available on hosted/gitlab.com EE plans |
Approval rules for code review | Require approvals from multiple groups before allowing merge. | docs | ✔ | Advanced feature. Something we have but don't use currently. Could be reimplemented as a CI job. |
Merge request reviews | Submit all reviews as one email, rather than per commit. | docs | ✔ | This has been ported to GitLab CE. Still listed on feature list. |
Insights | Yaml specification for individual project statistics. | docs | ✔ | This is the kind of data we currently get from https://wikimedia.biterg.io but limited per project. |
Advanced Global/Syntax Search | Use advanced queries for projects to which you have access. | docs, docs | ✔ | This isn't yet available for GitLab.com; they anticipate it Q3 2020. We have this already with https://codesearch.wmflabs.org/. |
EVERYTHING BELOW THIS LINE IS NOT LIKELY TO BE A BLOCKER[edit] | ||||
PostgreSQL HA | High availability configuration for postgresql via consul. | docs | Only needed if using the omnibus GitLab install, which we are not going to use. | |
Group webhooks | Groups of projects share a webhook | docs | ✔ | Webhooks look useful. Managing them per group rather than per project looks useful. There are other ways to do this; this provides a UI for doing this easily. |
Live upgrade assistance | Support for upgrades | docs | ✔ | GitLab can't do the upgrade for you. There are, of course, contractors. |
Audit Logs | Lets owners and administrators know who edited values on the server. | docs | ✔ | This information is always available to folks with access to server logs, this presents the info in the UI. |
Reject unsigned commits | Rejects commits not signed by PGP key | docs | ✔ | Could be a CI job. Could also be implemented as a server hook which is part of the CE version. |
Multi-project pipeline graphs | Visualization UI enhancement for pipelines that trigger other pipelines. | docs | ✔ | Makes an svg graph to visualize what your settings are. Could be easily re-implemented in CI. |
Globally distributed cloning with GitLab Geo | Read-only secondary git nodes that are geographically distributed. | docs | Speed up clones for users outside the US where our primary datacenter is located. | |
Deploy Boards | GitLab’s Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes | docs | Similar to https://integration.wikimedia.org/zuul/ but specific to k8s CI runners. Nice to have. | |
Browser Performance Testing | Determine performance impact of changes | docs | ✔ | Easy to reimplement as a CI job. Uses open source https://www.sitespeed.io/ on the GitLab.com version. |
Pipelines for Merged Results | Run tests on merged branch rather than source branch. | docs | ✔ | Similar to zuul, our current solution. This is part of the, "Not Rocket Science Rule Of Software Engineering". Open source peers, namely freedesktop.org, use marge-bot for this. |
Static Application Security Testing | Static security analysis | docs | ✔ | Easy to reimplement as a CI job. Uses open source static analysis scanners (e.g., KubeSec, phpcs-security-audit, etc) on the GitLab.com version. |
Container Scanning | Scans containers for vulnerabilities. | docs | ✔ | Easy to reimplement as a CI job. Uses klar and clair on the GitLab.com version. |
Dynamic Application Security Testing | DAST test for code | docs | ✔ | Easy to reimplement as a CI job. Uses zaproxy on the GitLab.com version. |
License Compliance | Check that licenses of your dependencies are compatible with your application, and approve or deny them. Results are then shown in the Merge Request and in the Pipeline view. | docs | ✔ | Can be reimplemented as a CI job. |
Status Detail Pages | Static site for status | docs | ✔ | Easy to create a fallback page in apache when a proxy is failing. Other types of errors less easy to communicate. |