Apr 22, 2020 - Farnoosh Seifoddini  

GitLab 12.10 released with Requirements Management and Autoscaling CI on AWS Fargate

GitLab 12.10 released with Requirements Management, Autoscaling CI on AWS Fargate, Issue and Epic health status, and much more!

GitLab 12.10 now helps teams streamline and improve compliance with requirements management, reduce cycle time and accelerate software delivery with CI with auto-scaling on AWS Fargate, and more efficiently manage a portfolio of projects with issue and epic health status.

Compliance is easier

Compliance is a common challenge in most large organizations, where teams and projects need to demonstrate they followed the organization’s processes and procedures, and delivered what was actually "required". Did the project actually address the business requirements is a common question, and with 12.10, we’re starting to deliver requirements management as a distinct category in GitLab to help teams define, track, and manage business requirements. Also, demonstrating project and release compliance just got a little easier in GitLab 12.10, as there's no longer a need to use scripts to compare release evidence over time, helping teams document and prove that the project is in "compliance". The new project compliance framework label makes it easy for organizations to indicate that a specific project is required to comply with specific compliance frameworks. Speaking of compliance frameworks, to help projects that are subject to HIPAA audits and compliance, the new HIPAA audit protocol project template gives them a head start. It's also easier to protect your secrets with improved HashiCorp Vault Integration, which helps keep your projects compliant with your security policies.

Reduce Cycle Time and Accelerate Delivery on AWS

The last thing you need is another bottleneck that potentially slows down delivery and that’s why we’ve supported autoscaling GitLab CI runners for a very, very long time. In GitLab 12.10, we’re extending our autoscaling ability on AWS Fargate to auto-scale runners so pipelines can efficiently scale to meet demand. Speaking of AWS, it's now faster and easier to configure your application to deploy to AWS with predefined AWS deployment variables, where GitLab has added AWS deployment variables and also helps with format validation.

Efficiently manage projects

Managing multiple projects and associated issues can be hard to juggle. With all the information there is to track, it's hard to know where there might be problems. Now in GitLab 12.10, it’s easy for teams to track and share the health status of issues so that it’s simple to visualize the overall health of the epic. Additionally, we’re making it easier to import issues from Jira into GitLab so that teams can spend less time switching between tools and more time focused on building great software.

And much much more!

There’s never enough space to highlight all the great features in our releases. Here’s a few other cool features that you should check out: Python PyPI repository and View Issue and MR activity- newest first.

Provide feedback on this release post Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Dmitry Chepurovskiy

Dmitry has made a major contribution adding the Puma web server to the GitLab unicorn Helm chart (soon to be the webservice chart). This work provides users of the GitLab Helm chart with the option to use Puma instead of Unicorn. In testing, we have observed a 40% reduction in memory usage when using Puma as the web server. Dmitry, we appreciate your awesome collaboration and enormous contribution to add Puma to our cloud native installation.

Check out the epic, and get started today! Thank you, Dmitry, for your contribution and hard work.

Key improvements released in GitLab 12.10

Create and view requirements in GitLab

The first step towards managing requirements from within GitLab is here! This initial release allows users to create and view requirements at a project level.

We often hear about the struggles associated with external requirement management tools - difficult integrations, multiple toolchains, and challenging workflows. We believe in the power of a single application, by offering an opportunity to keep all requirements, designs, code, and tests in a single environment. As Requirements Management evolves in GitLab, stay tuned for support for traceability between all artifacts, creating a seamless workflow to visually demonstrate completeness and compliance.

For more information and to collaborate with us on the amazing Requirements Management system, see Requirements Management Category Direction.

Retrieve CI/CD secrets from HashiCorp Vault

In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of HashiCorp’s JWT authentication method rather than manually having to provide secrets as a variable in GitLab.

Retrieve CI/CD secrets from HashiCorp Vault

Epic and Issue Health Tracking

Managing multiple epics across multiple groups and projects is difficult. To help users track projects and in-flight work GitLab now enables you to report on and quickly respond to the health of individual issues and epics by showing a red, amber, or green health status on your Epic Tree. Assign an issue a health status of On track (green), Needs attention (amber), or At risk (red) and see an aggregate report of health at the Epic level. Quickly view and analyze where a collection of work is at risk so you can open up the right discussions at the right time and keep work on track!

Epic and Issue Health Tracking

Import Issues from Jira to GitLab

Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility. GitLab 12.10 includes an MVC to automatically import your Jira issues into GitLab. This is the first of many planned enhancements to make transitioning from Jira to GitLab as frictionless as possible.

To get started, set up the Jira integration on your GitLab project, click the import icon at the top of your project’s Issue List, and select Import From Jira.

Import Issues from Jira to GitLab

Autoscaling GitLab CI jobs on AWS Fargate

GitLab Runner autoscaling responds to CI job demand by provisioning new cloud-hosted virtual machines. However, while this model of automatically spinning virtual machine instances up and down continues to be sufficient for specific use cases, customers also want to take advantage of the capabilities of cloud container orchestration solutions for executing GitLab CI/CD jobs. You can now auto-scale GitLab CI on AWS Fargate with the MVC release of GitLab’s AWS Fargate Driver. With this new autoscaling pattern, GitLab’s AWS Fargate driver automatically runs each build in a separate and isolated container on Amazon’s Elastic Container Service (ECS) using a user-defined container image.

Autoscaling GitLab CI jobs on AWS Fargate

Easy to configure AWS deployment variables

When deploying to AWS, applying the necessary environment variables should be as convenient as possible. You can now select the predefined variables for ‘AWS_ACCESS_KEY_ID’, ‘AWS_SECRET_ACCESS_KEY’ and ‘AWS_DEFAULT_REGION’ from the environment variable key list. You’ll also see the variables you enter validated to ensure they are entered in a valid format.

Easy to configure AWS deployment variables

Release and build managers are often in charge of wrangling several activities outside of GitLab in order to effectively deliver a release. GitLab is working to make the Release page a single source of truth for everything regarding your releases. We’ve added the ability to link runbooks to the assets of a Release so you can now track all of these related activities easily and see how far along they are.

Link runbooks and assets to a Release

Enhanced Secure workflows for use in offline environments

GitLab Secure scanners need internet connectivity to download updates and the latest signatures. GitLab 12.10 makes it substantially easier to use these scanners when running self-managed GitLab instances offline or with limited connectivity. Several adjustments to the underlying scanner job definitions support this workflow.

New documentation for offline environments describes the high-level workflow needed for Secure scanning in an offline environment. We have also added scanner-specific instructions on each scanner’s documentation page.

We will continue to add support for offline Secure scans in future releases, by offering support for additional languages, tools, and use cases.

Enhanced Secure workflows for use in offline environments

Status Page

When your service is down or degraded, your top priority is to fix it. At the same time, you must update customers and business stakeholders about the progress of your fixes. Keeping them in the dark can lead to a flood of emails from unhappy people. Users rely on status pages to confirm if providers know about problems and to learn what to do. When there’s an active incident, knowing what steps are being taken inspires confidence. It helps people to make choices about what they will do in response to the incident.

Today, the new GitLab Status Page is available. Keep users, customers, and stakeholders informed during incidents. Push information from private incidents, like issue descriptions and select comments, from a private incident issue to a public web page. Work directly from the incident issue you are already using for triage and firefighting, instead of bouncing between a lot of different tools.

To begin with, we are targeting one narrow use case. We designed Status Page to publish information from issues in a dedicated incident management project on a private GitLab instance out to public status detail pages. Visit the Status Page Direction to see our plans to add capabilities and support more use cases.

Status Page

Build, publish, and share Python packages to the GitLab PyPI Repository

Python developers need a mechanism to create, share, and consume packages that contain compiled code and other content in projects that use these packages. PyPI, an open source project maintained by the Python Packaging Authority, is the standard for how to define, create, host, and consume Python packages.

In GitLab 12.10, we are proud to offer PyPI repositories built directly into GitLab! Developers now have an easier way to publish their projects’ Python packages. By integrating with PyPI, GitLab will provide a centralized location to store and view those packages in the same place as their source code and pipelines.

In March, we announced that the GitLab PyPI Repository and support for other package manager formats will be moved to open source. You can follow along as we work to make these features more broadly available in the epic.

Build, publish, and share Python packages to the GitLab PyPI Repository

Container Network Policies Statistics Reporting

We’re pleased to announce Container Network Policy Statistics Reporting! You can now see data on both total and blocked traffic, allowing you to more easily determine how to configure, tune, and evaluate your Network Policies.

Container Network Policy statistics will appear on a new Threat Monitoring page under the Security & Compliance menu item. By default, this data covers a 30-day period.

Container Network Policies Statistics Reporting

Web Application Firewall (WAF) Controls for Logging and Blocking Modes

To help tune rules for false positives or false negatives, you can globally set your WAF to either Logging or Blocking mode on the Operations -> Kubernetes page.

Web Application Firewall (WAF) Controls for Logging and Blocking Modes

Other improvements in GitLab 12.10

Compliance dashboard shows pipeline result for the most recent, merged MR

When an administrator or group owner assesses compliance of their GitLab projects, they need to know the status of pipelines for the code being deployed. Pipelines can contain stages or jobs that determine compliance with organizational policy. Until now, administrators or group owners had to investigate every project to validate each pipeline.

The Compliance Dashboard now includes the most recent pipeline status for all projects in a group. Administrators and group owners can now identify potential compliance issues with approved and merged MRs at a glance.

Compliance dashboard shows pipeline result for the most recent, merged MR

Extend Access Token lifetime in GitLab.com

Starting 12.10, GitLab.com customers can also limit the lifetime of personal access tokens in group-managed accounts, similar to self-managed instances of GitLab.

In the General section of your group’s settings, you can specify a lifetime duration for personal access tokens created by members of a group-managed account. This policy will only apply to users of that group.

New HIPAA audit protocol project template

With GitLab, you can automate highly repeatable HIPAA Audit Protocol workflows. GitLab can help simplify these workflows natively by leveraging issues and project templates. This process can help map new issues to each requirement in the HIPAA audit protocol. It can also help your organization manage audit evidence collection and overall status within your GitLab workflow.

GitLab now supports the HIPAA audit protocol, through the new enterprise compliance template. To aid in HIPAA compliance, GitLab can help you create new projects, each with the 180 issues that map to the HIPAA audit protocol. Each issue serves as an audit trail for each HIPAA protocol and can help teams stay connected as they manage their HIPAA compliance programs within GitLab.

View Issue and MR feed by newest activity first

Issues are one of the primary tools for collaboration within GitLab. The default order of oldest-to-newest discussions and systems notes is incredibly helpful for some use cases, such as understanding the history of a given issue. However, it is much less helpful when teams are in triage and firefighting mode, as they have to scroll all of the way to the end of the issue to see the latest updates.

Now you can reverse the default order and interact with the activity feed with the most recent items at the top. Your preferences for Issues and MRs are saved separately via local storage and are automatically applied to every Issue and MR that you view.

View Issue and MR feed by newest activity first

Design thumbnails

Designs uploaded to Issues can be quite large in file size. Loading these files can take a long time, especially if you have more than one Design in an Issue. With this release, we now automatically generate Design thumbnails and use them to speed up the load time of the Design tab. This will also enable us to improve loading times of Designs in other parts of GitLab as we continue to build out the Design Management feature.

We tested the GitLab homepage mockup which is 1222px by 5113px and was 2.6MB. With thumbnail generation, this image comes down to 0.018MB, which is a ~99.9% reduction in size!

Project template with built-in Static Site Editor

Hosting static websites with GitLab Pages is an easy and quick way to get your site up and running. Editing the content that populates your static site, however, often requires setting up complex local development environments, an understanding of the underlying project architecture, and familiarity with Markdown syntax. For some, this is a barrier to collaboration.

We’re taking our first step toward delivering a first-class editing experience for static site content that facilitates collaboration on content without requiring any prior knowledge of programming languages or even Git. GitLab now includes a new project template that creates a static website, initially supporting Middleman, pre-configured to be hosted on GitLab Pages and with content that can be edited in a new, streamlined Static Site Editor. After deploying the site, just click the “Edit this page” link visible on every page and this will launch our new editor which removes the extraneous interface and focuses entirely on the content of the page. When you’re done, one click generates a new branch and a merge request for your changes.

Tracking Wiki activity

Up to GitLab 12.9, when you contribute to the wiki content, it does not influence your activity in GitLab. With this release, you’ll see all wiki contributions on the project, group, and user activity pages. Now you can track wiki changes and wiki editors will get credit for their contributions!

Tracking Wiki activity

Automatically trigger your project when another is rebuilt

It is now possible to set up a dependency relationship on a project you depend on, such that when the default branch on that project builds successfully, a pipeline on your default branch also triggers. This relationship is set up as a subscription from the project with the dependency, making it easy to set these up even in situations where the project you depend on is managed by another group.

Easier access to Container Registry commands

The GitLab Container Registry used to show an illustration that contained easy to copy build and push commands with the correct registry URL for your project. However, once an image was added to the registry, the commands would disappear.

In 12.10, we now show these Docker commands even when the registry is not empty. This will make the onboarding process of a new user easier and will boost their familiarity with Docker commands.

Easier access to Container Registry commands

Use Deploy tokens to read and write to the GitLab Container Registry

Deploy Tokens allow you to access your group and project’s repositories and container registries. However, the defined scopes of read_repository and read_registry have not allowed you to grant push access to the GitLab Container Registry. As a result, DevOps teams have used insecure or expensive user based workarounds.

In GitLab 12.10, we are excited to announce more granular permissions for GitLab Deploy Tokens. You can now set read or write access for the Container Registry. You can create and manage Deploy Tokens from within the GitLab application or by using the API.

View Docker images in the Container Registry at the group level

When using the GitLab Container Registry, it is important to have a cross-project view of all your Docker images. Until recently, the user interface has only been available at the project level. This inefficient workflow has resulted in a lack of collaboration and sharing of Docker images amongst teams.

In 12.10, we are excited to announce that you can now view all of your group’s images within the GitLab application. Now you can share, discover and manage all of your images in one place.

Provide severity levels for dependency scanning vulnerabilities

All Dependency Scanning analyzers now support reporting severity levels, making findings more easily assessed for risk and priority. Previously, not all languages were supported by findings with severities leaving some severities set to Unknown, making it difficult to prioritize their remediation.

GitLab Pages Project Template for Gatsby

GitLab Pages natively supports the most common Static Site Generators. With GitLab 12.10, you can now make use of the latest technologies for static sites including ReactJS, Webpack, GraphQL, modern ES6+ JavaScript, as well as CSS, with our new Gatsby Project Template.

GitLab Pages Project Template for Gatsby

Merge Trains support added to /merge quick action

When merge trains are enabled, the /merge quick action now automatically adds the merge request to the merge train. In previous releases, using this quick action skipped the merge train altogether and merged requests immediately; this behavior was both unexpected and confusing.

Alerting available in GitLab Core

A critical part of monitoring and observing system and application performance is the alert you receive that tells you when something has gone wrong. Without alerting, there is no way to close the DevOps loop and efficiently respond to services where critical thresholds have been breached. These capabilities are needed by every development team and we want our Alert Management solution to be widely available to everyone that uses GitLab. As part of our 2020 gift, we’ve moved alerting in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 12.10, all users can create IT alerts from charts on the metrics dashboard, and receive alerts in GitLab via the generic REST endpoint.

Collapse unfurled charts in issues

When resolving incidents, charts embedded directly into an issue can save you time by displaying all of your information in one place instead of forcing you to bounce around between multiple locations. However, charts can become frustrating if you only want to read the text and quickly consume the information. You can now collapse and expand charts, and choose between seeing the charts or removing them from the view.

Display your metrics with bar charts

We’ve added bar charts as a new visualization option on your monitoring dashboard to help you display your metrics the way you want.

Display your metrics with bar charts

Out-of-the-box NGINX alerts for Auto Monitoring in Auto DevOps

Auto Monitoring is a feature of Auto DevOps, a predefined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications.

Auto Monitoring enables you to monitor your application’s server and response metrics right out of the box after deploying your application. Auto Monitoring uses Prometheus to display system metrics such as CPU and memory usage directly from Kubernetes, and response metrics such as HTTP error rates, latency, and throughput from the NGINX Server. While this sounds like a lot to configure, we’ve reduced the configuration required for you to see the metrics and alerting in action by adding out-of-the-box alerts for NGINX Throughput and HTTP error rate metrics that work right away after you set up Auto Monitoring for Auto DevOps.

Time range in URL for metric charts

When viewing metric charts, updating the time range now updates the URL to the chart, allowing you to share or bookmark links to specific time frames easily.

Geo improvements to the administrator interface

Systems administrators need to know the overall status of their Geo installation. This is especially important if replication errors are detected. In GitLab 12.10 we’ve added several iterative improvements to the Geo administrator interface to make it easier for systems administrators to diagnose issues with Geo and to help them understand what corrective actions they need to take, for example by identifying repositories that failed to replicate.

One of the biggest changes is the addition of a popover that displays a detailed breakdown of all synchronized, queued and failed items. Where available, there is a link to a details page, which allows systems administrators to investigate individual items.

Additionally, we’ve made a few other user experience improvements to the administrator interface:

Geo improvements to the administrator interface

GitLab chart improvements

  • The Helm Chart documentation has been updated to include command line options and documentation links specific to Helm 3, and to highlight some of the differences between Helm 2 and Helm 3. The specific changes can be viewed in the issue.
  • In GitLab 13.0, the next release of GitLab, we will be removing the ConfigMap entries for puma.rb and unicorn.rb files in favor of environment variables. Please note that if you have modified the unicorn.rb from the ConfigMap (via Helm + Kustomize) in the past, you will be impacted by this change. We are doing this to eliminate maintaining two copies of these files. Until now, the puma.rb and unicorn.rb files were static within the gitlab-webservice container and overwritten by ConfigMap items from the gitlab/unicorn chart. For details on the new environment variables, refer to the associated merge request.
  • Now that you can choose between Unicorn or Puma for your web application server, the name of the Unicorn chart will be changing from unicorn to webservice. This change will take place in GitLab 13.0. As a reminder, Puma will become the default application server in GitLab 13.0 due to the performance improvements we have seen with its multi-threading capabilities. To try out Puma in your Helm install, see the instructions in the Charts documentation.

Omnibus improvements

  • The GPG signing keys for the GitLab PackageCloud repository have expired and have been replaced with new ones. This means existing users who had already configured GitLab package repositories on their machines to be used via apt, yum or zypper, will have to fetch and add the new keys to continue installing or updating packages from the GitLab package repository. For detailed instructions, see the Package Signatures documentation. Further details are also available in Balu’s blog post.
  • GitLab 12.10 includes Mattermost 5.21, an open source Slack-alternative whose newest release includes ChatOps integration with AWS, GitLab, and CodeShip, and more. This version also includes security updates and an upgrade from earlier versions is recommended.
  • Omnibus GitLab now defaults to PostgreSQL 11 for new installs. For upgrades, it defaults to PostgreSQL 11 if HA and Geo are not configured. See PostgreSQL 11 is now the default version of PostgreSQL for GitLab Self-Managed for more details.

PostgreSQL 11 is now the default version of PostgreSQL for GitLab Self-Managed

The default version of GitLab-provided PostgreSQL is now PostgreSQL 11. For new installs, and upgrades of existing installations that do not use HA or Geo, PostgreSQL 11 will automatically be used by default. For Geo and HA installs, please see the 12.10 upgrade notes. In GitLab performance testing using the 10K user reference architecture, we found that PostgreSQL 11 was able to handle 7% more Requests Per Second compared to PostgreSQL 10, and showed 20% less CPU usage for the merge request discussions endpoint. We did not observe performance regressions when moving from PostgreSQL 10 to 11. For a more detailed performance analysis, see the performance testing issue.

Note that PostgreSQL 9.6 and PostgreSQL 10 will no longer be supported as of GitLab 13.0. You will need to upgrade your PostgreSQL version prior to upgrading to 13.0.

If you are using Geo, please keep in mind that major PostgreSQL updates cannot be performed without downtime on the Geo secondary due to the need to resynchronize the database on the secondary cluster. Specific steps for Geo are available in the Geo upgrade docs. If you are using the Helm install, you will need to manually switch to PostgreSQL for 12.10.

Reduction in Advanced Global Search index size by about 50%

Previously, scaling Advanced Global Search in GitLab to very large instances has been challenging due to the size of the Elasticsearch index required. This index was made up of search data and configurations, which were only partly utilized.

We’ve re-evaluated our usage of which content needs to be indexed, and updated the index_options for our Advanced Global Search configuration. On GitLab.com we’ve seen an almost 50% reduction for our production Elasticsearch Index. This change should make it easier to get started with Advanced Global Search and help you save on operational overhead when running Advanced Global Search in GitLab.

Switch to plain SQL for GitLab schema

GitLab 12.10 has switched from utilizing schema.rb to structure.sql for managing the database schema. Switching to plain SQL in structure.sql allows GitLab to make use of PostgreSQL-specific commands, like partitioning.

Contributors and administrators may want to be aware of the change, in the event they need to work with migrations. The change to structure.sql will be automatically performed, and no action is required.

Compliance framework labels for projects

Organizations using GitLab have company policies and industry regulations that dictate how they operate. A top-of-mind goal for many of our customers is ensuring their GitLab projects are adhering to internal company policies, which are influenced by industry regulations. Previously, there was no easy way to identify a project as one that has certain compliance requirements or additional oversight, which is a fundamental need to tracking compliance status.

Now you can label projects with specific compliance frameworks by navigating to a project’s Settings area and, in the General section, choosing from the Compliance framework dropdown menu. This feature lays a foundation to ease project compliance management in the future.

Group-level activity overview MVC

Development leaders and GitLab administrators often wish to understand how their teams are using GitLab. In this MVC you’ll see three counts on the group landing page: Merge Requests, Issues, and Users added to the group, all over the past 90 days. This feature is being released in beta.

Group-level activity overview MVC

Optional SSH key expiration date

Compliance-minded organizations need a way to control SSH credential access to their GitLab environment. SSH keys are normally configured without expiration dates. This is problematic for organizations with access management and/or credential management policies, which require an expiration date on all access credentials. With this release, GitLab supports expiration dates for SSH keys that users can set within the GitLab UI.

Optional SSH key expiration date

Caching of Git info/refs

When fetching changes from a Git repository, the server advertises a list of all the branches and tags in the repository, known as refs. In some instances, we have observed up to 75% of all requests to the GitLab web server are requests for the refs. In the best case, when all the refs are packed, this is an inexpensive operation. However, when there are unpacked refs, Git must iterate over the unpacked refs. This causes additional disk I/O, which is slow when using high latency storage like NFS.

In GitLab 12.10, info/refs are cached to improve the performance of ref advertisement and decrease the pressure on Gitaly in situations where refs are fetched very frequently. In testing this feature on GitLab.com, we observed read operations outnumber write operations 10 to 1, and saw median latency decrease by 70%. For GitLab instances using NFS for Git storage, we expect even greater improvements.

High Availability for Gitaly (beta)

Access to Git repositories is critical to developers and businesses. If an outage occurs, developers can’t push code, and deployments will be blocked. To prevent outages, GitLab can be run in a highly available (HA) configuration. The recommended approach currently uses Network File System (NFS), but this adds significant latency to every read and write operation, severely impacting the performance of GitLab.

In GitLab 12.10, Gitaly now offers beta support for high availability without using NFS. While data loss is not likely, it is not recommended for use in production environments yet. In this release, the replication queue and leader state have been moved to a PostgreSQL database. Previously, the replication queue and leader state was stored in memory in the Praefect proxy/router. This prevented configurations using multiple Praefect nodes, and could result in data loss if Praefect was restarted before the replication queue was drained.

The first version of High Availability for Gitaly is eventually consistent. It is implemented as an asynchronous replication queue, and favors availability over consistency. If an outage occurs on a primary Gitaly node before the replication queue has been drained, data loss is an expected side effect of automatic failover. Work is already underway on strong consistency to prevent such data loss scenarios.

High Availability for Gitaly (beta)

Repository file icons based on file extension

When viewing files in your repository, GitLab now displays an icon based on the file extension. Different file types use icons of different colors and shapes to help people quickly recognize files in the editor, and when browsing their computer.

This change also makes icon styling consistent between the repository view, the Web IDE, and the merge request file tree. Enjoy!

Repository file icons based on file extension

Use Copy & Paste to upload an image to the Design Tab

With the new Copy & Paste functionality, you can now paste one image from the top of your clipboard history directly into the Designs tab as a .png file. This functionality is particularly useful to quickly share screenshots from the clipboard in any issue.

Filter the Package Registry by name

GitLab’s Package Registry enables you to store a myriad of package types in a single, universal, registry. Until recently, the only way to explore your list of packages was to change the sort order. This made it difficult to find a specific package efficiently, especially if you stored many packages within your registry.

We are excited to announce that as of GitLab 12.10, you can now filter by name to find your packages quickly.

Use the GitLab API to purge blobs from the Dependency Proxy

The GitLab Dependency Proxy allows you to proxy and cache images hosted on DockerHub so they are readily available for use within GitLab CI/CD. However, up until this release, there wasn’t a way for you to purge the cache and that resulted in additional storage costs.

This is no longer the case. Now, you can use the GitLab API for purging the cache of your group’s Dependency Proxy and lower your total cost of storage.

Disable individual rules in DAST

As a black-box tool, a DAST scan doesn’t know anything about the underlying site or application architecture. This can lead to false positives that the user immediately knows aren’t exploitable vulnerabilities. An example of this is the DAST scan reporting a possible SQL injection vulnerability when there’s no SQL database in the application architecture. Because of this problem, GitLab 12.10 supports toggling specific rules on and off using the DAST_EXCLUDE_RULES variable. This allows using a comma-separated list of Vulnerability Rule IDs to be excluded from scans. When using this variable to exclude specific rules, it’s possible to better tailor a scan to the targeted app to get fewer false positives.

Compare Release Evidence over time

In 12.6, GitLab introduced a streamlined approach to collect all the necessary information to support compliance and audit efforts within the Release object. With this new feature, an evidence collection timestamp will appear alongside a link to download the evidence hash. This enables auditors to easily compare Release Evidence over time, rather than requiring a script to collect and compare each piece of evidence.

Compare Release Evidence over time

Independent ECS task creation

As part of our AWS Cloud Deploy Docker image, we’ve bundled a script you can leverage in your pipeline to streamline task creation for ECS deployments. This helps you move boilerplate code in deployment jobs and simplifies your CI/CD configuration.

Use GitLab UI to delete an environment

This feature enables users to easily administer their environments from the GitLab UI rather than API. Expanding the management of environments to the UI saves time and supports users spending their day in the GitLab frontend.

Use GitLab UI to delete an environment

Automatically embed metrics in GitLab issues for Prometheus alerts

While triaging an incident, charts help you visualize what went wrong, which can speed up investigation and resolution. In 12.9, GitLab started automatically embedding relevant charts in all incident issues that were created from GitLab-configured Prometheus alerts. We have now extended this feature to work in issues generated from all Prometheus alerts GitLab receives, whether the alerts were configured in GitLab or configured externally.

Custom metrics available in Core

Understanding system performance often starts with monitoring the metrics that convey the health and performance of the components in question. These capabilities are needed by every development team and we want our metrics solution to be widely available to everyone that uses GitLab. As part of our 2020 gift, we’ve moved custom metrics in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 12.10, all users can add and display any metric they collect using Prometheus in the GitLab UI.

Filtered search for pod logs

Logs, while ubiquitous, are only useful if the relevant logs can be found easily. In GitLab 12.10, we introduced filtered search for pod logs, enabling you to search and define filters for pod logs with a single, scalable search bar. This replaces the cumbersome combination of terminal view, filters, and a search bar, ultimately enabling you to find the relevant logs more easily.

Support custom intervals in metrics charts

Sometimes using predefined time intervals makes pinpointing a specific time period difficult. GitLab monitoring dashboards now support custom intervals, which enable you to visualize your aggregated metric data in an interval of your choosing, on top of being able to visualize with the default intervals.

Support custom intervals in metrics charts

Users statistics improved

The Users statistics page provides administrators with an overview of user accounts by role, also totals of all users, active users, and blocked users. GitLab billing is based on the number of active users. The information on this page helps you manage seat allocation and subscription costs.

Users statistics improved

Easily clean up unused LFS files

GitLab supports managing large binaries in projects via Git LFS, such as audio, video, or graphics files. These files can be removed from LFS by rewriting Git history; however, unreferenced files will still use up storage. Until now, the only way to remove these unreferenced LFS objects was to delete the entire project, which is not an option in many situations. Consequently, users may run up against storage limits, and realize that they are using a lot of storage on LFS objects they no longer want or need, without a clear path forward.

Fitting for the Spring season, we added two Rake tasks, gitlab:cleanup:orphan_lfs_file_references and gitlab:cleanup:orphan_lfs_files, that allow removing LFS files from individual projects. The Rake tasks can be run on a project-by-project basis and scheduled as needed. Happy Spring cleaning!

Geo redirects HTTP(S) requests for unsynchronized repositories to the primary node

Geo supports selective synchronization of projects, which allows systems administrators to choose a subset of data that is replicated to a secondary Geo node. Until now, users trying to access repositories on a secondary node that were not synchronized would receive an error that the project was not available. This could be because of selective synchronization or because of replication lag. This was confusing for users and disturbed their Git workflow.

In GitLab 12.10, any Git requests made via HTTP(S) to an unsynchronized secondary Geo node will be forwarded to the primary node so that users can still access the repository. This means that users won’t need to know what is or isn’t replicated - Geo will try to fulfill the request. Support for proxying SSH Git operations will be available in GitLab 13.0.

Global Search in GitLab has long been able to return code results for searches performed. However, it wasn’t clear to users where in the returned results their search query was actually matched. This meant that users had to hunt for this in the results and may have missed important results where the string may have been returned multiple times.

Now, each line that matched the search will be highlighted to provide a better indication of where in the results the search term was matched. This also matches multiple occurrences in the same file to better highlight each line that may be valuable.

Huge thanks to @terales for contributing this feature!

Highlight code results in Global Search

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

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.

Sidekiq Cluster available in Core

Sidekiq Cluster allows starting additional Sidekiq processes to run background jobs, as well as offering convenient options for selecting a particular set of job queues to be processed. These options allow for improved management of Sidekiq queues, and continued scaling for large instances.

Previously this feature was only available in the Starter tier and higher. As of GitLab 12.10, it is now available in Core. It will be enabled by default starting in GitLab 13.0.


‘user’ setting deprecated in Omnibus GitLab

The consul[user] and repmgr[user] settings are deprecated and will be removed in GitLab 13.0. Other services in GitLab use username rather than user. For consistency, the user name for Consul and repmgr will be provided using a consul[username] and repmgr[username] setting from 13.0 onwards.

Planned removal date: May 22, 2020

Auto DevOps Auto Deploy setting value deprecated

Because several APIs were removed in Kubernetes 1.16, the default value of extensions/v1beta1 for the deploymentApiVersion setting in Auto DevOps’ Auto-Deploy chart is now deprecated.

The deploymentApiVersion setting is scheduled to be changed to a new default of apps/v1 in GitLab 13.0. If you are using Kubernetes 1.9 and below, you will need to upgrade your Kubernetes cluster in order to get apps/v1 version support. For Auto DevOps GitLab requires Kubernetes 1.12+.

Planned removal date: May. 22, 2020

Auto DevOps and Secure Configuration templates are changing to rules instead of only/except

The use of only and except is discouraged in favor of rules. The rules parameter provides more verbose and expressive job execution logic that is less complex to evaluate and understand.

Auto DevOps and Secure configuration templates that use only and except will be transitioning to rules, starting in GitLab 13.0. We strongly encourage customers who have customized job templates to transition as these two configuration options cannot be used together. We have documentation available for help migrating your templates.

This change will affect the following job configuration templates:

  • Build.gitlab-ci.yml
  • Test.gitlab-ci.yml
  • Deploy.gitlab-ci.yml
  • Secure vendored .gitlab-ci.yml templates:
    • Container-scanning.gitlab-ci.yml
    • DAST.gitlab-ci.yml
    • Dependency-Scanning.gitlab-ci.yml
    • License-Management.gitlab-ci.yml
    • License-Scanning.gitlab-ci.yml
    • SAST.gitlab-ci.yml

Any customization to these templates using only and except should be transitioned to the rules syntax. There are occasional cases where the existing only and except logic cannot be matched with rules. We would love to hear more about these cases on this rules improvement issue.

Relevant Issues: - Moving Auto DevOps jobs syntax to rules - Transition to rules syntax for Secure’s vendored templates

Planned removal date: May 22, 2020

Auto DevOps’ default PostgreSQL due to change

As part of updating Auto DevOps to support Kubernetes 1.16, we added the opt-in ability for Auto DevOps to use the PostgreSQL chart version 8.2.1 in GitLab 12.9. The default PostgreSQL chart version is currently 0.7.1. In GitLab 13.0, we plan to switch the default PostgreSQL chart version from 0.7.1 to 8.2.1. To remain on the old default, you will need to explicitly set the AUTO_DEVOPS_POSTGRES_CHANNEL CI variable to 1. To migrate your existing 0.7.1 PostgreSQL database to the newer 8.2.1-based database, follow the upgrade guide in order to backup your database, install the new version of PostgreSQL, and restore your database.

Planned removal date: May 22, 2020

Backported os.Expand

In GitLab Runner 13.0 we will remove the backported os.Expand() from Go v1.10.8. This backport was needed to include a change in behavior introduced in Go v1.11. You can find more details in issue #4915.

Planned removal date: May 22, 2020

GitLab Pages disk source no longer supported in 14.0

GitLab Pages new API-based configuration will be available in 13.0 and will replace the disk source configuration. You can still use the old configuration through next year, although we recommend switching to the API-based configuration sooner rather than later, as new features will not be supported with the old configuration. In many cases, GitLab Pages will automatically switch to the API-based configuration without any action. There is nothing you need to do right now. Starting in 13.0, GitLab Pages will automatically use the new configuration source and fallback to the old one in case of errors. There will also be a way to enforce the old configuration source, but it will be removed in 14.0.

Planned removal date: May 22, 2020

GitLab Snippets content search removal in 13.0

As we continue to work towards version control for Snippets we’ll be making a change to search for Snippets in the UI and API that removes snippet content from search results. Title and Description content will be accessible via search and API.

Planned removal date: May 22, 2020.

Introducing a new ‘id’ field which will eventually replace ‘cve’ in the JSON common security report

GitLab’s current JSON common report format for security reports needs improvements, particularly as we encourage and add third-party security vendor integrations. The primary field cve property is confusing, as it does not contain CVE data, and should therefore be removed. We are introducing the id field, which is automatically calculated for GitLab scanners and is required for third-party partner scanners. The id field will eventually replace cve as a unique finding identifier. Anyone leveraging the cve property in security reports, with custom scripts or as an integrator into our Secure features, will eventually need to stop using the cve property and instead should start using the new id property. Please be aware that today id and cve are both required fields.

Planned removal date: May 22, 2020

Offset pagination limit of 50,000 for /projects endpoint

An offset-based pagination limit of 50,000 will be applied on GitLab.com, and by default on self-managed instances, to the /projects API endpoint in GitLab 13.0. Integrations which make API calls with offsets above 50,000 will need to switch to a keyset-based pagination method, which will offer significantly improved response times and reduced load on the GitLab server. Self-managed instances will be able to customize the limit to a desired value.

To provide the optimized performance, keyset-based pagination only offers ordering based on project id. Use cases which require more flexible ordering options can continue to use offset-based pagination, provided the offsets remain below the limit. If use cases require flexible ordering options with deep offsets, we recommend sorting client-side.

Planned removal date: May 22, 2020

Planned removal of ‘marked_for_deletion_at’ attribute in Projects API in GitLab 13.0

For customers using GitLab Silver, Premium or above, GitLab’s API response when listing projects currently returns an attribute named marked_for_deletion_at, which denotes the date on which a project was been marked for soft deletion. To standardize on terminology across our APIs, this attribute will be deprecated in GitLab 13.0. A new attribute named marked_for_deletion_on with the same information has already been added.

Planned removal date: May 22, 2020

Planned removal of ‘projects’ and ‘shared_projects’ attributes when requesting group details via API in GitLab 13.0

To improve performance, we limited the number of projects returned from the `groups/:id endpoint. Starting with GitLab 12.9, we limited the number of projects returned on the group details API to 100.

To further improve performance of this endpoint, we are removing the ‘projects’ and ‘shared projects’ attributes from the response when requesting details of a group via API, starting in GitLab 13.0. Users can still find this information in the same Group API, in the list a group’s projects endpoint.

Planned removal date: May. 22, 2020

Planned removal of token attribute in Runner’s details API

In GitLab 13.0 (May 2020), we are removing the token attribute from the Runners API endpoint that gets details of a runner by its ID. You can provide feedback in the related issue or your usual support channels.

Planned removal date: May 22, 2020

Puma will become the default application server

GitLab will be switching default application servers from Unicorn to Puma in 13.0. Puma is a multithreaded application server, allowing GitLab to reduce it’s memory consumption by about 40%.

As part of the GitLab 13.0 upgrade, users who have customized Unicorn settings will need to manually migrate these settings to Puma. It will also be possible to remain on Unicorn, by disabling Puma and re-enabling Unicorn until Unicorn support is removed in a future release.

Planned removal date: May 22, 2020

Redis 3 deprecation

In GitLab 12.7, the Redis version was updated to Redis 5. Redis 3 has passed end of life and will no longer be supported as of GitLab 13.0.

Planned removal date: May 22, 2020

sidekiq-cluster will become the default method of invoking Sidekiq in GitLab 13.0

In GitLab 13.0, we will be deprecating the sidekiq-cluster parameter that is used to start multiple Sidekiq processes. In GitLab 13.0, instead of manually enabling sidekiq-cluster and specifying parameters as described in Starting multiple processes, Sidekiq Cluster will be enabled by default, and a default set of parameters will be provided. If you already have Sidekiq Cluster enabled, there should be no visible change.

If you would like to start using the new method now, refer to Using Sidekiq Cluster by default.

Planned removal date: May 22, 2020

Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation.

Important notes on upgrading to GitLab 12.10

  • The GPG key used to sign the GitLab packages was changed on April 6, 2020. If you had configured the GitLab package repositories on your machines prior to that, you will need to take some manual steps to add the new key before you can install or update GitLab packages. See the Omnibus Improvements for more details.
  • PostgreSQL 11 is the default version of PostgreSQL in GitLab 12.10. All new installs of GitLab will automatically default to PostgreSQL 11. For upgrades of existing GitLab installations, the PostgreSQL version will be automatically upgraded to PostgreSQL 11 if PostgreSQL 9.6 or 10 are detected. However, major PostgreSQL upgrades on installations with High Availability and/or Geo require some manual steps. If GitLab detects that you are using repmgr or Geo, it will ask you to follow the manual upgrade instructions for HA or for Geo; we will not automatically upgrade your PostgreSQL database. For 12.10, if you prefer to upgrade your GitLab version first and upgrade PostgreSQL later, you still have the option to stay on PostgreSQL 9.6 or 10 by disabling the PostgreSQL upgrade before you upgrade GitLab (sudo touch /etc/gitlab/disable-postgresql-upgrade). Note: There is a known issue when upgrading to 12.10 when using an external PostgreSQL database rather than the Omnibus-packaged database, resulting in the need to take some manual steps. To track this bug and see the workaround refer to the related issue.

    Please note that PostgreSQL 9.6 and 10 will be removed in the next version of GitLab (13.0). This means that you will need to upgrade your PostgreSQL database to PostgreSQL 11 before you can upgrade to GitLab 13.0. We are very excited about the database performance improvements that PostgreSQL 11 will allow us to make and look forward to sharing the benefits of these improvements with you over the coming months.


Please check out the changelog to see all the named changes:


If you are setting up a new GitLab installation please see the download GitLab page.


Check out our update page.


We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans
  • Free: Free-forever features for individual users
  • Premium: Enhance team productivity and coordination
  • Ultimate: Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash free license

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Open in Web IDE View source