We continue to improve the performance of GitLab with every release for GitLab instances of every size.

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

We’re also releasing GitLab Runner 12.7 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

The ability to get a list of active services makes it easier for developers to programmatically add and edit services on their projects from the API.

A new API route is available under /projects/:id/services that provides a list of all active project services for that given project. Previously, the GitLab API included routes that allowed for creating, editing, and deleting services–but no route to get this list.

With the update to support Elasticsearch 7.x we’re also shipping version 2.0.0 of our indexer which officially provides this support. As previously mentioned , Elasticsearch 5.6.x is no longer supported for use with GitLab.

In GitLab 12.7 we’ve updated dependencies across our indexer and GitLab to support Elasticsearch 7.x alongside our existing support for Elasticsearch 6.x. This is the most requested feature for our Elasticsearch integration so we’re very excited to be including this in the release.

Triage of errors is challenging because they are noisy, and pertinent information is difficult to find. The error detail page in GitLab surfaces the most important attributes of an error. With GitLab 12.7, those details now include language and urgency , intended to help determine the root cause of the error as quickly as possible.

GitLab Pages now has a way to disable non-authorized access separate from project privacy settings, which will then require all users to log in prior to accessing the site even if the project is set to public. This setting can be enabled by a GitLab administrator via a checkbox in the Admin Settings for Pages.

GitLab comes out-of-the-box with a number of useful metrics dashboards for monitoring your application’s health. In 12.7, you can now easily duplicate one of those default dashboards in order to make slight customizations to add, for example, your application’s specific system or business metrics.

With OpenSSH switching to SHA-256 by default in 2015 , displaying a MD5 hash for SSH keys is not useful. Thanks to a community contribution, you’re now able to see the SHA-256 fingerprint for both SSH and deploy keys - and query for a user via the key’s fingerprint, thanks to the addition of this new API.

Now, when viewing a Rust project’s Cargo.toml dependency file, GitLab will detect and link packages to crates.io , so that it is easier to understand its dependencies. Previously, in GitLab 9.3 support was added for Go, Ruby, Node.js, Python, PHP, and Objective-C.

When browsing a project, looking at its dependencies is often useful, but dependencies are typically stored in machine-generated files that link to a public package registry.

GitLab 12.7 now supports configuring a commit message template for the commits created by GitLab when applying a suggested change, so to that is valid according to your commit message push rule.

Suggesting changes in merge requests makes proposing improvements easy. However, if you use a push rule to require a specific format for all commit messages, in most cases it wasn’t possible to apply the suggested change, because the commit message generated by GitLab wouldn’t match the validation pattern for the push rule.

Errors can be noisy and plentiful which makes triage processes time-consuming, because it is difficult to sort through the cruft to find the critical ones. Being able to ignore an error in the GitLab UI, gives you the ability to clear out errors that don’t need attention, so that you can easily focus on the ones that require fixing. Ignoring non-critical errors makes the error list easy to scan and triage. The Ignore button can be found on the specific detail page for the error and on the error list.

Feature Flags allow you to enable or disable a recently introduced feature in your production environment, to reduce the risk of breaking your application until the feature is fully tested. Now you can conveniently toggle flags on or off inside GitLab directly from the Feature Flag list. Previously, feature flags could only be toggled using the API.

When rolling out changes to your application, it is possible to release production changes to only a portion of your Kubernetes pods as a risk mitigation strategy. By releasing production changes gradually, error rates or performance degradation can be monitored, and if there are no problems, all pods can be updated. GitLab supports both manually triggered and timed rollouts to a Kubernetes production system using Incremental Rollouts, to support both Continuously Delivered and Continuously Deployed applications. They are already available in Auto DevOps projects. We have prepared a new guide that shows how to achieve the same result when using only GitLab CI/CD.

We have added support for an API that retrieves the list of merge requests shipped within a given deployment. This is useful for tracking when a merge request was merged to a certain environment.

This is an instance-level feature that requires administrative access and is currently available for self-managed customers only. You can follow and contribute to this issue discussing whether to enable this feature for GitLab.com users in a future release.

Administrators can now prevent users from changing their profile name to increase traceability of user actions. This additional control over identities will allow compliance-minded organizations the ability to ensure GitLab supports their internal policies for audit logging and identity verification.

In GitLab 12.7, we are excited to announce that users can now leverage the predefined environment variable, CI_JOB_TOKEN , to authenticate to their Conan Repository and easily publish and install their dependencies.

We recently launched the GitLab Conan Repository to support C/C++ developers in publishing and downloading their dependencies. However, in order to leverage GitLab CI/CD, they were forced to use their user name and password, which is inefficient and a potential security risk.

As a step further into GitLab Releases , we make your journey through an audit easier by automatically including events for creating or editing Releases, downloading artifacts, and associating or dissociating a milestone from within GitLab’s audit logs.

With GitLab 12.7, you can now install a custom version of pip in Dependency Scanning by using the DS_PIP_VERSION variable . When this is set, it will be passed down to the Dependency Scanning analyzers.

The Blame view allows you to trace the history of a file line by line, and inspect each commit. In GitLab 12.7, you can easily follow the history of a particular line, using the new button titled View blame prior to this change .

Finding precisely the issues, merge requests, and epics you want can be difficult, especially when you want to omit a subset of the results. GitLab now supports excluding results while filtering issues, merge requests, epics, and issues cards within an Issue Board using a not or an “is not” ( != ) operator.

For large instances with thousands of projects, sharing individual projects with a group quickly becomes unscalable. To make this easier, we’re introducing the ability to share a group with another group, removing the need to share individual project links with a group.

Groups can be used for organizing projects and groups of people. A typical usage pattern is to create groups for different teams, e.g. Engineering, Legal, and Operations, and share relevant projects with each group .

Parse and analyze instance activity with structured application logging CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD GitLab’s log system allows administrators to monitor and evaluate log files to better understand the state of an instance. These logs have a wide variety of use cases, including performance monitoring, analytics, and system auditing. Some logs, however, are only offered in an unstructured format — making them challenging to parse. One of these unstructured logs was application.log , which recorded application activity including project, group, and user events. In 12.7, we’ve introduced a more flexible logging system in GitLab, and introduced a JSON-formatted version of application.log in the form of application_json.log . Creating a structured version of this logfile opens up a number of interesting use cases, like ingesting into a monitoring tool for event auditing, sending these events to a visualization tool to build customized dashboards, and many more. Documentation Issue

Create an issue directly from an epic CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD No more switching through multiple tabs to create an issue and assign it to an epic! You can now create an issue directly from the Epic view. Documentation Issue

Cut and paste a Markdown table from a spreadsheet CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Incorporating tabular data into Markdown can be a tedious and labor intensive process. As of 12.7, you can now copy content from a spreadsheet and paste it directly into a Markdown editor within GitLab. Automatically converting the spreadsheet into valid Markdown syntax let’s you spend less time formatting and more time creating amazing things. Documentation Issue

Automatically stage all changes in Web IDE CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD The Web IDE in GitLab is a great tool for contributing changes to a project. However, the lack of a persistent file system can become a challenge. Situations may occur where users make changes to multiple files, but not all changes are staged and committed prior to browsing away from the Web IDE page. This could result in the loss of those changes. In order to make the Web IDE more accessible to users and prevent more cases of accidental loss, changes in the Web IDE will now be automatically staged. When a user clicks Commit, the following commit screen will give them the ability to add their commit message and select their branch instead of giving the option to stage changes. Documentation Issue

Delete a pipeline from the UI CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Previously, deleting a pipeline was only possible from the API. As of 12.7 users with owner permissions to a project can click on the new Delete button to delete a specific pipeline directly from the Pipeline Details page. This non-reversible action expires the pipeline caches and deletes all related objects (builds, logs, artifacts, and triggers). A key benefit of being able to delete a pipeline from the UI is the ability to take immediate actions to protect leaked secrets if a job in the pipeline exposes private keys in plain text. And an even more commom use case for deleting pipelines is the need to clean-up a messy CI history littered with failed pipelines resulting from CI configuration attempts or experiments; a side benefit of cleanup being assurance that undesirable pipelines are not inadvertently used again. Documentation Issue

Zoom in on your Designs when viewing them CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD When uploading a large image, like a widescreen website layout, to the Designs tab in an issue, there was difficulty in seeing the detail of the image because it was displayed in the fixed-width viewport. We now include the ability to zoom in on the Design so you can get into the details! You’ll find the zoom controls at the bottom of the image. Documentation Issue

Auto DevOps does not run unless Dockerfile or matching buildpack exists CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Auto DevOps is a great way to get started with modern DevOps practices for any project. However, until now, Auto DevOps needed to run a CI pipeline to determine compatibility with a project by checking if an existing Dockerfile or a matching buildpack exists for the project. In an effort to make it more efficient and taking advantage of the new workflow:rules feature in GitLab CI, Auto DevOps will only run if the project contains a Dockerfile or if a matching buildpack exists for the project’s language. Documentation Issue

Install Kubernetes applications using CI templates CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Installing Kubernetes applications using GitLab CI provides a great way to customize Helm charts and custom resources (CRDs) prior to installation. As part of this release we have added templates for installing Cert-Manager as well as GitLab Runner using GitLab CI. Installing the GitLab Runner helm chart via GitLab CI allows users to configure settings they previously could not, such as number of concurrent jobs or the jobs check interval. Documentation Issue

Create templates for email responses from the Service Desk CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Service Desk email responses can now be customized per your organization! Simply add template Markdown files to your repository and when the Service Desk responds to a user, the templates are used! This will allow custom branding and messaging to provide an optimal experience for customers. Documentation Issue

Geo supports replicating Design Management assets CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD GitLab Design Management allows users to upload design assets (e.g. mockups) to GitLab issues and store them in one place. GitLab Geo now supports replicating these Design Management assets to secondary nodes, ensuring that distributed teams can access them from the closest Geo node. Because Design Management assets are replicated, they can also be restored from a secondary node. We currently don’t support verification of these assets and will add support in a future release. Documentation Epic

Append user template to incoming Service Desk issues CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD The Service Desk allows new issues to be created by sending an email to a unique address. When these new Service Desk issues are created, it would be beneficial if they could be automatically assigned to a specific user, given a label or assigned to a milestone. You can now do that by creating a template to be included with all new Service Desk issues. Include any of the quick actions in the template and they will activate when the issue is created. Documentation Issue

Appearance API CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD You’re now able to adjust appearance settings of your instance - including attributes like your instance’s title, description, favicon, logo, and others - through a new API. Thank you to Fabio Huser and Siemens for the contribution! Documentation Issue

Link to GitLab commit on the Sentry error detail page CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Digging through a stack trace is cumbersome enough without also having to determine what version impacted the affected file. In GitLab 12.7, the commit that most likely caused the error is automatically surfaced on the error detail page. Being able to automatically associate the commit with the suspect error you are seeing can significantly reduce the time to resolve the error. This gives you the ability to immediately roll back the change, or fix it with a patch. Please note that in order to take advantage of this feature, you will need to name your Sentry Release objects with the SHA of the deployed commit. Documentation Issue

Improved diff highlighting for Merge Request Suggestions CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Proposing improvements to a Merge Request using a Suggested Change makes collaborating easier by applying the change and resolving the discussion with a single click. In GitLab 12.7, improved diff highlighting of suggested changes makes it obvious which words and characters have changed, so that you can apply the suggestion with confidence. Documentation Issue

Disable automatic closing of Issues from Merge Requests CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Every team has unique needs. Oftentimes, it’s necessary to keep an Issue open beyond the life-cycle of a single Merge Request or to reference an Issue in a commit without the intent of closing the Issue. Prior to this release, teams did not have a way to disable the default behavior of automatically closing an Issue by mentioning it in a Merge Request or commit. As a step towards providing teams with more granular control over this functionality, you can now disable automatic closing of Issues within your Project’s settings. Thanks Fabio Huser and the Siemens crew! Documentation Issue

Resolve Sentry errors in GitLab CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Once you’ve identified the root cause of an error, deployed the fix, and verified its success (all from within GitLab). With GitLab 12.7, it is now possible to resolve the error without switching to Sentry, just with a click of a button. The Resolve button can be found on the specific detail page for the error. Documentation Issue

Improved initial response time of /projects API endpoint CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD In GitLab 12.7, we have made stark improvements to the first page response time of the /projects API. Previously, for some parameter combinations, we were seeing response times as high as 30 seconds on GitLab.com. With these changes, the majority of responses will be within one second. Note that these improvements apply regardless of the pagination strategy used. Documentation Issue

Faster /projects API endpoint with keyset pagination CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD We have introduced a new paginaton mechanism for the /projects API endpoint. Previously, offset-based pagination was the only method available, which while providing flexible sorting and filtering options, performs increasingly poorly for each page requested. This poor performance characteristic put increasing loads on the GitLab server, and also exhibited longer and longer response times. With GitLab 12.7, we are introducing keyset-based pagination. While this method only allows for sorting based on project id , it performs significantly faster with consistently low response times regardless of which page you are requesting. Utilization of keyset pagination for queries which retrieve many pages, will both reduce the load on the GitLab server and result in faster data retrieval. In 13.0, we will implement a configurable page depth limit for offset-based pagination, defaulting to a maximum depth of 50,000 records. This limit of 50,000 will be enforced on GitLab.com in 13.0. Documentation Issue

GitLab Chart 3.0 released CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD GitLab Chart 3.0, released along with GitLab 12.7, is a new major version of the GitLab Helm chart. Due to the significant changes in this version, upgrading requires additional steps to be performed and should be done in accordance with the upgrade documentation. GitLab Chart 3.0 includes functional improvements and updates to a number of components, each of which are outlined below and linked to the GitLab Chart 3.0 epic. The GitLab Chart uses a fork of the nginx-ingress chart. GitLab Chart 3.0 pulls in changes that were made in the upstream nginx-ingress chart to ensure GitLab compatibility with Helm 2.15.0 and Helm 3.

The extensions/* and apps/beta* API versions stopped being supported in Kubernetes 1.16. Multiple upstream charts used by GitLab have been updated to stop using these API versions. GitLab chart 3.0 includes updated upstream charts: Prometheus chart 9.4.x , PostgreSQL chart 7.7.0 , and Redis chart 10.3.x (no longer forked).

and API versions stopped being supported in Kubernetes 1.16. Multiple upstream charts used by GitLab have been updated to stop using these API versions. GitLab chart 3.0 includes updated upstream charts: Prometheus chart , PostgreSQL chart , and Redis chart (no longer forked). Sidekiq deployments now use unique selectors to avoid confusion over which deployments own a set of sidekiq pods when multiple deployments are created. For important information about upgrading Sidekiq deployments, refer to the upgrade documentation. Documentation Epic