GitLab 12.8 Release

Credential inventory for group-managed accounts

Credential inventory for group-managed accounts

Managing access to your GitLab.com groups requires visibility into the credentials people are using to take actions within those groups.

In GitLab 12.8, we’ve extended the credentials inventory from self-managed instances to GitLab.com. Now, owners of group-managed accounts can view the SSH credentials and personal access tokens that exist within their groups. This inventory shows the user, the type of credential, and the expiration date so you can make informed decisions about access and rotation.

New audit events

New audit events

We’re continuing to add audit events to improve the visibility of activity in your self-managed instances and GitLab.com groups. In this release, we’ve added administrator actions to create, block, or delete users and include username changes in the self-managed instance logs.

These new audit events will help compliance-minded organizations to maintain separation of duties, access management, and nonrepudiation.

Dark syntax highlighting theme for Web IDE

Dark syntax highlighting theme for Web IDE

GitLab has long supported alternative syntax highlighting themes for use when browsing files in the repository or viewing diffs during the code review process. However, our code editor areas have not supported the use of this preference despite being the most requested feature for the Web IDE.

The Web IDE now supports the Dark syntax highlighting preference in the code area. We’ve started with this theme, as it’s the most widely used one beyond our default, but we’ll continue to expand our support for syntax highlighting preferences in the Web IDE. We’ll also be working on expanding the dark theme to the rest of the Web IDE, including the file tree and sidebars.

Enable Git delta islands core

Enable Git delta islands core

Depending on the structure of a Git repository’s packfile on disk, cloning can be CPU- and memory-intensive because Git may need to build and compress a packfile on the fly. Extreme CPU and memory use can occur when a large repository is cloned many times simultaneously, for example during a parallelized CI pipeline. However, if you trigger packfile reuse, instead of constructing the response on the fly, Git streams the packfile directly from disk, eliminating most CPU and memory usage of the clone.

In GitLab 12.8, when repacking repositories, a delta island core is created that contains all the reachable branches and tags so that packfile reuse is triggered when cloning a Git repository. GitLab performs repacks automatically for active repositories, but they can also be triggered manually by clicking Run Housekeeping in the projects General Settings. Note, when using a shallow clone strategy for CI, packfile reuse will not be triggered.

Faster repository browser

Faster repository browser

Exploring the source code of a project you’ve just discovered, or a project which you contribute to is now faster. In GitLab 12.8, when browsing between directories, the file list and commit data are updated without reloading the entire page, which eliminates unnecessary page loads.

Merge Request changes are loaded progressively

Merge Request changes are loaded progressively

Merge Requests, particularly the Changes tab, is where source code is reviewed and discussed. Previously, as proposed changes became larger, the diff would load slowly and couldn’t be read until fully loaded.

In GitLab 12.8, the file changes list loads immediately, and the diffs are loaded progressively so that you can begin reading the diff almost immediately rather than waiting for the page to load fully.

Smarter Git packfile reuse

Smarter Git packfile reuse

In GitLab 12.8, we are including a patched version of Git 2.24 in GitLab Omnibus with improvements to Git packfile reuse.

When a client fetches or clones, it is more efficient for the server to respond by reusing existing packfiles as much as possible. The improvements implement a new smarter algorithm for reusing packfiles that makes a better compromise between the cost to serve a clone or a fetch, and the quality of the resulting packfile.

Thank you Peff and GitHub for sharing this improvement, and Jonathan Tan (Google) for your help reviewing! We hope the patches land in Git 2.26.

Allow-failure action is now available in new rules syntax

Allow-failure action is now available in new rules syntax

Expanding on our new rules syntax, it is now possible to define pipeline rules that are allowed to fail. This gives users more flexibility when setting up their job behaviors and makes it easier to migrate additional projects to our new, more human-readable syntax.

Extended log length in pipeline failure emails

Extended log length in pipeline failure emails

The length of the log in pipeline failure emails has been increased from 10 to 30 rows, making it easier to see more of the trace and more likely that the complete error message is included in the email.

Thanks to Philipp Hasper for the contribution!

Jobs in Directed Acyclic Graph (DAG) pipelines can be set up with no predecessors

Jobs in Directed Acyclic Graph (DAG) pipelines can be set up with no predecessors

Specifying an empty needs: array can be used to indicate to GitLab that there is no predecessor for that job and that it can always start immediately, regardless of what stage it is in. You can use this to set up more flexible relationships in a DAG pipeline, speeding them up and making them more efficient.

GitLab NPM Registry to support NPM distribution tags

GitLab NPM Registry to support NPM distribution tags

To verify that their NPM package was uploaded or to look up the correct version of a package, users would like to use package metadata. NPM tags can be used to provide an alias instead of version numbers, making it easier to discover packages. For example, a project might choose to have multiple streams of development and use a different tag for each stream, such as stable, beta, dev, or canary.

In GitLab 12.8, we are excited to announce that we now support NPM distribution tags in the GitLab NPM Registry. You can now add, remove, and list tags associated with any package hosted in their registry, making it both faster and easier to find and discover packages.

Improved performance for the GitLab Container Registry garbage collection algorithm for S3

Improved performance for the GitLab Container Registry garbage collection algorithm for S3

For organizations building many images across many projects, it is important to remove old, unused images and tags. The container registry garbage collection takes a long time to run and consumes resources inefficiently during the process. This makes it difficult for instances with large registries to run garbage collection and results in an increased cost of storage.

In GitLab 12.8, we are excited to announce a significant improvement in the performance of garbage collection for instances using S3 for storage. These improvements optimize both the mark and sweep phase of the algorithm. While testing on 15 thousand images, the mark phase went from 25 minutes to 90 seconds! The sweep phase went from 20 minutes to 3 seconds! Read more on performance tests and benchmark optimization in the merge request.

Leverage policies to remove Docker images

Leverage policies to remove Docker images

You build many Docker images as part of your pipelines, however, many of these images are only needed for a short time. Until now, you’ve had to rely on removing images via the Container Registry API or using the user interface. Both require effort. Wouldn’t it be great to define a policy and have those unwanted tags removed automatically?

In 12.8, we are excited to introduce Docker tag expiration policies for all new projects. This new feature allows you to identify a tag by name, select how many versions of the tag to keep, and define when it should be removed. For example, you can set up a policy that will remove all tag names that match a regex like the Git SHA, always keep at least five images, and remove any image that is older than 30 days.

Collect Release Evidence at Release end date

Collect Release Evidence at Release end date

When users first create a Release entry, a snapshot of the metadata is taken for Evidence in the event of an audit. As of 12.8, we automatically take an additional snapshot of the Release Evidence at the Release end date. By providing a second snapshot, it becomes possible to compare the start state of a Release with its end state. This gives audit teams better visibility into what changed between these two points in time.

Documentation for using earlier Knative Versions

Documentation for using earlier Knative Versions

As Knative approaches version 1.0, many GitLab users need to build older versions of Knative as many kinks in the Knative upgrade process have not yet been ironed out. A problem arises because new versions of gitlabktl only support a specific version of Knative because of API changes. Because GitLab Serverless is in alpha, we’ve chosen not to support backward compatibility. As we shipped updates, each version of gitlabktl has only supported a specific version of Knative. While this strategy keeps development simple and lets us iterate quickly, it has made it painful to update GitLab, because we were forced to update Knative as well.

The solution to this problem is to use a pinned version of gitlabktl. While this has always been possible, it hasn’t been easy to figure out. We’ve now added a clear set of instructions to our docs to aid in discoverability and execution.

Install more Kubernetes applications using CI/CD templates

Install more Kubernetes applications using CI/CD templates

Installing Kubernetes applications using GitLab CI/CD provides a great way to customize applications before installation.

In GitLab 12.8, new templates are available for installing JupyterHub and the Elastic Stack using GitLab CI/CD. Installing applications via GitLab CI/CD will additionally enable version control and access control to the installed charts.

Automatically close issues when the related Sentry error resolves

Automatically close issues when the related Sentry error resolves

Managing errors in your application is tough enough without needing to also remember to close the GitLab issue after fixing the error. GitLab issues now close automatically after the related Sentry error is resolved. It eliminates the extra manual work and prevents confusion over which issues are still active.

Duplicate a dashboard including custom metrics

Duplicate a dashboard including custom metrics

Previously, duplication of dashboards included only default metrics. With this new enhancement in 12.8, custom metrics are now included when cloning a default dashboard with both custom and default metrics.

Navigate from metrics chart to logs

Navigate from metrics chart to logs

When troubleshooting an incident, reviewing both logs and metrics is important. When viewing a metric chart, you can now drill down directly into the log explorer while preserving context and without ever leaving the GitLab console.

Searchable environment in metrics dashboards

Searchable environment in metrics dashboards

Searching for a specific environment could get cumbersome when you have many of them. You can now quickly find the environments you want to see in the metrics dashboard with the new search bar in the dropdown menu.

Geo moves towards a self-service developer framework

Geo moves towards a self-service developer framework

Geo helps distributed teams by replicating data to local Geo nodes, and is also used for disaster recovery. Today, some of GitLab’s features are not yet supported by Geo. We want all upcoming features to ship with Geo support out of the box. To accomplish this, we are moving towards a developer framework, which will make it easier for developers in the GitLab community to contribute new data types that need to be replicated and verified.

This is valuable, because it standardizes the technical processes used in Geo to extend Geo to other parts of GitLab, and it will give the GitLab developer community a solid technical foundation to contribute future features and improvements to Geo. Effectively, future development work will be faster and more efficient.

In this release, we have merged a significant first iteration for package files that establishes the technical foundations of this work. In the next iteration, we will add support for package file replication and verification.

PostgreSQL 11 is now available in Omnibus GitLab

PostgreSQL 11 is now available in Omnibus GitLab

The Omnibus GitLab package now includes PostgreSQL 11. The PostgreSQL 11 release includes enhancements to partitioning and other performance improvements that we will be building upon in GitLab 13.x to increase its overall speed and responsiveness. PostgreSQL 11 has been fully tested with Omnibus GitLab for new installs and upgrades, including HA configurations. Testing with Geo is in progress.

Upgrades to PostgreSQL 11 are opt-in for GitLab 12.8. For instructions on upgrading, see the upgrade notes. New installs, and automatic upgrades from 9.6, will still default to PostgreSQL 10. PostgreSQL 11 will become opt-out in GitLab 12.10 and the minimum required PostgreSQL version in GitLab 13.0. For more details about GitLab’s PostgreSQL 11 roadmap, see the epic for adding support for PostgreSQL 11.

We encourage administrators of instances not using Geo to upgrade to PostgreSQL 11 at their earliest convenience to benefit from performance improvements and to prepare for the removal of PostgreSQL 9.6 and 10.x in GitLab 13.0.

Bug fixes

Bug fixes

Some of the notable bug fixes in GitLab 12.8 are:

• Handling LFS objects for fork networks
• Initialization order issue with the Geo database

Rapidly updated vulnerability database

Rapidly updated vulnerability database

We keep updating our vulnerability database with the latest vulnerabilities. This ensures that GitLab’s scanners are always scanning for the latest vulnerabilities, protecting you and your applications.

In February 2020, we’ve added known vulnerabilities to our database on average within 2.2 days of their announcement. You can see the latest status of our vulnerability updates in the Handbook.

Disable self-approval at the instance level

Disable self-approval at the instance level

We’ve introduced new instance-level settings to prevent unwanted changes to merge request approval settings by bringing some of the merge request approval settings from the project settings into the Admin Area. This will give administrators better control of their deployments and allow them to maintain separation of duties when deploying code.

By enabling these settings at the instance level, all projects in a self-managed instance are forced to adopt these settings, and only administrators can change them for an individual project. This new enforcement capability ensures only approved deployments make it into production and brings your GitLab projects into a more compliant state.

Change the name of the Service Desk user

Change the name of the Service Desk user

Emails sent from your Service Desk on GitLab.com come from the GitLab Support Bot by default. Many times, the originator of the issue does not know that they are emailing GitLab, which makes it confusing.

It’s now possible to configure the name for your Service Desk user! This allows you the opportunity to give your users a recognizable name that matches your brand!

Drag-and-drop Design badges

Drag-and-drop Design badges

When viewing a design inside the Design tab of an issue, you can drop comment badges on any area of the image and attach a comment. This is great for having point-of-interest discussions. However, as feedback is given and you upload new revisions, sometimes you need to move the badge to a new spot. This release lets you drag badges around. Now you can:

• Drag the comment badge around after you drop it.
• Move someone else’s badge over to fit yours.
• Move the badges to match a new Design after you make a layout revision.

Enable Git protocol v2 for HTTP

Enable Git protocol v2 for HTTP

We’ve re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.

Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.

Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data.

Git protocol v2 is supported from Git 2.18.0 and is opt-in. To enable it, run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled. Follow this issue for updates.

Merge Request Approval Rules for Protected Branches

Merge Request Approval Rules for Protected Branches

Code review is an essential practice of every successful project, and Approval Rules can be used to make sure the right people review each change. When practicing continuous delivery or working on higher risk projects, this is especially important. Previously, adding more restrictive approval requirements to protect the default branch would impose the same requirements on every branch. This forced all merge requests to meet the same approval requirements, whether it be merging a bug fix from master into a release branch, or between two feature branches.

GitLab 12.8 resolves this problem: Approval Rules for Merge Requests set at the project level can be required selectively based on the target branch of the merge request. This allows restrictive approval rules to apply exactly when needed, and even different approval rules to apply to different branches like for stable release branches.

S/MIME Signature Verification of Commits

S/MIME Signature Verification of Commits

Every commit in a Git repository has an author, but this is not verified by Git and means that it is easy to create commits that appear to be authored by someone else. Commit signing allows you to prove that you are the author of the commit. This is important for sensitive projects and in some commercial environments.

In Git 2.19, OpenGPG signing and verification support was extended to include support for S/MIME using X.509 certificates, because managing these certificates is more friendly for large organizations.

GitLab now also supports S/MIME Signature Verification of commits, thanks to Roger Meier from Siemens! Further thanks go to Henning Schild, also from Siemens, for contributing this feature to Git in the first place!

Tab width user preference

Tab width user preference

Tabs, in contrast to spaces, are more than a matter of preference for some. For those who use tabs, the correct tab width is no trifling matter. Particularly for C and Go projects, where tabs are most common, it is important that tab width can be configured to match local preferences for the best code review.

GitLab now provides a Tab width user preference, used when viewing code including diffs, CI logs, and rendered code blocks in Markdown.

Thank you Alexander Oleynikov for your contribution!

Automatically bring in artifacts from cross-project jobs

Automatically bring in artifacts from cross-project jobs

You can now specify that a job in a project depends on the latest artifact produced by a job in another pipeline, making it much easier to set up cross-project pipelines that have artifact dependencies on each other.

As an example, you might have a pipeline that builds an executable binary. Before this update, you had to rebuild all of the libraries the binary depended on every time you built the binary, even if the library didn’t change. This was a waste of time and computing power, and the workarounds required using a brittle mix of API keys, cURL, and secure variables. Now, by specifying artifacts: true on your needs: job, you can pull the artifact generated by the library pipeline and use it in your final executable pipeline without the need to rebuild.

GitLab Runner 12.8

GitLab Runner 12.8

Welcome to the 12.8 release of GitLab Runner. GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Key highlights include:

• Kubernetes executor should expose services via HostAliases
• Bump Go version to 1.13.7
• Add support for X-GitLab-Trace-Update-Interval header
• Support rate-limiting headers from GitLab API

You can find the full list of changes in GitLab Runner’s changelog.

Clean up corrupted Docker manifests during garbage collection

Clean up corrupted Docker manifests during garbage collection

When running garbage collection to remove old, unused images, users have frequently run into an issue in which the process fails due to corrupted Docker manifests. To resolve this issue, administrators have had to manually remove the corrupted files from object storage, which is slow and risky.

In 12.8, we are excited to announce that any corrupted manifests will now be deleted as part of the garbage collection process. If a bad link file (zero bytes in size or with an invalid checksum) is found during garbage collection, instead of stopping the garbage collector, it will log a warning message and ignore it. Blobs related with invalid link files will be deleted in the sweep stage if those blobs are not associated with another valid link file. This update makes the garbage collection process more reliable and efficient.

GitLab metadata is now available in the Package Registry user interface

GitLab metadata is now available in the Package Registry user interface

We learned from a recent round of user research that users navigate to the Package Registry UI to verify which version of a package they should use or verify that their pipeline built it correctly. However, since we did not display any information in the user interface about how a package was built, users were forced to navigate between several different areas of the application.

In GitLab 12.8, we are excited to announce that packages built via GitLab pipelines will now include pipeline_id, branch, and commit in the Package Registry user interface. This will help users understand how a package was built and troubleshoot much easier when something goes wrong!

Improved performance of the delete API for the Container Registry frontend

Improved performance of the delete API for the Container Registry frontend

The GitLab Container Registry user interface allows you to view, discover and manage your project’s images. The problem is that deleting a tag has been the worst-performing action on GitLab.com, with some requests taking up to 60 seconds to complete. This has resulted in slow page load times and an increased number of support requests.

In GitLab 12.8, we are excited to announce that we have improved the performance of this function by ~70%. This will improve page load times and reliability.

Resolve Docker garbage collection issues for GitLab Container Registries hosted on DigitalOcean S3

Resolve Docker garbage collection issues for GitLab Container Registries hosted on DigitalOcean S3

There is a known Docker issue where Ceph-based storage for all requests with absolute URI impacts the Docker garbage collection process. Since DigitalOcean uses Ceph, it prevents users from running garbage collection if they are using DigitalOcean for storage. This results in higher storage costs for those users.

In GitLab 12.8, we resolved this issue by updating the driver for Ceph to support the latest version of the API. This allows any organization using DigitalOcean for storage for their GitLab Container Registry to run garbage collection and lower their cost of storage.

Display Kubernetes namespace on the job page

Display Kubernetes namespace on the job page

When a CI/CD job deploys to a Kubernetes environment, the job detail page will now display the Kubernetes namespace used for that deployment. You can use the detail page to verify workloads are deployed to the correct destination.

Enable Review Apps via a code snippet

Enable Review Apps via a code snippet

We want to make Review Apps easy to set up even if you already have a functioning .gitlab-ci.yml file. A new Enable Review Apps button has been added to the environments page; if you are using Kubernetes and want to enable Review Apps, this will show you the YAML snippet that needs to be added to your .gitlab-ci.yml.

Manage access to protected environments from the API

Manage access to protected environments from the API

Until now, users configuring access levels for protected environments needed to update developer and maintainer permissions through the Settings UI instead of the CLI. This wasn’t efficient for users who want to work from the command line and need to maintain the same level of environment access across groups. With this release, maintainers can save time when adding or removing access to protected environments by using the API, rather than having update permissions in the Settings UI.

Column charts for Metrics Dashboard

Column charts for Metrics Dashboard

When it comes to visualizing metrics, users often like to choose different types of visualization for different metrics. To help achieve that, we’ve added column charts as a new visualization option on your monitoring dashboard so you can display your data how you want.

GitLab self-monitoring project

GitLab self-monitoring project

GitLab administrators can now gain insights into the health of their GitLab instances, using a new base project which will be added under the “GitLab Instance Administrators” group. Created for visualizing and configuring key metrics to monitor your GitLab instance.

Scale metrics chart

Scale metrics chart

The y-axis value on the metric chart had previously always started from zero. This made it difficult for users to detect minor changes on the metric charts. Starting with version 12.8, the y-axis values will automatically scale according to the data.

Geo improved license banner

Geo improved license banner

Geo is only available at the Premium and Ultimate tier. Previously, when you tried to enable Geo in the administrator interface using a Starter or Core license, we just told you that the license was invalid - not very helpful! We now provide a clearer message stating which license you are using, which one you need to use Geo, and we also provide a link to manage your license.

We hope you give Geo a try!

Omnibus improvements

Omnibus improvements

Omnibus GitLab now includes PostgreSQL 11 as an opt-in version of PostgreSQL. See the main release post announcement for more details.

GitLab 12.8 includes Mattermost 5.19, an open source Slack-alternative. This release of Mattermost includes faster development cycles with GitLab, a Webex plugin, 1-click Mattermost install on DigitalOcean, and security updates. We recommend upgrading from earlier versions.

Project import and exports are faster and more reliable

Project import and exports are faster and more reliable

GitLab 12.8 includes significant improvements to how projects are imported and exported, resulting in much faster execution times and improved reliability.

Project exports are now four times faster to complete, with 80% reduction in memory footprint. Previously, large projects could fail to export due to exceeding the memory limitations of the export job. With the reduced footprint, these jobs are now much more likely to succeed.

Project imports are approximately 50% faster, due to a significant reduction in database calls. In the future, we plan to reduce the memory required for imports, by switching to newline-delimited JSON.

Performance improvements

Performance improvements

We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!

In GitLab 12.8 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.8 are:

• Remove N+1 from user notification settings
• Remove Gitaly calls from Todos page
• Add foreign key constraints to Epics table
• Fix blobs search API degradation
• Application limit for ES indexed field length
• Optimize issue search when sorting by due date and position
• Optimize issue search when sorting by weight

Support Go Modules in Dependency Scanning

Support Go Modules in Dependency Scanning

We are excited to add support for Go Modules as a Dependency Scanning supported language.

Although this scanner is viable, the feature is currently in alpha as the database only contains Go Module vulnerability definitions from 2019 and later. We appreciate any feedback in this epic around the age and types of Go support desired in addition to any issues you experience. It will help us continue to move this language support out of alpha.