May 22, 2020 - Farnoosh Seifoddini  
13.0

GitLab 13.0 released with Gitaly Clusters, Epic Hierarchy on Roadmaps, and Auto Deploy to ECS

GitLab 13.0 released with Epic Hierarchy on Roadmaps, Auto Deploy to ECS, and much more to help you iterate quickly on a High Availability platform

Progress since GitLab 12.0

At this milestone release of 13.0, we’d like to take a moment to reflect. We’ve accomplished so much since our 12.0 release! We've put together a blog to recap GitLab 12.0 to 12.10. Three favorites from version 12 releases include: Requirements Management, Container Network Security, and Parent-child pipelines. In addition to product enhancements, we've embraced partnerships/integrations, adding integration guidelines for third-party security scanners, and have grown our professional services to help you with things like Jira and Jenkins migrations. Our new channel, Learn@GitLab makes it easy to find many new how-to videos such as Getting started with CI.

Iteration is the key to resilience

GitLab is enabling IT and business teams to adapt, respond, and thrive. Iteration is the key. To do so you must collaborate rapidly, optimize for efficiency, and automate processes to handle security and compliance while you focus on delivering business value. GitLab 13.0 can help you iterate quickly and with greater insight. At the same time, access to Git repositories is critical, and we have enhanced our Gitaly cluster for high availability Git storage to ensure there are always multiple warm replicas ready to take over if an outage occurs.

Rapidly collaborate and respond across the entire team

GitLab builds upon capabilities that help with collaborative development, reporting, organizing, and managing work. Version control is foundational to collaboration and, with 13.0, we have added version control for snippets. To manage more complex projects, 13.0 allows you to view the epic hierarchy on your roadmap, view how your epics line up with your various milestones, and add a single or multiple milestones to your releases while alerts upon closing an issue with open blockers help you focus on critical path items.

Designers are an important part of the development team. While working on one of the most popular new features, the dark themed web IDE, we learned how to pull designers in to collaborate more closely. At the same time, we moved Design Management to core recognizing users who are designing products as individual contributors.

Optimize for efficiency

As many businesses strive to be more responsive and efficient, GitLab helps streamline existing software development processes. New features aimed at efficiency include things like simplified deployment to Amazon ECS and a new consolidated list of alerts that provides a single interface aggregating IT alerts originating from multiple sources. In addition, Terraform users will rejoice. GitLab 13.0 lets you review the summary of terraform plan in Merge Requests and use GitLab as an HTTP Terraform state backend.

Trust your processes and don’t sacrifice security or compliance

GitLab helps businesses embrace security and compliance controls end-to-end in the software development lifecycle, reducing risk and freeing up resources to focus on business critical needs. Our Application Security Testing capabilities help you find and fix security vulnerabilities earlier and for these, GitLab was just named as a Niche Player in the 2020 Gartner Magic Quadrant for Application Security Testing. Since Gartner's evaluation of 12.4, we have added many new features. In 13.0 alone we've added the ability to scan REST APIs via DAST and a full commit history scan for secrets for even greater detection. More importantly, we have rearchitected the way we handle vulnerability objects. This enabled the ability to export vulnerabilities from the security dashboard and will unlock many more robust Vulnerability Management capabilities in the future.

In addition to security scanning, GitLab automates policies and, with 13.0, provides more granular control with new features such as setting a deployment freeze with the Freeze Period API to easily prevent an unintended production release during a specified period of time. To simplify audits, you can now filter search for instance-level audit events as part of a the larger epic.

Looking ahead

We are excited about our upcoming releases, particularly features that will help you:

Want to see the complete list of what’s coming out NEXT month? Our roadmap is transparent and always available for you to contribute!

Now, without further ado, check out more fabulous updates in 13.0 below!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Sashi

Sashi contributed a wide variety of improvements across several areas of GitLab during 13.0. Sashi’s work helped improve Versioned Snippets, remove errors related to the Releases tag, minimize duplicate events sent by webhooks. Sashi also improved the organization and readability of the code by ensuring that each package format has unique models for storing metadata.

Thanks for all these contributions Sashi!

Key features released in GitLab 13.0

Gitaly Cluster for high availability Git storage

GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can’t push code, and deployments are blocked.

Internally, Git repository storage is handled by Gitaly, and now Praefect too. Praefect is a new router and transaction manager we built for Gitaly to coordinate leader election and asynchronous replication. When using a Gitaly Cluster, requests for Git data are routed through one of multiple Praefect nodes to a Gitaly node. This means that there are always multiple warm replicas ready to take over if an outage occurs.

In the future we plan to support strong consistency, so that write operations succeed on multiple Gitaly nodes, before responding with a success signal, and support horizontally distributing reads so that CPU and memory resources can be better scaled.

Gitaly Cluster for high availability Git storage

Auto Deploy to ECS

Until now, there hasn’t been a simple way to deploy to Amazon Web Services. As a result, Gitlab users had to  spend a lot of time figuring out their own configuration.

In Gitlab 13.0, Auto DevOps has been extended to support deployment to AWS! Gitlab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes. Auto DevOps simplifies and accelerates delivery and cloud deployment with a complete delivery pipeline out of the box. Simply commit code and Gitlab does the rest! With the elimination of the complexities, teams can focus on the innovative aspects of software creation!

In order to enable this workflow, users need to define AWS typed environment variables: ‘AWS_ACCESS_KEY_ID’ ‘AWS_ACCOUNT_ID’ and ‘AWS_REGION’, and enable Auto DevOps. Then, your ECS deployment will be automatically built for you with a complete, automatic, delivery pipeline.


View Epic hierarchy on a Roadmap

When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. You can now quickly expand a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track!

View Epic hierarchy on a Roadmap

Versioned Snippets

Snippets are useful for sharing small bits of code and text that may not belong in the main project’s codebase. These items are important to groups and users who rely on them for other tasks, like scripts to help generate diagnostic output or setup supporting services for testing and demo environments. Unfortunately, a lack of version control has made it hard to know if a snippet was the latest version or what changes may have happened and how to reconcile those.

Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository.

This is the first step in enabling more collaboration on Snippets. In future releases we’ll introduce support for multiple files, continue to expand features and expand permissions.

Versioned Snippets

Dark Theme in the Web IDE

For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most popular for other editors and important for providing a comfortable experience. It’s also clear that GitLab users love their dark themes as a Dark Application theme for all of GitLab is the second most popular request in the GitLab Issue Tracker.

The GitLab Web IDE is now completely themed dark for users who choose the Dark syntax highlighting theme perference. This is an important step in delivering an editing experience users love and a valuable step in understanding how the GitLab UI responds to dark themes. You can read more about the design process here.

Dark Theme in the Web IDE

Standalone Vulnerability Objects

We are excited to announce the first feature release for Vulnerability Management, standalone vulnerability objects. With this release, we’ve implemented a new vulnerability object model, enabling a whole new set of capabilities that span the entire lifecycle of vulnerability management.

One of the biggest benefits is each vulnerability occurrence will now have a unique URL, meaning a vulnerability can be directly linked to, shared, referenced, and tracked as the Single Source of Truth. On this page, you can change the status of a vulnerability to Detected, Confirmed, Dismissed, or Resolved. Another benefit is vulnerability occurrences will persist across scanner runs. Previously, running scans on the same branch would overwrite any previous findings with the new results. Persisting vulnerabilities will improve tracking, visibility, and cut down on duplication of findings between runs. It also enables the future ability to report on group and project vulnerability trends over time across a broad range of variables.

Standalone Vulnerability Objects

REST API support for DAST scans

GitLab 13.0 supports DAST scans of REST APIs. This allows for full DAST security coverage of an application, not just the UI. By supporting use of an OpenAPI specification as a guide for what URLs and REST endpoints need to be scanned, DAST helps secure an application’s entire attack surface and provides more insight into the potential vulnerabilities of any running application.


SAST for .NET Framework

We’re introducing initial support for .Net Framework which will allow developers to enable SAST Security Scans on additional types of .NET projects. Like our other SAST jobs, this will use Linux GitLab Runners. We plan to expand support to GitLab Windows Runners in a future release. Since introduction in GitLab 11.0, SAST for .NET only contained support for .NET Core projects.

Supported Language Scan tool Introduced in GitLab Version
.NET Core Security Code Scan 11.0
.Net Framework Security Code Scan 13.0
SAST for .NET Framework

Review summary of `terraform plan` in Merge Requests

If you use Terraform to define your infrastructure as code, you know the pain of having to pass around the resulting changes from your terraform plan command in slack and MR comments. In GitLab 13.0, you can now see the summary of your terraform plan command in the context where it is most useful, directly in your merge request. This helps you to more quickly verify your infrastructure changes and gives you a place to collaborate with your team members on the intended effects of your infrastructure as code changes.

Users of the Terraform template provided by GitLab will see the terraform plan merge request widget without additional configuration. Users of customized CI/CD templates for Terraform can update their template to use the image and scripts in the official GitLab Terraform template.

Review summary of `terraform plan` in Merge Requests

GitLab HTTP Terraform state backend

Users of Terraform know the pain of setting up their state file (a map of your configuration to real-world resources that also keeps track of additional metadata). The process includes starting a new Terraform project and setting up a third party backend to store the state file that is reliable, secure, and outside of your git repo.

Many users wanted a simpler way to set up their state file storage without involving additional services or setups. Starting with GitLab 13.0, GitLab can be used as an HTTP backend for Terraform, eliminating the need to set up state storage separately for every new project.

The GitLab HTTP Terraform state backend allows for a seamless experience with minimal configuration, and the ability to store your state files in a location controlled by the GitLab instance. They can be accessed using Terraform’s HTTP backend, leveraging GitLab for authentication. Users can migrate to the GitLab HTTP Terraform backend easily, while also accessing it from their local terminals.

The GitLab HTTP Terraform state backend supports:

  • Multiple named state files per project
  • Locking
  • Object storage
  • Encryption at rest

It is available both for GitLab Self-Managed installations and on GitLab.com.

GitLab HTTP Terraform state backend

Exclude large files using Partial Clone

Storing large binary files in Git is normally discouraged, because every large file added will be downloaded by everyone who clones or fetches changes thereafter. This is slow, if not a complete obstruction when working from a slow or unreliable internet connection.

In GitLab 13.0, Partial Clone has been enabled for blob size filters, as well as experimentally for other filters. This allows troublesome large files to be excluded from clones and fetches. When Git encounters a missing file, it will be downloaded on demand. When cloning a project, use the --filter=blob:none or --filer=blob:limit=1m to exclude blobs completely or by file size. Note, Partial Clone requires at least Git 2.22.0.

Read more in our recent blog, How Git Partial Clone lets you fetch only the large file you need.

Exclude large files using Partial Clone

Use variables to power metric dashboards

In GitLab 13.0, you can create dashboards powered by variables, enabling you to use a single dashboard to monitor multiple services and components, rather than creating hard-coded dashboards for each service you want to monitor. Instead of the time-consuming and repetitive task of recreating similar dashboards multiple times, you can now create a single dashboard and use variables to change the data you view in it.


Reduced memory consumption of GitLab with Puma

Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-hosted instances.

Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration. See the Important notes on upgrading and GitLab chart improvements for additional details.

Reduced memory consumption of GitLab with Puma

Other improvements in GitLab 13.0

Filtered search for instance-level audit events

When you need to find a specific event, either for audit reporting or to investigate incidents, it should be easy. It shouldn’t require a lot of time to manually dig through a large data set.

Now, you can perform filtered searches on a single object, e.g., a user, group, or project in the instance-level audit events table to make this process much easier. This feature is available for self-managed customers only, but will be extended to groups and projects as part of a the larger epic to make the instance, group, and project-level audit events experiences uniform and much friendlier to use.

Filtered search for instance-level audit events

Enable group-level default branch protection

Previously, the translation of instance-level default branch protection settings down into projects was confusing because, in certain scenarios, it created an unintuitive experience: developers could not push new commits to projects they could create. This made it difficult for organizations to strike a balance between mitigating risk and allowing carte blanche access to projects for all developers since the workaround required promoting them to Maintainer.

Now, default branch protection can be set at the group level to provide better flexibility for administrators and group owners. Using a combination of default branch protection and default project creation settings, organizations can find the right mix of autonomy and control, such as using custom default branch protection and allowing only maintainers to create new projects. This would allow developers to push new commits (not force push or delete a branch) to new projects, but allow maintainers to control project creation.

This group-level configuration of default branch protection can be disabled for organizations requiring more strict controls in place. By disabling the group-level setting for default branch protection, maintainers can apply more stringent controls on developer access and permissions.

Value Stream Analytics | Tasks by Type

This powerful new chart allows teams to see how delivery is distributed across different types of work. Use labels to see how many features are delivered vs. bugs from release to release, or how many items a given team ships vs. another. By reflecting on the distribution of work delivered through the value stream, teams can tune their processes to better align with strategic objectives or better balance resources across teams.

Value Stream Analytics | Tasks by Type

Email notification for unknown sign-ins

Users will now receive an email notification when a sign-in using their credentials occurs from a new IP address or device. This new functionality helps users quickly identify potential malicious activity related to their accounts.

Raise warning when closing an issue with open blockers

In GitLab 12.8, we introduced the ability to create dependencies between issues, where one issue can block another related issue. This means that the downstream issue should not be closed until the predecessor is completed and closed. This required you to check to see if an issue is blocked before you closed it.

Having to check if an issue is blocked prior to closing the issue is an additional step that is unnecessary and easy to forget.

We’ve eliminated that step by showing you a warning if you attempt to close an issue with unresolved blockers. We also provide links to the blocking issues so you can verify that your issue is safe to close.

This level of increased dependency alerts helps keep projects running smoothly, and ensures that sequencing of issues can be maintained!

Add Epics or issues via the Epic Tree more easily

Creating and adding issues and epics in the Epic tree used to be split across multiple buttons and drop down menus, and was somewhat cumbersome to use. We have consolidated the “add” and “create” actions into a single button and menu to make it easier and faster to add new issues and epics!

Add Epics or issues via the Epic Tree more easily

Use emojis in design comments to enhance feedback 👍

In 13.0, Design discussions are one step closer to the commenting experience in GitLab. We’ve added emoji support so you can convey your feedback in a more fun and imaginative way! 😼

Use emojis in design comments to enhance feedback 👍

New comparison mode for Merge Requests

Merge Requests, particularly the Changes tab, is where source code is reviewed and discussed. In circumstances where the target branch was merged into the source branch of the merge request, the changes in the source and target branch can be shown mixed together making it hard to understand which changes are being added and which already exist in the target branch.

In GitLab 13.0, we are adding an experimental comparison mode, which will show a diff calculated by simulating a merge - a more accurate representation of the change than using the merge base of the two branches. The new mode is available from the comparison target drop down by selecting master (HEAD). In the future it will replace the current default comparison.

Syntax Highlighting Themes for the Web IDE

GitLab supports six syntax highlighting preferences when viewing code. Themes are important to developers when viewing and editing code on GitLab since it’s imperative that they work comfortably throughout the day. We’ve now released support for all six syntax highlighting preferences in the Web IDE. This includes Solarized Dark, Solarized Light, Monokai and a no highlighting option.

Over the last few releases (for example, 12.8 and 12.9) we’ve been steadily adding and improving support for syntax highlighting preferences in the Web IDE. These updates follow this effort and help to lay the foundation for our Dark Theme in the Web IDE, also launching in 13.0. We’re excited to continue to expand on developer experience and making the Web IDE feel more like home.

Syntax Highlighting Themes for the Web IDE

Visually highlight design comment pins so you can follow the discussion

When there are a lot of discussion threads on a design it can be hard to identify which thread relates to which comment pin on the design without scanning for the correct comment number.

In 13.0, we added a mechanism to highlight the relevant design discussion comment pin when you click on the comment. We also added the reverse where you can click on the comment pin and have the relevent comment scroll into view. This reduces manual scrolling and sifting through the noise when you have lots of comment pins.

Visually highlight design comment pins so you can follow the discussion

Group-level push rules

Push rules provide additional control over what can and can’t be pushed to your repository. They allow you to create custom operational standards that align with your organizational policies.

Previously, push rules could only be set at the instance or project level, forcing admins to manage large numbers of people and projects independently. New group-level push rules will allow group owners a way to govern policy in a central location, while still providing individual project owners with flexibility.

Commit navigation buttons in merge requests

Easily navigating commits in large merge requests allows reviewers to be more efficient while reviewing on a commit-per-commit basis.

The new commit navigation buttons allows users to seamlessly navigate between the current commit to the previous or next commit, making it more efficient to review merge request with a large number of changes.

Commit navigation buttons in merge requests

Make JUnit Reports available through the GitLab API

A JUnit report can contain a wealth of information that can be used to update test plans, test execution history, and other artifacts which teams use to track the quality of their code. Updating those artifacts can be a painful, manual, process made worse by the fact that JUnit reports are only available to download from the GitLab UI. Starting in GitLab 13.0 users of the GitLab API will be able to access JUnit reports directly. This will enable users to parse JUnit data to create new issues or update test execution history.

Filter pipelines by trigger author and branch name

Searching for pipelines triggered by a specific user or that ran on a particular branch is now easier than ever before. With a new filter feature on the pipelines page, it is now possible to filter by trigger author and/or by branch name. Being able to refine the pipelines view by applying these filters will help to stay informed of pipeline activities that matter most to you.

Setting to allow Deploy tokens to read and write to the GitLab Package Registry

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

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

Package versions are now nested under their parents

The GitLab Package Registry has been treating each new version of a package as a new package. This has made it difficult to find the package you are looking for or to understand what has changed from version to version.

In GitLab 13.0, we are excited to announce that each version of a package will now be nested under its uniquely-named parent. This will make it easier to find the package you are looking for in the UI and to better understand what has changed from version to version. This change applies to both the group and project-level views of the Package Registry. In addition, when using the Packages API, versions will now be returned as an array within the parent package.

Package versions are now nested under their parents

Implement a deployment freeze with the Freeze Period API

In this milestone, GitLab introduces more controls for environments. With the Freeze Period API, you can easily prevent an unintended production release during a period of time specified by you, whether it is a large company event or holiday. You can now rely on the enforcement of policies that are typically outside the scope of GitLab to reduce uncertainty and risk while automating deployments.

Update Release's milestone in Web UI

GitLab’s Release Management team is working on expanding the Release Page to include all the Release API’s functionality. In 13.0, it is now easier to add a single or multiple milestones to your Releases. With this addition, you no longer have to manually call the Release API to take advantage of planning features, such as the Release Progress View, which was introduced in 12.9.

Update Release's milestone in Web UI

Use search to quickly find and discover images hosted in the GitLab Container Registry

When you or someone on your team publishes an image to the GitLab Container Registry, you need a way to quickly find it and ensure the image was built properly. If you’re using GitLab CI/CD to publish images with each build, it’s been very difficult to find an image efficiently within the current user interface. Instead, you’ve relied on the command line or the API.

We are excited to announce that in 13.0, we’ve added search functionality to the GitLab Container Registry. Simply navigate to your project or group’s registry and enter an image name to see a list of all your images.

View payload and annotations of external IT alerts in GitLab

The alert list view is helpful for triaging problems at a high-level, but it does not provide enough space for all alert attributes and the payload. The new alert detail page is dedicated to displaying and organizing the alert payload and annotations so that responders can quickly find critical information during an investigation.

Emojis render on status page

GitLab issues support emojis in the issue title and all Markdown fields. When you publish a Gitlab issue to a public URL as a status page, the status page now supports and renders emojis used in issue titles, descriptions, and comments.

Toggle Metrics Dashboards visibility

Previously, project administrators couldn’t control permission to view a project’s metrics dashboards. As part of GitLab 13.0, admins can now toggle metric dashboard visibility to either project members, or to everyone with access.

Toggle Metrics Dashboards visibility

Add annotations to a Metrics Dashboard

Sometimes your metric charts can be hard to understand. Starting in GitLab 13.0, you can now add annotations to your metrics charts which appear as dotted horizontal lines overlaid on your graphs and charts, to help you interpret and understand the data.

Add annotations to a Metrics Dashboard

Secret Detection for the Full History of a Repository

GitLab 13.0 updates our Secret Detection Security Scanning to support a new configuration variable (SAST_GITLEAKS_HISTORIC_SCAN) to allow scanning the full history of a repository. This allows you to identify historical secrets that might be hiding in your older git commit history. Since introduction in GitLab 11.9, Secret Detection scanned the commit history of changes in a merge request. This would detect new secrets but would not identify secrets in the repository’s older git history. This new functionality is particularly useful when you are enabling Secret Detection in a repository for the first time and you want to perform a full secret scan.

We have created a short video walkthrough showcasing how you can perform a historical secret scan via scheduled pipeline or with a manual pipeline.

Export vulnerabilities list from Instance and Project Security Dashboards

We’re pleased to announce the initial release of exportable vulnerability lists from the Instance Security Dashboard and Project Security Dashboard. While the Security Dashboards let users manage vulnerabilities as part of the GitLab workflow, it hasn’t been as easy to get a list of this information for external use.

You can now download a CSV file containing the detected vulnerabilities for a given project or all projects configured on the Instance Security Dashboard. This export list can then be used for things such as creating compliance reports or as a data source for external dashboards. Simply go to the instance Security Dashboard or any project’s Security Dashboard and click the new Export button in the upper-right or go to the Security option under the More menu in the top navigation bar, then click the new Export button in the upper-right. Your browser will automatically start the download.

Export vulnerabilities list from Instance and Project Security Dashboards

Web Application Firewall (WAF) SIEM Integration

We’re pleased to announce a new SIEM integration for the Web Application Firewall (WAF)! The integration allows users to export their WAF logs to a SIEM or central logging solution so they can review any anomalies detected by their WAF. This visibility into the logs also helps users to test and tune their WAF rules to reduce false positive rates. The SIEM integration can be configured by enabling Fluentd on the Operations -> Kubernetes page.

Web Application Firewall (WAF) SIEM Integration

GitLab Helm chart improvements

  • The Helm chart now supports configuration of multiple Redis instances. This allows you to have different Redis instances for different storage types, for use with our 10,000 users Reference Architecture. For details on specific changes, refer to the issue.
  • Now that Puma is the default web application server, with the option to still switch back to using Unicorn, the name of the Unicorn chart has changed from unicorn to webservice. For configuration details, see the Charts documentation.
  • The ConfigMap entries for puma.rb and unicorn.rb files have been removed 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.
  • The version of Ruby used by the GitLab Helm chart has been updated to 2.6.6.

Geo secondaries automatically forward SSH requests for unsynchronized repositories

Geo supports selective synchronization of projects, which allows systems administrators to choose a subset of data that is replicated to a secondary Geo node. Geo already supports redirecting HTTP(S) requests to the primary when trying to access these unsynchronized repositories. However, users trying to access unsynchronized repositories on a secondary node via SSH would receive an error that the repository was not available. This was confusing for users and forced them to either wait for the repository to synchronize or do extra work to connect to the right repository.

In GitLab 13.0, any Git requests made via SSH to an unsynchronized secondary Geo node will be forwarded to the primary node. This results in a much more seamless user experience because users won’t need to know what is or isn’t replicated to this node - Geo will fulfill the request both via HTTP(S) and SSH without any additional configuration.

Geo improvements to the administrator interface

As GitLab grows, Geo continues to support replication for additional resources. This in turn increases the number of status pages that are shown in the sidebar. This approach does not scale well and makes it harder for systems administrators to find what they need. In GitLab 13.0, we merged the sub-pages for Projects, Uploads and Designs into a single view that can be accessed via a single sidebar entry “Replication”. This change groups all the information in one place and helps systems administrators access the replication status of individual items.

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

Geo improvements to the administrator interface

Runner now supports downloading artifacts directly from Object Storage

GitLab Runner 13.0 now supports downloading artifacts directly from object storage. When this option is enabled the GitLab server will redirect the Runner directly to object storage, rather than proxying the traffic. This can result in significant cost savings on network transfer costs, as well as reduced load on the GitLab server.

To enable set the FF_USE_DIRECT_DOWNLOAD feature flag to true via an environment variable.

Bug fixes

Some of the notable bug fixes in GitLab 13.0 are:

Added admin impersonation audit events

Auditability and traceability are critical components of an organization’s compliance program. Previously, actions taken by an administrator, who impersonated another user, would be captured in the audit events table as if the impersonated user was taking those actions. Now, audit events will show you when specific actions were the result of an administrator’s impersonation activity.

This important addition to audit events corrects a gap in nonrepudiation for your compliance program and adds to the reliability and comprehensiveness of your GitLab audit events data.

Value Stream Analytics | Lead time, cycle time metrics

Two key value stream metrics now give teams a baseline against which process improvement efforts may be measured so that they may more easily see the impact of process changes. Lead time measures the elasped time between a requested item and its delivery. Cycle time measures the length of the development cycle itself. By optimizing flow across the entire value stream, teams avoid moving a problem from one place to another and ship faster.

Value Stream Analytics | Lead time, cycle time metrics

Okta SCIM Integration Application for GitLab.com

We now offer an Okta SCIM integration application for Gitlab.com groups! When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta. This reduces group administrator time spent to onboard and offboard users.

Export and Import Groups in the UI

Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.

As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI. We plan to introduce similar Import functionality to the UI within the next few weeks.

View Milestones on the Roadmap

Accurately tracking the status of work in flight is a must to help keep teams on track. Now, when viewing your roadmap, you can view how your epics line up with your various milestones helping you better understand when work will land, and identify if projects are ahead or behind expectations.

View Milestones on the Roadmap

Assign an issue to a different Epic via drag and drop in the Epic Tree

Often when organizing or curating an epic, you need to move an existing issue to another epic in the tree. You can now move an issue to a different epic via drag and drop, instead of having to click through multiple tabs.

Assign an issue to a different Epic via drag and drop in the Epic Tree

Design Management moved to Core

In the 12.2 release, Design Management debuted with Design Uploads and Point of Interest Discussions as a GitLab Premium feature. Since then, we’ve considered our users who are designing products as individual contributors and, in 13.0, we’re excited to announce we’ve moved these two features down to GitLab Core! This aligns with our Individual Contributor Buying Model and we expect to add other great team features in the future, like approvals, as we progress towards category maturity.

So now, all users can upload and participate in design feedback on issues in GitLab! As a refresher, you’ll find the Design tab next to the Discussion tab on any issue. Try a drag-and-drop upload of a screenshot to get started!

Design Management moved to Core

Improved Snippets editor

With the release of Versioned Snippets in GitLab 13.0, we’ve upgraded the Snippets editor to a lighter-weight version of the editor found in our Web IDE. With this editor, users will benefit from basic code completion and linting for some languages. We’ve also improved source code language detection for better syntax highlighting, and added support for all our syntax highlighting themes. These improvements will make it easier to edit and collaborate on Snippets.

We’re excited to bring consistency to the editors in Snippets and the Web IDE. In a future release we’ll expand this functionality to our single file editor and in our .gitlab-ci.yml editing experiences.

Improved Snippets editor

WYSIWYG for the Static Site Editor

Markdown is a powerful and efficient syntax for authoring web content, but even seasoned authors of Markdown content can struggle to remember some of the less-frequently used formatting options or write even moderately-complex tables from scratch. There are some jobs better accomplished with a rich text, “What You See Is What You Get” (WYSIWYG) editor.

GitLab 13.0 brings a WYSIWYG Markdown authoring experience to the Static Site Editor with formatting options for common formatting options like headers, bold, italics, links, lists, blockquotes, and code blocks. The WYSIWYG editor also removes the onerous task of editing tables in Markdown by letting you visually edit table rows, columns and cells in the same way you would edit a spreadsheet. For those more comfortable writing in raw Markdown, there’s even a tab for switching between WYSIWYG and plain text editing modes.

WYSIWYG for the Static Site Editor

Approved-by filter for merge requests

Merge Request Approvals require specific people to approve changes before they can be merged. When searching the merge request list, you can quickly find which merge requests need your approval using the Approvers filter. In GitLab 13.0, you can now also find any merge requests you previously approved using the new Approved-By filter.

Approved-by filter for merge requests

Support parent/ancestor groups and users in CODEOWNERS file

Groups can be used for organizing users in GitLab. This makes it easy to share projects, mention in comments, or assign as merge request approvers without selecting them one at a time.

Groups and users can be assigned as code owners, but ancestor groups could not be used. This meant assigning a parent group from the project hierarchy as a code owner had no effect.

GitLab 13.0 introduces the ability to include users and groups from a parent or ancestor group in a project’s CODEOWNERS file, providing more flexibility when specifying Code Owners’ rules.

Inherit environment variables from other jobs

Passing environment variables (or other data) between CI jobs is now possible. By using the dependencies keyword (or needs keyword for DAG pipelines), a job can inherit variables from other jobs if they are sourced with dotenv report artifacts. This offers a more graceful approach for updating variables between jobs compared to artifacts or passing files.

GitLab Runner 13.0

We’re also releasing GitLab Runner 13.0 today! GitLab Runner is the lightweight, highly scalable, cross-platform software agent agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Configurable browser performance testing threshold

Browser Performance Testing allows users to easily detect when there is a degradation in their web app before merging to master. In many cases this causes extra noise and clutters up the Merge Request page unnecessarily, even for minor changes. In this milestone, you can now set an optional degradation threshold as a requirement that must be met before the Performance report will be displayed.

View more robust data in the list view Package Registry user interface

Before this release, the Package Registry list view showed a limited amount of information related to the packages in the UI. While this information is important, it lacked key metadata such as version, branch, and commit.

In 13.0, we’ve updated the design of this page to include additional metadata to help you find the package you are looking for and verify it was built properly. In addition to the package name, you can now see version, type, and more. Check out the video for an example or start using the feature today.

View more robust data in the list view Package Registry user interface

View all of your Python packages in one place with the GitLab Package Registry

The GitLab Package Registry user interface allows you to confirm that your packages have been built properly and troubleshoot when something has gone wrong. However, the MVC of the new PyPI Repository that launched in 12.10 did not include this functionality.

In 13.0, we’ve added the PyPI Repository to the Package Registry UI. Now, you can view and download your project or group’s PyPI packages and reference metadata to validate that the package was built properly. You can also quickly copy setup and install commands for more efficient sharing and coding. If the package was built using a GitLab pipeline, you’ll be able to view and link it to the pipeline, as well as the commit that was used to publish the package.

View all of your Python packages in one place with the GitLab Package Registry

API support for Feature Flag lists

As part of our support for Feature Flag lists, we have added API support to enable creating, editing, and deleting them. This will make it easier to automate the management and synchronization of these lists between different systems.

Define policies to ensure important images are never deleted

When using GitLab’s Image Expiration Policy, there is no way to express something such as “no matter what, don’t delete this tag”. This introduces risk into the deletion process, as it’s possible to delete release or master images, which should be immutable.

In 13.0 we are excited to announce that you can now update your project’s expiration policy to identify images you never want deleted. Simply enable the policy and use regex to identify the image you want to preserve.

Define policies to ensure important images are never deleted

Use Cloud Native Buildpacks for Auto DevOps (beta)

Cloud Native Buildpacks are the next iteration of buildpacks. While GitLab currently defaults to Herokuish buildpacks, we intend to move Auto DevOps to Cloud Native Buildpacks when the project matures, to provide a future-proof and well-maintained solution to our users. With this release, you can opt in to use the beta for Cloud Native Buildpacks in Auto DevOps pipelines by setting the AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED CI variable.

Aggregate IT alerts from external tools in GitLab

When responding to alerts, responders need a single interface that aggregates IT alerts originating from multiple sources. The new alerts list enables you to sort through alerts quickly and intuitively to help you find and triage the most critical problems first. You can access the alerts list at Operations » Alerts.

Add frequently used dashboards to favorites

In GitLab 13.0, you can now add your frequently-used dashboards to your favorites by clicking the Star button. Starring a dashboard displays it first in the dashboard search bar results to save you time.

Add frequently used dashboards to favorites

Display charts in full screen mode

In GitLab 13.0, you can now display metrics charts in full screen mode, helping you see chart information in more detail when triaging incidents.

Status pages anonymized

When an incident response team shares incident updates and status changes, the incident description is published publicly, but all user and group names in issue descriptions are anonymized to protect the privacy of individuals and teams.

View DAST Scanned Resources List

DAST analyzes your running web application for known runtime vulnerabilities, starting with each merge request. DAST scans many resources, but knowing precisely which ones was not possible before.

GitLab 13.0 presents a full list of the resources that DAST scanned. You can now evaluate DAST scans to ensure all necessary application surfaces are covered. For further ease of analysis, you can download scan lists directly from the results screen.

Container Network Policies SIEM Integration

We’re pleased to announce a new SIEM integration for Container Network Policies! The integration allows users to export their Cilium logs to a SIEM or central logging solution so they can review any anomalies detected by their Network Policies. This visibility into the logs also helps users to test and tune their Network Policies to reduce false positive rates. The SIEM integration can be configured on the Operations > Kubernetes page.

Container Network Policies SIEM Integration

Live Information about Vulnerability Database

We know that understanding what GitLab scans for is important to ensure that you feel safe. With this release, we are introducing a new page to give you more information about the vulnerability database our scanners use.

From this page, you can get information about what we are scanning for, when we last updated our database, and also look up specific vulnerabilities you are concerned about.

PostgreSQL 11 is now the minimum required version to install GitLab

The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been removed in GitLab 13.0. This update allows us to start introducing performance improvements based on the partitioning features that were added in PostgreSQL 11. We plan to support PostgreSQL 11 for the entire duration of the GitLab 13.x series of releases. Support for PostgreSQL 12 will be added in the near future. See Important notes on upgrading for PostgreSQL-related upgrade guidelines.

Improved Geo replication performance for Job Artifacts, Uploads and LFS files

To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s database queries time out, data can’t be replicated successfully. In GitLab 13.0, we use a new approach to synchronize Job Artifacts and Uploads, thereby eliminating the possibility of database statement timeouts. We also improved the database query performance to retrieve Job Artifacts, LFS Objects, and Uploads when these files are stored locally, which increases the overall scalability and performance of GitLab Geo.

These iterations bring us closer to removing Geo’s dependency on Foreign Data Wrappers, which were added for improved performance, but makes Geo more complex and harder to maintain.

Omnibus improvements

  • The minimum required version of PostgreSQL is now PostgreSQL 11. See the PostgreSQL 11 announcement for more details.
  • In Redis 5, the terminology for slave was changed to replica. In GitLab 13.0, this change was made in the Redis configuration in Omnibus. See Important notes on upgrading for upgrade instructions.
  • GitLab 13.0 includes Mattermost 5.22, an open source Slack-alternative. This release includes team switch shortcuts, ability to unarchive channels from the user interface, experimental channel sidebar features, and much more. This version also includes security updates. If you have a Mattermost environment that contains a lot of emoji reactions, please refer to Important notes on upgrading for information on longer upgrade times.
  • The version of Ruby packaged in Omnibus GitLab has been updated to 2.6.6.

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

Deprecations

Removal of deprecated project paths

With the introduction of subgroups, GitLab’s URL path structure became more complex. We’ve been introducing a separator, /-/, to improve clarity between groups, projects, and pages within a project. For example, https://gitlab.com/gitlab-org/gitlab/issues is now https://gitlab.com/gitlab-org/gitlab/-/issues. These changes result in improved performance, stability, and simplicity.

As we introduce the separator to additional pages, we automatically redirect requests to the old paths to the new ones. With GitLab 13.0, we are removing this redirect for pages which have had the separator since GitLab 12.0.

Regular usage of GitLab will not be impacted by this change. However bookmarks or scripting created over a year ago, utilizing an affected path, will need to be updated to utilize the new path.

Deprecation date: Jun 22, 2020

GitLab Pages `auth-server` to be removed in 14.0

We’re changing how some of the configuration options in GitLab Pages behave to streamline the initial setup, while helping you avoid misconfiguration. If you installed GitLab by using the Omnibus, no action is required. Otherwise, you’ll need to set the gitlab-server parameter and remove auth-server.

Deprecation date: May 22, 2021

Prometheus replaces InfluxDB for self-monitoring

Starting in GitLab 13.0, InfluxDB is being deprecated in favor of Prometheus for GitLab self-monitoring metrics. Please update your configuration for GitLab reporting and visualizations to use Prometheus, which is installed by default on every GitLab instance.

Deprecation date: June 22, 2020

The default method of invoking Sidekiq will be `sidekiq-cluster`

As stated in the 12.10 release post, in GitLab 13.0 we have deprecated alternative ways of starting Sidekiq in favor of Sidekiq Cluster. Sidekiq Cluster provides additional options for managing Sidekiq queues and scaling.

This enables running multiple Sidekiq processes for Core instances (a previously EE exclusive feature). Multiple Sidekiq processes allow a GitLab instance to continue to scale vertically, and are often a good first step prior to adding additional nodes. In addition, this will allow us to simplify support and improve maintainability for GitLab.com.

Directly invoking Sidekiq will no longer be supported as of 14.0.

For more information on falling back to the old (deprecated) behavior, please refer to either Omnibus or Helm charts docs.

Bug reports in this issue will be greatly appreciated.

Deprecation 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 in GitLab 13.0.

In GitLab 13.0, the deploymentApiVersion setting changes to a new default of apps/v1. If you are using Kubernetes 1.9 and below, you must upgrade your Kubernetes cluster to support apps/v1. For Auto DevOps, GitLab requires Kubernetes 1.12+.

Deprecation date: May. 22, 2020

Auto DevOps' default PostgreSQL version is changing

As part of updating Auto DevOps in GitLab 12.9 to support Kubernetes 1.16, we added the opt-in ability for Auto DevOps to use the PostgreSQL chart version 8.2.1. The default PostgreSQL chart version in GitLab 12.10 is currently 0.7.1. GitLab 13.0 switches the default PostgreSQL chart version from 0.7.1 to 8.2.1. To remain on the old default version, you must 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 to backup your database, install the new version of PostgreSQL, and restore your database.

Deprecation date: May 22, 2020

Removal of logs view from the admin dashboard

Logs can no longer be viewed from within GitLab admin dashboard. These logs used to be read directly from disk to be displayed in the admin interface. Sadly, this does not work in multi-node setups and could cause confusion for administrators by displaying partial information. The logs are still available to administrators with access to the host, please see the documentation on our log system for more information. For multi-node systems we recommend ingesting the logs into services like Elasticsearch and Splunk.

Deprecation date: May 22, 2020

Planned deprecation of variables SAST_ANALYZER_IMAGE_PREFIX and DS_ANALYZER_IMAGE_PREFIX in Secure CI Templates

To help streamline and simplify the setup of GitLab Security Tools, we have introduced a new global variable SECURE_ANALYZERS_PREFIX which by default points at the GitLab registry. This variable replaces the now deprecated variables in SAST and Dependency scanning: SAST_ANALYZER_IMAGE_PREFIX and DS_ANALYZER_IMAGE_PREFIX. Support for these deprecated variables will be removed in a future release, so please migrate any usage to SECURE_ANALYZERS_PREFIX. You can override this variable to easily affect all security scanners at once. This is useful in situations where you are using your own registry images which is common in offline and air-gapped environments.

Related Links:

Deprecation date: June 22, 2020

Deprecation of Docker-in-Docker (DinD) for Security Scanners

To increase the security and reduce complexity of scans, use of Docker-in-Docker (DinD) in GitLab Secure scanners has been deprecated. GitLab security products will begin to use non-DinD mode by default in vendored templates in GitLab 13.0. We encourage customers to update their vendored templates to use this new behavior. If you want to continue using DinD mode instead, see Enabling Docker-in-Docker for Dependency Scanning. In a future release we intend to remove DinD completely. Please be aware of slight changes in scanner detection logic, which we have largely mitigated.

Deprecation 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 in Auto DevOps and Secure Configuration templates. The rules parameter provides more verbose and expressive job execution logic that is simpler to evaluate and easier to understand.

Auto DevOps and Secure configuration templates that use only and except will transition to rules, starting in GitLab 13.0. We strongly encourage customers who have customized job templates to transition because the only/except and rules syntax cannot be used together. For help migrating your templates, see Transition your only/except syntax to rules.

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 Auto DevOps and Secure Configuration templates using only and except should be transitioned to the rules syntax. There are occasional cases where the existing only and except syntax cannot be easily matched with rules. We would love to hear more about these cases on this rules improvement issue.

Relevant issues:

Deprecation date: May 22, 2020

SSH `authorized_keys` file deprecated

As of GitLab 13.0, the bin/authorized_keys file used for SSH authorization is deprecated, replaced by bin/gitlab-shell-authorized-keys-check, which conducts the authorization through fast lookup instead. The deprecated method wasn’t reliable as it doesn’t check that the requesting user matches the expected user. The final removal is scheduled for GitLab 13.1, released next month (June 22nd, 2020).

Deprecation date: May 22, 2020

Removal of authorized_keys authorization for SSH

The authorized_keys authorization mechanism for SSH is not scalable, and is vulnerable to race conditions and out-of-order execution issues. It also requires a shared filesystem for most deployments of more than one machine. [Fast lookup of authorized SSH keys] (https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html) solves these issues and is the recommended authorization mechanism. As such, we are planning to make it the default mechanism starting in GitLab 14.0.

As we work to make fast SSH lookups the default Git+SSH authorization mechanism in GitLab, we are deprecating the authorized_keys mechanism, which is currently the default. We plan to make this new mechanism work out of the box, so there is no impact or action required from GitLab users nor administrators.

Deprecation date: May 22, 2021

Planned removal of legacy storage in 14.0

GitLab currently supports two types of storage for repositories: Legacy storage and hashed storage. Hashed storage makes the folder structure immutable and results in performance and security improvements.

Hashed storage has been available since GitLab 10.0 and is on by default since GitLab 12.0. GitLab.com has been fully migrated to hashed storage. With GitLab 13.0 legacy storage is deprecated and we are planning to fully remove legacy storage in 14.0.

In 13.0:

  • Legacy storage is deprecated and usage is strongly discouraged. Please follow instructions on how to migrate fully to hashed storage.
  • Administrators will no longer be able to disable hashed storage for new projects.
  • New projects and renamed projects will use hashed storage by default.
  • When renaming or moving projects they will be migrated to hashed storage automatically.

In 13.2:

  • Upon upgrading to 13.2, all projects still in legacy storage will be automatically migrated via a background migration.
  • Some new features may require hashed storage and won’t be available when using legacy storage.

In 14.0:

  • Legacy storage support will be completely removed from GitLab. Users must migrate to hashed storage before upgrading to 14.0.

Deprecation date: May 22, 2020

Deprecate Windows batch `cmd` for the shell executor

In GitLab 11.11, we announced the deprecation of the Windows batch executor, Cmd shell, for the GitLab Runner in favor of PowerShell. In 13.0, we have deprecated the use of the Windows batch executor for the GitLab Runner. PowerShell is the default command shell when a new Runner is registered that uses the Windows executor starting with GitLab Runner 12.0. The Cmd shell remains included in future versions of GitLab Runner. However, any new Runner feature is to be tested and supported only for use with PowerShell. You can find more details in issue #4163.

Deprecation date: May 22, 2020

Unicorn will be removed in favor of Puma

Unicorn support is deprecated and will be removed in GitLab 14.0. Learn more about migrating to Puma.

Deprecation date: May 22, 2021

Removals

Removed `debug/jobs/list?v=1` endpoint

In GitLab Runner 13.0, we have removed the /debug/jobs/list?v=1 endpoint used for monitoring. This is superseded by the /debug/jobs/list?v=2 endpoint. You can find more details in issue #6361.

Removal date: May 22, 2020

Remove --docker-services flag on register command

In GitLab Runner 12.7 we introduced the ability to allow a service alias from config in the Docker executor. In 13.0, the old structure (--docker-services) has been removed. This means that the option gitlab-runner register --docker-services postgres will no longer set the service, because the configuration is no longer an array of strings. You can find more details in issue #6404.

Removal date: May 22, 2020

Release API evidence_sha and evidence_file_path deprecated

Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha and filepath fields. Access to the original Evidence object is separately available via the deprecated evidence_sha and evidence_file_path fields in the Releases API. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.

Removal date: May 22, 2020

`gitlab_monitor` attribute removed from `gitlab.rb`

The GitLab Monitor tool was renamed GitLab Exporter in 12.3 to prevent confusion with other monitoring-related features, and gitlab_exporter keys were added to gitlab.rb. The gitlab_monitor keys were deprecated in 12.3 and have been removed in 13.0.

Removal date: May 22, 2020

Remove support for Windows Server 1803

We have removed support for Windows Server version 1803 in the GitLab Runner 13.0 release. You can find more details in issue #6553.

Removal date: May 22, 2020

Auto DevOps' postgres chart upgrading to ver 7.7.3

As Kubernetes 1.16 no longer serves resources on the extensions/* and apps/beta* API endpoints, all dependent resources are upgraded to consume the new apps/v1 API endpoint. If you are making use of the postgres database served by Auto DevOps, see the migration guide in order to backup your database, upgrade postgres version, and restore your database.

Removal date: May 22, 2020

Remove support for array of strings when defining services for Docker executor

In GitLab Runner 13.0, we have reverted back to using the default TOML parsing instead of UnmarshalTOML for the DockerService. You can find more details in issue #4922.

Removal date: May 22, 2020

`consul['user']` and `repmgr['user']` attributes removed from `gitlab.rb`

The consul['user'] and repmgr['user'] attributes were deprecated in favor of consul['username'] and repmgr['username'] in 12.10 to be consistent with other GitLab services that allow a username to be configured. These attributes have been removed in 13.0. If you are still using the user attributes you will need to switch over to using the username attributes.

Removal date: May 22, 2020

GitLab Pages auth_server attribute removed

The auth_server setting (with an underscore [_]) for configuring access control when running GitLab Pages on a separate server was deprecated in a previous release in favor of the gitlab_server setting. This change was made because the data that GitLab Pages gets from GitLab now extends beyond just authentication. The auth_server setting has been removed in 13.0.

Removal date: May 22, 2020

Redis 3 no longer supported

Redis 3 has reached end of life and is no longer supported starting in GitLab 13.0. The bundled Redis version was updated to Redis 5 in GitLab 12.7 and GitLab Cloud Native Chart 3.0.

Removal date: May 22, 2020

Remove Fedora 29 package support

Since Fedora 29 has reached End of Life as of 2019-11-30, we have removed support for Fedora 29 packages in the GitLab Runner 13.0 release. You can find more details in issue #16158.

Removal date: May 22, 2020

Remove macOS 32-bit support

As Go 1.14 is the last Go release to support 32-bit binaries on macOS (the Darwin/386 port), we have removed support for 32-bit macOS in the GitLab 13.0 release. GitLab Runner will continue to support the macOS 64-bit Darwin/AMD64 port. You can find more details in issue #25466.

Removal date: May 22, 2020

PostgreSQL 9.6 and 10 removed no longer supported

The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been from the Omnibus package and Helm charts. The removal of support for 9.6 and 10 allows us to build upon the latest features and performance improvements available in PostgreSQL 11. For more details, see the release post on PostgreSQL 11.

Removal date: May 22, 2020

GitLab Snippets content search removal in 13.0

With the release of Versioned Snippets, files in Snippets are no longer available via search from the UI and API. Title and Description content will be accessible via search and API.

Removal date: May 22, 2020.

Remove `FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER` feature flag

In 12.0, we introduced a feature flag for the Docker executor that enabled you to continue using the method where volumes are not mounted to services. In 13.0, this feature flag has been removed and volumes will be mounted to services. You can find more details in issue #6581.

Removal date: May 22, 2020

NFS for Git repository storage deprecated

With the general availability of Gitaly Cluster in GitLab 13.0, we are deprecating NFS for Git storage. We intend to remove support for NFS for Git repositories in GitLab 14.0. We are taking this action early to communicate our intent clearly, and avoid customers purchasing expensive NFS appliances that are not needed.

We invite customers currently using NFS for Git repositories to begin planning their migration. There are multiple use cases for NFS for Git storage, and we are working to address these in our Gitaly Cluster roadmap.

Removal date: May 22, 2020

Protected path configuration removed from `gitlab.rb`

Configuration settings for protected path rate limits have been removed from gitlab.rb. Configuration of protected paths was moved to the GitLab Admin UI in GitLab 12.4.

Removal date: May 22, 2020

Remove legacy build directory caching

In GitLab Runner 13.0, we have removed the legacy build directory caching feature flag that was introduced in 11.10. You can find more details in issue #4180.

Removal date: May 22, 2020

Release API evidence_sha and evidence_file_path removed

Now that users can create Release Evidence on demand, GitLab supports multiple Evidence objects, each of which exposes the summary_sha and filepath fields. The original Evidence object is accessible as the first instance of the multiple Evidence objects. Updates to 13.0 make it possible to continue using Release Evidence and to be able to leverage on demand evidence collection.

Removal date: May 22, 2020

Remove Jenkins CI(deprecated) Service

In GitLab 8.3, the Jenkins integration using the GitLab Hook Plugin was deprecated in favor of the GitLab Plugin. In 13.0, this Jenkins CI(deprecated) service is removed in issue #1600.

Removal date: May 22, 2020

Remove Backported `os.Expand`

In GitLab Runner 13.0, we have removed 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.

Removal date: May 22, 2020

Important notes on upgrading to GitLab 13.0

  • GitLab 13.0 automatically migrates all snippets, creating a repository for each one of them and also committing a file into it based on the snippet file name and content. This operation is done in a background migration, therefore no downtime is required. In case the background migration fails migrating any of the snippets, GitLab 13.0 also introduces several rake tasks to help migrating them manually.
  • PostgreSQL 11 is the minimum required version starting in GitLab 13.0. PostgreSQL 9.6 and 10 have been removed and are no longer officially supported. You will need to plan on some downtime for the PostgreSQL upgrade because the database must be down while the upgrade is performed. If you are using the GitLab-provided PostgreSQL database, your database will be automatically upgraded when you upgrade to GitLab 13.0, unless you are using HA or Geo in which case some manual steps are required. See the Geo upgrade documentation and HA upgrade documentation for important instructions.
  • Puma is now the default web application server for GitLab. Users who have customized their Unicorn settings will need to manually migrate these settings to Puma. Additionally installations using Direct Git Access, usually those with slower NFS drives, may want to consider running Puma single-threaded. To learn more about the benefits of switching to Puma, see the Puma release note. Unicorn support will be removed in GitLab 14.0.
  • If you are running a self-managed instance of GitLab with an external PostgreSQL database, please note that the default timeout for PostgreSQL statements that was added in GitLab 12.9 has been temporarily disabled. This was due to an issue experienced with GitLab.com. The default timeout will be re-enabled when the proposed change in implementation has been added.
  • If you have a self-managed instance of GitLab and are using the Mattermost integration, please note that a schema change was made in the Mattermost database to fix performance issues with emoji reactions. As a result of the schema change, you may experience longer upgrade times if your Mattermost database contains a lot of emoji reactions. See the Mattermost upgrade documentation for the recommended approach to upgrading.
  • The Redis configuration has been changed in 13.0 to replace the slave terminology with replica, and the Redis version was updated to 5.0.9. These change require a restart of Redis. If you are using Redis HA, follow the Redis HA updgrade steps to upgrade without downtime. If you are running Redis on a single node, you will need to plan on Redis being in accessbile while it restarts.

Changelog

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

Installing

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

Updating

Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project gets the features of Gold for free irrespective of their plan.

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 for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg