GitLab 12.9 Release

Additional audit events

Additional audit events

Compliance-minded organizations need visibility into the actions of their users. This can help identify anomalous activity, mitigate risks, take action on certain behaviors, and document activity for regulatory compliance. We’re continuing our work on the Audit Events category, striving to capture 100% of user-driven events, to support the organizations relying on GitLab for auditability and traceability of their GitLab user activity.

GitLab 12.9 now provides audit events for the following changes made to merge request approval settings: prevent approval of merge requests by merge request author, prevent approval of merge requests by merge request committers, and number of required approvals. These events are visible under the project-level and instance-level audit events tables.

Group Export and Import is available using the API

Group Export and Import is available using the API

Migrations between GitLab instances can be challenging, especially from self-managed GitLab to GitLab.com, because organizations can have their work organized in many Projects and Groups. Until now, these migrations had to be done by exporting and importing one Project at a time.

With the release of the Group Export/Import MVC, users can export an entire Group and easily import it into the desired instance of GitLab, whether their destination is GitLab.com or another self-managed GitLab instance.

View history of changes to issue, merge request and epic descriptions

View history of changes to issue, merge request and epic descriptions

The descriptions of issues, merge requests, and epics can be freely edited as they naturally evolve. In the past, changes were not recorded and the history of these descriptions was lost. Not any more! GitLab now stores these updates, and allows you to view what changes were made, who made them, and when!

Drag-and-drop support for uploading Designs

Drag-and-drop support for uploading Designs

Up until this release, the only way to upload Designs to GitLab was to click and use the file uploader. This worked but is not as efficient as using drag-and-drop. With this release you can now do the following in the Designs tab:

• Upload a new Design by dragging a new file and dropping into the dropzone.
• Upload a new version of an existing Design by dragging a new file with the same name and dropping into the existing Design.

GitLab hosted CodeSandbox for Client-Side Live Preview

GitLab hosted CodeSandbox for Client-Side Live Preview

In GitLab 11.2 we released live preview powered by CodeSandbox to allow you to preview simple Javascript apps and static sites in the Web IDE. This feature depends on scripts hosted by CodeSandbox, but due to security concerns around sending private code to a third party, some customers were not comfortable using this feature.

GitLab.com is now hosting the required package to enable live preview in the Web IDE. This is the first step in enabling this feature across self-managed instances of GitLab. In a future release, we’ll provide a configuration option for self-managed instances to host the required libraries themselves, and we’ll also look into enabling it by default for all GitLab instances.

Reduce email notifications for eligible approvers

Reduce email notifications for eligible approvers

Email notifications allow you to keep up with issues and merge requests you’re interested in from your inbox. GitLab provides various levels of notifications, including Participate, which notifies you of activity after you’ve participated in the merge request or issue. However, people who have been configured as eligible Merge Request Approvers, would receive notifications for all activity on every merge request for which they are an eligible approver. This made the number of email notifications overwhelming for all but the smallest projects.

From GitLab 12.9, eligible approvers are no longer treated as participants until they leave comments, or approve the merge request. This will reduce the volume of emails being sent to eligible approvers, so they can focus on the notifications that matter. If you want to receive more emails, the Watch setting will notify you of any activity on the project.

White syntax highlighting theme for Web IDE

White syntax highlighting theme for Web IDE

Users have strong preferences for consistency in the tools they use which is why GitLab has long supported alternative syntax highlighting themes. The white theme is the most popular across GitLab, however, our code editor areas have been inconsistent in applying a matching theme.

The Web IDE is now consistent with the White syntax highlighting preference in the repository and diff areas of GitLab. We’ll continue to expand our support for syntax highlighting preferences in the Web IDE. We’re also continuing to extend the dark theme, introduced in GitLab 12.8, to the rest of the Web IDE, including the file tree and sidebars.

Disable inheritance of defaults and variables

Disable inheritance of defaults and variables

Previously, users had the ability to set certain parameters as global defaults for all of their jobs by using the default: keyword. However, disabling these defaults for a particular job required manually overwriting each setting and was inefficient. Additionally, it wasn’t possible to prevent the inheritance of variables once they were defined as global defaults.

In GitLab 12.9, we’ve now added the ability to disable the inheritance of globally defined defaults and variables. Using the inherit: parameter, users can explicitly define what is inherited from the global defaults and more easily define a job’s behavior.

GitLab Runner 12.9

GitLab Runner 12.9

We’re releasing GitLab Runner 12.9 today! GitLab Runner is the lightweight cross-platform agent that runs your build jobs and sends the results back to a GitLab instance. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab.

Changes include:

• Create network per build to link containers together
• Fix Job marked as success when job terminates midway in Kubernetes
• Fix Error dialing backend:EOF Google Kubernetes Engine
• Allow service alias from config in Kubernetes executor
• Add support for Windows services with network per build
• Provide rpm/deb package for arm64
• Add CI_JOB_IMAGE to predefined environment variables
• Support EKS IAM Service Accounts (Web identity Providers
• Support ECS Task IAM Role for S3 based cache
• Introduced Windows Lifecycle Policy
• Add Fedora 30 to supported operating systems
• Add execution stage name in job trace
• Overwrite kubernetes resource limits and requests for build container on job level

The list of all changes can be found in GitLab Runner’s CHANGELOG.

Improved performance for the GitLab Container Registry garbage collection algorithm for Google Cloud Storage (GCS)

Improved performance for the GitLab Container Registry garbage collection algorithm for Google Cloud Storage (GCS)

Our users have expressed frustration about the long downtime that is needed to run garbage collection on old, unused images, and we’ve heard you. The improvements we’ve made to the efficiency of the cleanup code means you don’t have to make a tradeoff between two bad options: taking a long outage, or keeping around lots of unneeded files.

In GitLab 12.9, we are excited to announce a significant improvement in the performance of garbage collection for instances using the GitLab Container Registry and leveraging GCS for storage. While testing with a 1.4GiB repository, which is a rough approximation of the 10 TiB registry used on dev.gitlab.org, we observed a performance improvement of 95%.

Use npmjs.org as a default remote repository when the package is not found in the GitLab NPM Registry

Use npmjs.org as a default remote repository when the package is not found in the GitLab NPM Registry

The GitLab NPM Registry allows users to host a private NPM registry alongside their source code and pipelines. This works best if the GitLab NPM Registry is the only source of packages with the GitLab group_name scope. However, it’s common that users also publish open source packages to the global NPM registry using the same scope, often when their private packages depend on those public packages.

In GitLab 12.9, we are excited to announce that you can now use https://www.npmjs.com/ as a remote repository when the package is not found in your GitLab private registry. This feature will be auto-enabled at the instance level and can easily be disabled by navigating to the instance level CI/CD settings.

Create a Release from the UI

Create a Release from the UI

GitLab now offers users the ability to create Releases from the UI. Users are a click away from creating a tag that contains all the contents of your Release version, including Release notes, milestone associations, and links added from the API stored as assets. This addition will make things easier for release managers who are planning releases for teams straight from the Releases page, rather than going to the Tags view.

Install Crossplane application using GitLab CI/CD

Install Crossplane application using GitLab CI/CD

Installing Kubernetes applications using GitLab CI/CD provides a great way to customize GitLab Managed Applications prior to installation. As part of this release, we have added a template for installing Crossplane using GitLab CI/CD. Installing the Crossplane chart via GitLab CI/CD allows users to specify any and all Crossplane chart configuration options.

Automatically embed metrics in issue for all gitlab-configured alerts

Automatically embed metrics in issue for all gitlab-configured alerts

GitLab Incident Management can create issues automatically when the Prometheus alert is triggered. Metrics charts help to visualize what anomaly caused the alert. Previously, charts could be embedded into the issue description, but this required manually grabbing the chart URL and pasting it into the issue.

Now, as of 12.9, a chart visualization for the metric that exceeded the threshold is automatically embedded in the issue description. This visualization saves you time in a firefight. You get critical information right away, without needing to go to an external source and perform a manual setup.

Note: This new capability will only work for alerts configured from the Metrics Dashboard within GitLab. In a future iteration, we plan to enable automatic charts for all Prometheus alerts regardless of how they are set up.

Edit custom metrics from charts

Edit custom metrics from charts

With the 12.9 release, we are improving the user experience to edit a custom metric directly in the metric chart rather than navigating to the Prometheus settings to edit the metric.

Formatting of y axis in metric charts

Formatting of y axis in metric charts

To improve visualization of the units on the y-axis and surface accurate data, we have introduced support for formatting the y-axis on the metrics chart.

Support additional query variables in custom dashboards

Support additional query variables in custom dashboards

Custom dashboards can be created and configured using Prometheus queries. To allow users to create dashboard definitions that can be used across different projects, we have extended support to include additional CI variables in Prometheus queries.

View all pod logs from a single page

View all pod logs from a single page

In a cloud-native world, logs are distributed across multiple pods. Previously, users would have to select each pod separately to view its logs, which can be challenging as pods can scale up significantly. In 12.9, we have added the ability to select “all pods” to help users troubleshoot incidents or verify the status of their services in a single view, instead of choosing each pod separately.

GitLab chart improvements

GitLab chart improvements

• Bootsnap is now enabled in the Rails containers (Task Runner, Unicorn, and Sidekiq). Bootsnap optimizes and caches computations to speed up the boot time of Rails applications. We’re seeing boot times reduced by approximately 14% in this iteration, and expect another significant gain in the future. You can read more about Bootsnap in its GitHub repository.
• Puma is now available in the GitLab Helm chart (Unicorn sub chart) as an alternative application server to Unicorn. Puma offers approximately 40% reduced memory consumption compared to Unicorn, for similar performance. Support for Puma in the Helm install is experimental in 12.9, but it is planned to be the default application server by GitLab 13.0. For more information, see the Helm chart documentation. A huge thanks to Dmitry Chepurovskiy for playing a key role in making this happen.

Project-level code search now reliably responsive

Project-level code search now reliably responsive

Searching within a project for code is now reliably responsive, with most queries completing in under 250ms. In previous versions of GitLab, when Advanced Global Search was disabled, queries which generated a high number of results could see latencies of 10 seconds or more. This represents approximately a ten-fold improvement, improving the search experience for users.

This improvement affects both the GitLab UI as well as project blob search API.

Seat Link

Seat Link

Customers with self-managed instances should have a simple and stress-free process for adding and paying for users as they grow. Seat Link is our first step towards providing self-managed customers with more transparent, prorated charges for user growth throughout the year. Seat Link will enable GitLab to automatically charge a prorated amount each quarter for added users.

So how does it work? Seat Link sends to GitLab daily a count of all users in connected, self-managed instances, so we can automate prorated reconciliations and you never have to deal with true-ups again. Data will be sent securely through an encrypted connection.

Seat Link will send only the following information needed to automate prorated charges:

• Date
• Historical maximum user count
• Active user count
• License key

For air-gapped or closed network customers, we’ll continue with the existing true-up model. Seat Link is available in 12.9, but we will not start processing prorated charges until a future date, with a tentative target of 12.10.

For more details, see the recent blog post.

New Policies tab under License Compliance

New Policies tab under License Compliance

Previously, developers could only view license policies for newly added licenses in a merge request. With GitLab 12.9, all participants can now easily view a list of all licenses detected in a project, as well as a list of all of the License Policies that have been configured for the project. Developers will now easily be able to proactively verify if a license will be permitted in the project. This new view also allows maintainers to add or edit licenses policies from within the new tab.

Suggested solution for Container Scanning

Suggested solution for Container Scanning

When Container Scanning finds a known vulnerability for your base image, GitLab offers a suggested solution (upgrading to the next version of the vulnerable package) where applicable. Users must select Resolve with merge request and submit the merge request that is generated with the proposed solution. This helps you swiftly and efficiently respond to and resolve container-based security findings while reducing your security risk and compliance risk. Please provide feedback for desired improvements in this epic.

Updated documentation to include steps to run offline SAST for self-managed instances

Updated documentation to include steps to run offline SAST for self-managed instances

We have enhanced our documentation to better describe how to run SAST scans in a self-managed, offline GitLab environment.

This will allow you to improve your project’s security, while still being in compliance when running GitLab in an offline environment.

Customizable Value Stream analytics

Customizable Value Stream analytics

Value Stream Analytics allows teams to understand the behavior of their development process by providing key metrics related to the planning, development, review, testing and production release of their software process. Now in 12.9, GitLab users have more control over the measures used to reflect their process. For each lifecycle stage, team leads may define trigger events which define when an issue or MR is considered to have entered or exited the stage. With this new flexibility, teams will be able to reflect their own processes in GitLab with higher fidelity and make decisions about where to focus improvement activities on the basis of their team’s historical data.

Filter issue list by an Epic

Filter issue list by an Epic

You can now filter an issue list by Epics. Quickly pull up a list of issues assigned to an epic, review, and interact with them in bulk to assign additional labels or milestones.

Commit all changes in the Web IDE

Commit all changes in the Web IDE

In GitLab 12.7 we began automatically staging all changes in the Web IDE as a step towards better accessibility by more personas. This measure also helped to prevent accidental loss if all changes weren’t properly staged prior to leaving the Web IDE.

This was an important change in Web IDE workflows and now, we’ve made this even easier by removing the staging workflow completely from the Web IDE. Now when a user makes a change in the Web IDE they won’t need to decide to stage or unstage their changes for their commit. They’ll see a new Changes tab that has a list of all changed files. This is a valuable step in making git and GitLab more accessible to users in the Web IDE.

Enable Git protocol v2 for SSH

Enable Git protocol v2 for SSH

We’ve re-enabled support for Git protocol v2 over SSH. In the previous release, GitLab 12.8, we 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. 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. Now, only the needed refs are transferred.

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.

Git protocol v2 is enabled by default from Git 2.26, and available from Git 2.18 by running git config --global protocol.version 2.

HTTP push mirroring API

HTTP push mirroring API

Push mirroring allows you to automatically push updates from your Git repository to copies stored elsewhere. Mirroring is easily configured from the project settings, but if it needs to be configured for hundreds of projects this is impractical. The new Remote Mirrors API solves this by allowing push mirroring over HTTP to be configured using the API.

Thank you Rajendra Kadam for your contribution!

Special markdown rendering for Design URLs

Special markdown rendering for Design URLs

Sharing a link to the Design tab is an important part of collaboration and how users can surface Designs in comments or descriptions. Currently, when sharing a link to the Design tab in markdown, the link is long and unruly: https://gitlab.com/gitlab-org/gitlab/-/issues/12345/designs.

With this release, GitLab renders these links in a readable way so it’s easy to distinguish Designs in issue descriptions or comments: #12345 (designs). Now it’s easier for collaborators to spot when a user is referring to Designs rather than just linking out to an issue.

Zooming Designs now supports full width for long images

Zooming Designs now supports full width for long images

When a website layout is uploaded as a Design on an issue, they are often quite tall in size. This aspect ratio is frequently used for website layouts where there is a lot of content and the user has to scroll down. With this release, you will now be able to zoom in on longer designs so you can more easily see and comment on the Design at 100% width.

Full Code Quality Report

Full Code Quality Report

Users are already making great use of the code quality feature in Merge Requests to prevent code quality from slipping after making a single change, but this may not give enough insight into other issues within the project. Contributors now gain visibility into other code quality issues in order to resolve them in the current Merge Request or in a future change.

To better enable users to write high quality code, the full Code Quality report output is now available in the CI/CD pipelines and as a downloadable artifact. This change allows developers even more visibility into any code quality issues in their project within the GitLab UI.

List Changed Pages in the Visual Review widget

List Changed Pages in the Visual Review widget

It can be difficult to navigate to a changed page in a Review App, especially in a statically generated site. Review Apps and Visual Reviews make it easy to leave comments directly in a Merge Request while looking at the modified page. That is, once you find it.

Starting in GitLab 12.9, users of Visual Review tools will be able to use a drop down list to navigate directly to the page(s) modified in a Merge Request, making it easier to find the changed page(s) and provide feedback on a Merge Request.

Specify Docker images that should not be deleted as part of the Container Registry bulk delete API

Specify Docker images that should not be deleted as part of the Container Registry bulk delete API

For organizations with many groups and projects, it is more efficient to remove old, unused, Docker images by utilizing the bulk tag deletion API. However, there’s currently no easy way to express something such as “no matter what, don’t delete this tag.” This introduces risk into the deletion process since it’s possible to delete release or master images.

In 12.9, we are excited to announce that you can add the name_regex_keep attribute to the bulk delete API in order to prevent any tags that match the provided regex from being deleted. Now, you have an easier way to prevent your important images from ever being deleted!

Use the GitLab API for creating and revoking project and group deploy tokens

Use the GitLab API for creating and revoking project and group deploy tokens

Deploy tokens allow users to fetch a project repository (through SSH with git clone) or to fetch the Container Registry images of a project without providing a username and a password. This enables users to create a single token for their project and avoid using personal access tokens. However, for organizations with many groups, sub-groups, and projects, it is inefficient and difficult to create deploy tokens for each project. Maintainers or administrators need a way to easily create and revoke deploy tokens for many groups and projects.

In GitLab 12.9, we are excited to announce that we have extended the Gitlab API to allow users to create, list, and revoke GitLab Deploy Tokens at the group/sub-group/project level. This will make the process of creating and managing deploy tokens much easier and safer.

Deploy keys and Deploy tokens move to CI/CD settings

Deploy keys and Deploy tokens move to CI/CD settings

Deploy keys and Deploy tokens have found a new home under Settings > CI/CD. They were previously found under Settings > Repository and were more difficult for users to find. Since both are used for CI/CD purposes, we consolidated all settings into this location.

Track cherry-picked commits from Merge Request

Track cherry-picked commits from Merge Request

It is important to track everything that gets delivered to production. We now record when a merge commit is cherry-picked into a branch that gets deployed (when done either through the UI or through the API). The original merge request thread is updated with a system note indicating that the merge commit was cherry-picked into the deployed branch, and it is also included in the list of deployed merge requests.

Drill down from incident to log explorer

Drill down from incident to log explorer

Previously, users struggled to find relevant logs when troubleshooting incidents. Starting with 12.9, users can drill directly down from the incident to the log explorer while preserving the same timeframe, simplifying investigation of the incident and finding the root cause.

Filter error list by status

Filter error list by status

Digging through a large list of errors to find the important ones that are impacting users can be a challenge when there is a low signal to noise ratio. You can now filter the list view of Sentry errors in GitLab by error status (ignored, resolved, or unresolved) to remove the cruft and focus on the problems you actually need to fix.

Log aggregation in Core

Log aggregation in Core

As a part of our 2020 gift, we’ve decided to move the log aggregation capabilities in the monitor stage from GitLab Ultimate to GitLab Core. This means that starting with GitLab 12.9, all users will be able to view their Kubernetes based application logs within the GitLab UI.

Support pagination in log explorer

Support pagination in log explorer

Previously, the Log explorer would show only 500 lines on the console - limiting a user’s ability to view logs when triaging an incident. With the support for pagination, users can select any time frame they like and scroll infinitely to view an unlimited amount of log lines.

Fixes for Geo database timeouts when finding unsynced Git LFS objects

Fixes for Geo database timeouts when finding unsynced Git LFS objects

Geo compares the tracking database to the read-only secondary database to determine what needs to be synced. The existing design has been iterated on and optimized, and we keep improving it further. If Geo’s database queries time out, data can’t be replicated successfully. In GitLab 12.9, we use a new approach to sync Git LFS files which eliminates the possibility of database statement timeouts. This design will be rolled out to other data types after we have validated the solution.

In addition, this sets the stage to allow Geo to remove its dependency on Foreign Data Wrappers, which was added for improved performance, but makes Geo more complex and harder to maintain.

Omnibus improvements

Omnibus improvements

• Upgrading PostgreSQL on Geo secondaries just got easier. pg-upgrade now supports upgrading PostgreSQL on Geo tracking database nodes. Previously, upgrading the Geo tracking database required the postgresql['enable'] setting to be temporarily set to true in thegitlab.rb file. Now, simply run the pg-upgrade command on the tracking database node.
• It is now possible to provide a default statement timeout when using an external PostgreSQL database. Previously this could only be set when using the bundled PostgreSQL database. The statement timeout is used to automatically kill queries that run for longer than the specified time. For details on configuring the timeout, see the database settings page
• GitLab 12.9 includes Mattermost 5.20, an open source Slack-alternative whose newest release includes a new mobile editor, desktop dark theme, and much more. This version also includes security updates. Upgrading from earlier versions is recommended.

We detected an issue where some additional changes need to be made to the configuration of the Geo tracking database after running pg-upgrade. A fix is planned for 12.10. For 12.9, we recommend using the old method of changing the gitlab.rb file.

Reduced memory consumption of GitLab with Puma

Reduced memory consumption of GitLab with Puma

GitLab is switching application servers from Unicorn to Puma, reducing the memory footprint of GitLab by 40%. This improved efficiency can allow GitLab administrators to leverage smaller memory instances, reducing the operational costs of the service. These savings are achieved due to leveraging the multi-threading support in Puma, compared to the single-threaded model of Unicorn.

Puma support is generally available in Omnibus, and experimental in the Helm chart. We plan to make Puma the default application server in GitLab 13.0.

Flag outdated security reports in the Merge Request

Flag outdated security reports in the Merge Request

Previously, it was impossible to tell from the merge request view whether the security report for the branch was out of date. This was only solvable by manually comparing the security report in the merge request to the security report on the master branch. The merge request will now show that the security report for the selected branch is outdated if the source branch is behind the target branch in commits. Guidance is offered to bring it up to date.

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.9 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.9 are:

• Ensure RepositoryLinkFilter handles Gitaly failures gracefully
• Search issues in GraphQl by milestone and assignees
• Bulk lazy loader for epic aggregates
• Fix N+1 in Group milestone view
• Set upper limit on bulk API request size for Elasticsearch indexing
• Project-level code search now 10x faster when there is a large number of results
• Buffer Writes to ElasticSearch and use the Bulk API
• Batch load records from the database for Elasticsearch incremental bulk updates
• Request Inline or Parallel diffs instead of fetching all data from the backend in one request
• Introduce BulkInsertSafe mixin for safe bulk-inserts
• Bulk insert for Import with 14-19% reduction in time
• Streaming serializer on Export with constant memory consumption

Support SAST in networks with a custom Certificate Authority

Support SAST in networks with a custom Certificate Authority

GitLab instances can now leverage SAST scans on environments with custom Certificate Authorities. This allows advanced network configurations such as leveraging self-signed certificates or custom Certification Authorities to enable use cases like HTTPS traffic observation and monitoring.