13.3
Aug 22, 2020 - Kevin Chu   Kevin Chu

GitLab 13.3 Release

GitLab 13.3 released with coverage-guided fuzz testing and a build matrix for CI/CD

GitLab 13.3 released with on-demand DAST, MR Analytics, Compliance dashboard, Pod health dashboard and much more!

DevSecOps helps teams detect and resolve faults and vulnerabilities early in the software development process. In GitLab 13.3, building secure software is easier with fuzz testing in your development workflow. With coverage-guided fuzz testing and on-demand DAST (Dynamic Application Security Testing), discovering real-world software vulnerabilities is faster and more efficient. At the same time, releasing code more frequently is made simpler with the new build matrix for CI/CD. Finally, the Pod health dashboard increases Ops' efficiency by reducing their context switching: all Kubernetes pods health primitives are in the dashboard. We hope that you find these top features, and the 69 new features packed in this release, useful.

Faster remediation: Find and prevent defects and vulnerabilities earlier

With coverage-guided fuzz testing, it's now easier to efficiently surface and solve vulnerabilities in C, C++, and Go. In GitLab 13.3 all our SAST (Static Application Security Testing) analyzers are available to everyone and it has never been easier to set them up. Finally, running DAST from the GUI is now more convenient. More importantly, security staff can tackle vulnerabilities faster by leveraging the new vulnerability evidence included in the DAST output.

Reduce cycle time, release more frequently

Building powerful workflows is now easy with the new build matrix: define keys and values once, release and deploy multiple times. Teams can increase velocity by measuring Merge Request throughput now available in the MR Analytics Dashboard. Also, MR authors can now integrate code faster by acknowledging their code review requests have been answered at a glance. This acknowledgment of fulfilled duties by different roles in MRs are now traceable in the Compliance Dashboard. Maintainers can also suggest to their contributors a Squash Commit policy. Lastly, rollouts can be more targeted and controlled using the newly named feature flags strategy called Percentage of Users.

Enable your delivery teams to be more productive and efficient

Software development is mostly about building and distributing packages. To make that easier and with usability in mind, we overhauled the whole Package registry GUI and made it available for everyone in Core. Plus, it has never been easier to publish NuGet packages in an automated way. Once deployed, your teams won't need to worry about the health of their systems. All relevant action can be now taken based on information from the Pod health dashboard.

It doesn’t stop here: there is more!

GitLab is used by companies with thousands of users in teams working synchronously and asynchronously across continents. To do so, we are focused on improving its fault tolerance and read/write operation synchronicity on every release. Overall, we are making GitLab lightning fast across the globe.

Here are several other cool features that you should check out:

If you'd like to preview what's coming in the next release, be sure to check out our 13.4 kickoff video!

Join us for Commit 2020 on August 26th

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Gilang Gumilar

Gilang Gumilar improved the use of Releases with issues and merge requests by fixing a filter bug.

This is a fantastic contribution that benefits GitLab users. Thank you Gilang! 🙌

13.3 Key improvements released in GitLab 13.3

Coverage-guided fuzz testing for Go and C/C++ applications

Coverage-guided fuzz testing for Go and C/C++ applications

You can now run coverage-guided fuzz tests against your Go and C/C++ apps. This is a great way to start finding security issues and bugs that other security scanners and traditional QA may miss. Coverage-guided fuzz testing uses contextual information about your app to randomly generate inputs and find crashes or other faults that you can then fix before they affect users in production.

This is the first release that incorporates the new technology from the fuzz testing acquisitions we recently announced. We recently wrote a blog post with some more information about the acquisitions as well.

We have much more on the way for fuzz testing. Check out all the details on our fuzz testing direction page page. We’d love for you to let us know what you think!

Create a matrix of jobs using a simple syntax

Create a matrix of jobs using a simple syntax

GitLab’s child/parent pipelines let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new matrix keyword that works along with parallel to handle the creation of multiple jobs for you, each with different variables.

For example, you could configure your pipeline to automatically create jobs for 4 different architectures, each with a debug and release target for 3 different versions, all with a single matrix-style configuration. This would create 24 unique jobs (4x2x3) to cover every possible combination.

Create a matrix of jobs using a simple syntax

On-demand DAST scans

On-demand DAST scans

Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI. The result is quicker configuration and greatly improved ease of use. When starting a new on-demand scan you select from a site profile that contains your preferred settings. In 13.3, we are releasing the first iteration of the on-demand scans. These scans will initially be limited to a 60-second spider time and a passive DAST scan. This scan will give a quick reconnaissance-type overview of the site you are scanning, without causing any performance or security issues. Over the next few releases, we will be adding options to the Site profile and introducing the Scanner profile. These additions will allow you to increase the spider time, validate ownership of the target site, enable active scans, set authentication options, and more.

On-demand DAST scans

SAST security analyzers available for all

SAST security analyzers available for all

We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. As part of our community stewardship commitment we have made all 15 of our open source based SAST analyzers available in every GitLab tier. This allows ALL GitLab users developing in any of our 18 supported languages and frameworks to leverage GitLab SAST in their projects.

Getting started is as easy as using our new guided SAST configuration experience, enabling Auto DevOps, or adding the SAST configuration template to your gitlab-ci.yml file. Customers not on the Ultimate tier can interact with generated SAST vulnerability report by downloading the SAST job artifact. We’ve also updated our docs with details about the tier breakdown for all our SAST features.

SAST security analyzers available for all

Guided SAST configuration experience

Guided SAST configuration experience

GitLab’s Static Application Security Testing (SAST) now supports a new guided configuration experience. Enabling SAST is now as simple as two clicks. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab SAST. The tool helps a user create a merge request to enable SAST scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template and properly overriding template settings.

With GitLab SAST covering 18 languages across 14 analyzers, there are many SAST configuration options and it can be hard to understand and setup. This new guided SAST configuration experience helps anyone get started with SAST, and lays the foundation for us to introduce new configuration options like custom rulesets and more. We also intend to expand this guided experience to our other security scanning tools.

Guided SAST configuration experience

Kubernetes Pod health dashboard

Kubernetes Pod health dashboard

Seeing all of your system’s metrics in one place, including cluster metrics, is critical for understanding the health of your system. In GitLab 13.3, you can view the health of your Kubernetes pods in the new out-of-the-box Pod health metrics dashboard, whether you are using a managed Prometheus, or have an existing instance of Prometheus running in your cluster, by connecting it to your GitLab instance. Select the desired pod in the dropdown and see key metrics such as CPU, memory usage, Network, and more.

Merge Request Approvals show who participated in the review

Merge Request Approvals show who participated in the review

Code review often involves multiple people and multiple iterations. It can be hard to know who has been reviewing the merge request, and which of those reviewers has approved and who hasn’t. It is important so you can avoid duplicating work and wasting time.

To show who has provided feedback via comments, the merge request widget now shows a Commented by column. This makes it easier for authors and reviewers to identify who to engage.

Merge Request Approvals show who participated in the review

Display strategy information on feature flags list view

Display strategy information on feature flags list view

With the introduction of support for multiple strategies per feature flag in GitLab 13.0, you are able to set strategies for your feature flags. However, you were unable to see the relevant strategy information in the list view of feature flags. It’s now possible to see all related information about a feature flag in the list view. This includes the strategies, the environments, and the number or percent of users for which the flag is enabled. This view lets you quickly understand the configuration of all the flags in your project without the need to open each one of them individually.

Display strategy information on feature flags list view

Instance-level project integration management for external services

Instance-level project integration management for external services

Administrators of self-managed GitLab can now integrate third-party services with all projects on the instance from a single interface.

Previously, integrations had to be configured per project, which meant that if an instance had thousands of projects, thousands of individual configurations had to be manually configured. Not only was this time-consuming, but it was also error-prone, hard to update, and made it difficult to enforce integrations as a policy.

By configuring integrations across all projects, administrators save themselves and their project owners incredible amounts of time and effort.

This is the first iteration of this functionality. In upcoming releases, we will expand this feature to the group level, add more configuration and compliance options, and more.

Instance-level project integration management for external services

Create and manage IT Incidents in GitLab

Create and manage IT Incidents in GitLab

Investigating incidents requires on-call engineers to evaluate different data sources across multiple tools. Assessing metrics, logs, and traces, sharing findings, and updating stakeholders requires engineers to manually aggregate information through screengrabs, copying, and pasting. This work is inefficient and time-consuming, which leads to alert fatigue, increased stress, and low morale.

In 13.3, GitLab is excited to introduce a dedicated list for triaging and managing Incidents in the Operations section of GitLab to help you reduce resolution time. The Incident list provides a high-level summary of the incident, and critical details: when it was created, who is assigned, and the Status Page publication state. Additionally, there are different views organized by status (open, closed, and all) making it easy to identify active incidents.

In GitLab 13.4 and beyond we plan to improve incident response workflows by surfacing related metrics charts, embedding logs, and rendering associated runbooks. To view progress and suggest ideas for future improvements, see the Incident Management epic.

Create and manage IT Incidents in GitLab

Package Registry now available in Core

Package Registry now available in Core

A year and a half ago, we expanded our support for Java projects and developers by building Maven support directly into GitLab. Our goal was to provide a standardized way to share packages and have version control across projects. Since then, we’ve invested to build out the Package team further while working with our customers and community to better understand your use cases. We also added support for Node, C#/.NET, C/C++, Python, PHP, and Go developers. Your increased adoption, usage, and contributions to these features have allowed us to expand our vision to a more comprehensive solution, integrated into our single application, which supports package management for all commonly-used languages and binary formats. This goal could not have been achieved without the explicit support of the GitLab community.

As part of GitLab’s stewardship promises, we are excited to announce that the basic functionality for each package manager format is now available in the GitLab Core Edition. This means that if you use npm, Maven, NuGet, Conan, PyPI, Composer or Go modules, you will be able to:

  • Use GitLab as a private (or public) package registry
  • Authenticate using your GitLab credentials, personal access, or job token
  • Publish packages to GitLab
  • Install packages from GitLab
  • Search for packages hosted on GitLab
  • Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
  • Ensure that your contributions are available for ALL GitLab users

We look forward to hearing your feedback and continuing to improve these features with all of our users.

GitLab Workflow extension for Visual Studio Code now official

GitLab Workflow extension for Visual Studio Code now official

Over two years ago, Fatih Acet created an extension to integrate GitLab with development in Visual Studio Code. Fatih and more than 25 contributors continued to improve the extension with new features, and it has now been installed over 160,000 times. Fatih transferred maintainership to GitLab, and we’ll continue to improve and support this extension.

The GitLab Workflow is now officially maintained and supported by the Editor Group. We’ll be continuing to contribute features, and support the community who was actively involved in our early releases. If you have ideas or feedback, please open an issue.

GitLab Workflow extension for Visual Studio Code now official

Run pipelines in the parent project for MRs from forks

Run pipelines in the parent project for MRs from forks

As a project maintainer, you might want to enable contributions from forked projects that are fully tested by your own project’s CI/CD pipeline. Previously, you’d have to give contributors access to project CI runners, CI configuration, and CI variables, which is something many development groups aren’t comfortable doing. Now, GitLab allows parent project members with the appropriate permissions to run a pipeline for an MR submitted from a fork using the parent project’s CI/CD configuration. It also shows a warning dialog explaining the risks before starting the pipeline so you can better mitigate potential risks.

ECS task definition from local JSON

ECS task definition from local JSON

Today, GitLab’s ECS deployment template updates existing task definitions that are already defined in your attached AWS account. It’s also common to update your task-definition as part of your GitLab flow. Now, you can update the JSON task definition in your local repository and push it knowing the task will get appropriately created in the AWS account, improving your standard development flow.

Project access tokens

Project access tokens

Project level access tokens allow access to a project without the need to provision a new GitLab user. Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API. Project access tokens will be authorized as Maintainers. This new functionality will make programmatic access to GitLab easier and more secure.

Project access tokens

Visualization of Directed Acyclic Graph (DAG) pipelines

Visualization of Directed Acyclic Graph (DAG) pipelines

You may have noticed the new DAG tab on your pipelines that visually renders the directed acyclic graph dependencies for pipelines using the needs keyword. This makes it easier to understand complex webs of dependencies in your CI/CD configuration. In this release, we consider the feature officially released and are removing the beta tag! Your feedback is still welcome, as always, so let us know what you think.

Visualization of Directed Acyclic Graph (DAG) pipelines

Edit Feature Flag User Lists from the UI

Edit Feature Flag User Lists from the UI

You can now create, edit, and delete Feature Flag user lists directly in the UI. Previously, you could only perform these actions via the API. Add or remove users to the list quickly and easily, as well as change the name of the list.

Edit Feature Flag User Lists from the UI

Multi-line comments for merge requests

Multi-line comments for merge requests

Commenting on a specific line in a merge request diff is a great way to leave feedback for the author. Reviewers often need to comment on an entire section of the code, for example a function or expression which covers multiple lines of code. Leaving a comment on a single line, while referring to many lines, makes communication less clear and less efficient.

With the introduction of multi-line comments, reviewers will no longer need to decide which single line of code to choose during a review, instead they will be able to provide feedback to multiple lines in the merge request diff.

Future iterations will include multi-line suggestions as well as increased ease of use. You can follow along in the multi-line comments epic.

Multi-line comments for merge requests

13.3 Other improvements in GitLab 13.3

Compliance Dashboard shows more information

Compliance Dashboard shows more information

Organizations need visibility into the compliance status of their groups and projects. A major component of compliance is the merge request; it is often the primary gating mechanism to ensure the appropriate policy and process has been followed. As such, one of the most important details of a merge request to highlight is to indicate the separation of duties between author and approver.

Now, within the Compliance Dashboard, you can view both the merge request author and the approver(s), enabling you to more quickly hone in on the projects that may not have maintained separation of duties.

Merge Request Analytics

Merge Request Analytics

Many organizations, including GitLab, use throughput as a way of measuring how fast a team can do work. We’re now introducing a first iteration of Merge Request Analytics to help your team better understand the rate of merged MRs in your projects.

Available at the project level, Merge Request Analytics can help an engineering team quickly understand MR activity at a glance. Users interested in a more detailed look—for example, a team lead interested in MRs with a specific label—are also able to filter and see a detailed list of relevant MRs.

Merge Request Analytics

Prevent forking outside a group

Prevent forking outside a group

Group administrators can now prevent the projects within their group from having new forks created outside of the current top-level group. This new setting gives group administrators additional mechanisms to protect their group’s intellectual property.

Display a single file when reviewing merge requests

Display a single file when reviewing merge requests

Reviewing merge requests diffs is an essential task when reviewing code contributions, as this is where most of the communication between author and reviewer takes place. However, as merge requests become larger and more files are involved, navigation and performance of merge request diffs can become difficult.

To resolve this, GitLab 13.3 introduces an option to see one file at a time on the Changes tab of merge requests. It provides a cleaner workspace and enhances the reviewer focus on one single file. At the bottom, you can navigate between the files changed by clicking the Prev and Next buttons. It can be optionally enabled through user preferences.

Thanks to GitLab user Osher for contributing to the initial iteration.

Concurrent Git repository backups

Concurrent Git repository backups

Backups protect against data loss events and should be run regularly, and before maintenance and upgrades. For this reason, GitLab has a gitlab-backup script so that system administrators can back up everything. As the number and size of repositories increases, backing up repository data using the script becomes impossibly slow.

A significant reason why the script is slow is that repositories are backed up one by one. This underutilizes the available CPU and memory resources, particularly when there are multiple Gitaly nodes. Adding concurrency allows multiple repositories to be backed up at the same time, significantly reducing backup time.

Drag and drop to reorder designs

Drag and drop to reorder designs

If you are using GitLab to design a product with screens or a user flow, you’ll want to place your designs in a specific sequence to present the full concept to your team.

Previously, designs were only displayed in the order in which they were uploaded, complicating reviews and leading to frustration.

As of 13.3, you can now drag and drop your designs into any order! The order is saved so that anyone who views your designs will see the order you intended. Go forth and create the flows you imagine or re-order to match your frames in Figma or Sketch!

Drag and drop to reorder designs

Find references added to Code Intelligence

Find references added to Code Intelligence

Code review is an important process that requires an understanding of the proposed change and surrounding code to know if it has been made in a maintainable way. GitLab’s native Code Intelligence helps developers navigate code and understand changes introduced in merge requests. This is important to understand existing code as well to ensure new code is added in a responsible way.

GitLab 13.3 introduces the ability to display references for projects using GitLab’s native Code Intelligence. Clicking on an object in your code will display the definition and offer the ability to browse references on the second tab, displaying the full path and line number where the object is being used.

Future iterations will include API support and displaying the code for references in the popover. You can follow along in the Code Intelligence epic.

Find references added to Code Intelligence

Gitaly Cluster reference transactions

Gitaly Cluster reference transactions

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. Write operations are currently replicated asynchronously however, which means that the GitLab server only has one copy of the change from when the write is accepted, until replication is complete.

Transactional write operations to Git repositories in GitLab 13.3 causes changes to be broadcast to all Gitaly nodes. Only the Gitaly nodes that vote in agreement with the primary node persist the changes to disk. Dissenting nodes are brought in sync by asynchronous replication. This means the change will typically be written to all Gitaly nodes when the write is accepted. This is not guaranteed, however, because all replica nodes could vote against the primary. Quorum-based voting (beta) can be enabled to prevent this.

Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.

Transactional writes for Gitaly Cluster (beta)

Transactional writes for Gitaly Cluster (beta)

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. However, because write operations are currently replicated asynchronously, the GitLab server only has one copy of the change initially.

In GitLab 13.2, transactional write operations to Git repositories can be enabled for Gitaly Cluster. When this option is enabled and an update is pushed to GitLab, the write operation will be proxied to the replica Gitaly nodes. The write operation will be coordinated between the Gitaly nodes using the two-phase commit protocol, so that they agree on the new state of the repository. Write transactions are currently limited to operations pushed over the HTTP and SSH Git interfaces, and does not include write operations via the GitLab interface like the Web IDE.

Audit logs for CI/CD group variables

Audit logs for CI/CD group variables

When you can’t track changes to CI/CD variables, it’s difficult to understand what might have caused your pipeline to fail. Now, in our first iteration of variable audit logs, you can track changes to group-level CI/CD variables. This new audit log captures three events: group variable additions, removals, and protected state changes.

CI linter now can provide warnings in addition to errors

CI linter now can provide warnings in addition to errors

The CI linter can now provide warnings in addition to error messages when validating your .gitlab-ci.yml file. This gives us the opportunity to provide more guidance when evaluating your pipelines, thereby making it easier to avoid more kinds of mistakes by catching them earlier.

Our initial iteration is to provide a warning when the when:always rule is used without workflow:rules; this scenario causes duplicate pipelines when an MR is created and has also been a source of confusion. And in addition to displaying this new warning message on the linter page, it will also appear on the pipeline view and run pipeline page to help you improve your CI configurations.

Configure a job artifact to never expire

Configure a job artifact to never expire

As a developer, you have the ability to specify a job artifact’s exact expiration date, but there are scenarios where you may need to retain an artifact forever. Now, you can set an artifact to never expire by setting the value of expire_in to never in your CI configuration.

Improve Fail Fast Testing Template

Improve Fail Fast Testing Template

We introduced the Fail Fast Testing template in GitLab 13.1 and gathered feedback from internal stakeholders. We found that if the default image was being overridden in a .gitlab-ci.yml file, the template would not work. We’ve since improved the Fail Fast template so you can now trust the the Fail Fast Template to work out of the box, even if you specify a different image.

View and manage group Runners

View and manage group Runners

We’ve added a new group management user interface (UI) for managing your organization’s Runners. In this new UI, you can view, edit, pause, and stop any Runner that’s associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.

View and manage group Runners

Use CI job token to publish NuGet packages

Use CI job token to publish NuGet packages

You can use the GitLab NuGet Repository to build, publish, and share .NET packages, right alongside your source code and CI/CD Pipelines. However, previously you couldn’t authenticate with the repository by using the pre-defined environment variable CI_JOB_TOKEN. As a result, you were forced to use your personal credentials for making updates to the NuGet Repository, or you may have decided not to use the repository at all.

Now it is easier than ever for you to use GitLab CI/CD to publish and install NuGet packages using the pre-defined CI_JOB_TOKEN environment variable.

Rename Feature Flag user strategies

Rename Feature Flag user strategies

In an effort to simplify the Feature Flag strategies and prevent confusion we have renamed them. Percent rollout (logged in users) has been changed to Percent of users and List has been changed to User List.

Rename Feature Flag user strategies

Set a deploy freeze in the UI

Set a deploy freeze in the UI

This feature expands on the API capability of setting a deploy freeze window, which we introduced in 13.0. Now, from the GitLab UI, you can easily set a time period when deployments can’t occur. You no longer have to use the API to script your deploy freeze or use .gitlab-ci.yml. Instead, you can easily go to the UI settings to create a recurring or one-time deploy freeze.

Set a deploy freeze in the UI

Use API to source Pages domain configuration

Use API to source Pages domain configuration

You can now configure GitLab Pages to source a project’s configuration through the GitLab internal API, and take advantage of the API for quicker GitLab Pages daemon booting times.

Create GitLab issues from PagerDuty Incidents

Create GitLab issues from PagerDuty Incidents

You can now generate GitLab issues from PagerDuty incidents, automatically notifying your responders when alerts are triggered, and centralizing your responses within GitLab.

Display metrics in alerts from externally-managed Prometheus

Display metrics in alerts from externally-managed Prometheus

When you receive alerts, GitLab helps you reduce investigation time by including the relevant metrics chart in the alert, helping you visualize what went wrong. In GitLab 13.3, we are introducing including metrics from an externally managed Prometheus instance within the alert.

Display metrics in alerts from externally-managed Prometheus

Manually create Incidents from the Incidents List

Manually create Incidents from the Incidents List

When maintaining the availability and reliability of a service, you don’t always learn of problems from your alerting systems: customers report outages, or team members spot anomalies. Regardless of the source, you can now manually create Incidents from the Incident List to mobilize your response teams when you learn of a problem.

Manually create Incidents from the Incidents List

Simpler, streamlined Metrics dashboard control bar

Simpler, streamlined Metrics dashboard control bar

Previously, dashboard actions such as creating, editing, duplicating, and adding metrics were scattered across the metrics dashboard. GitLab 13.3 organizes these items into a single actions menu, simplifying access to dashboard management features.

DAST vulnerability evidence

DAST vulnerability evidence

Vulnerabilities that have been found by a DAST scan can be difficult to reproduce, since the vulnerability might be reproduced only under certain circumstances. It can also be difficult to pinpoint what code is responsible for the issue when attempting to fix it. Evidence of the vulnerability discovered by the DAST scan is now included in the vulnerability details, making reproduction and remediation easier.

Container Network Policies Controls

Container Network Policies Controls

Container Network Policy Controls provide an easily discoverable way to find the documentation on how to install and uninstall Container Network Policies for a Kubernetes cluster. You can access these controls, along with a visual indicator of the current Container Network Policies status, in the Operations > Kubernetes > Applications page’s new GitLab Container Network Policies section.

Container Network Policies Controls

GitLab chart improvements

GitLab chart improvements

  • It is now possible to configure a dependency proxy for upstream images/packages in the GitLab Helm chart. Note that backup and restore, and migration from Omnibus are not currently supported. To learn more about dependency proxy, see Dependency Proxy. For configuration instructions, see Configure Charts using Globals.
  • The settings to configure object storage have been consolidated so that object storage for all objects can be configured by one section in values.yml. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for pre-signed URLs. For more details, refer to the Object Storage documentation.
  • For improved aggregation, the Workhorse log is now output in JSON rather than as unstructured data. For more details, see the related issue.

PostgreSQL 12 is now available

PostgreSQL 12 is now available

PostgreSQL 12 is now supported as an opt-in PostgreSQL version for self-managed installations of GitLab. PostgreSQL 12 includes a number of performance improvements such as improved query performance for large data sets. For a full list of improvements, see the PostgreSQL release page. Support for using PostgreSQL 12 with a PostgreSQL cluster and Geo sites will be coming soon. For more details on support for PostgreSQL 12 in GitLab, see the PostgreSQL 12 epic. PostgreSQL 12 is scheduled to become the default version of PostgreSQL in GitLab 13.6, but it will still be possible to opt out of this version.

Faster rendering of rich content

Faster rendering of rich content

One of the common tasks users perform in the GitLab UI is viewing rich content, for example rendered markdown in an issue, a merge request, or just viewing a file. For large content, this can take a long time to complete, resulting in a lengthy wait.

In GitLab 13.3, we have optimized how this content is generated, improving user experience and reducing load on the server. The GitLab changelog, a 14,000 line markdown file, now takes 20 seconds to view instead of 35, for a 40% improvement!

Unfurling a URL in tools like Slack provides useful context for other team members. In GitLab 13.3, search result pages have updated meta headers to provide a better description when unfurled.

Links to search results now unfurl in tools like Slack

Performance Improvements

Performance Improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!

Some notable performance improvements in GitLab 13.3 are:

Create multiple custom value streams

Create multiple custom value streams

In this release, we’re making customizable Value Stream Analytics (VSA) even better by allowing teams to create multiple custom value streams. Customizability in VSA allows teams to have detailed understanding of a group’s activity, and you’re now able to create and reuse your customized stages in this feature without needing to re-create them each time.

This is ideal for projects and groups collaborating across multiple departments, where each department may measure value differently. A project manager may want to see a value stream defined by issue labels, but an engineering team may want to understand merge request activity and time to deploy. With multiple value streams, you’re now able to create and customize separate value streams for both.

Create multiple custom value streams

Option to disable unknown sign-in email notifications

Option to disable unknown sign-in email notifications

We have improved the logic for unknown sign-in email notifications so that users receive fewer emails. We recommend leaving unknown sign-in email notifications enabled, but GitLab administrators will now also have the option to disable unknown sign-in email notifications for their instance. This option can be used in cases where users cannot accept cookies in their browser and users’ IPs change often.

Set default role for SAML SSO users

Set default role for SAML SSO users

To simplify the group member onboarding flow, GitLab 13.3 introduces the ability for group owners to set any role as the ‘Default membership role’ for users added to the group by SSO or SCIM. Previously all group members added to the group by SSO or SCIM were assigned the ‘Guest’ role by default.

Toggle epic confidentiality

Toggle epic confidentiality

As confidential work becomes ready to be shared on a more public level, it can be difficult to share a collection of issues and their parent epic. You can now toggle the confidentiality of your epics, enabling or disabling visibility for those with the proper access.

Toggle epic confidentiality

Display non-Markdown content in the WYSIWYG Static Site Editor

Display non-Markdown content in the WYSIWYG Static Site Editor

Static site generators often rely on Markdown to organize content and the Static Site Editor offers an intuitive WYSIWYG Markdown editing experience for those documents. However, their content isn’t always written in Markdown. Many generators support additional markup embedded in the Markdown to extend the author’s capabilities. It is also valid to write HTML alongside markdown content.

The Static Side Editor’s WYSIWYG mode now separates non-Markdown content into uneditable content blocks, displayed inline with your content. This prevents unexpected formatting errors that can arise when the editor attempts to convert non-Markdown content to HTML. The non-Markdown content is still editable in the raw source mode of the Static Site Editor and future iterations will enable safely editing this kind of content within the WYSIWYG mode.

Enhanced Web Editor

Enhanced Web Editor

We’ve upgraded the web editor to a lighter-weight version of the editor found in our Web IDE. This adds 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 make it easier to edit and collaborate on files in projects.

Enhanced Web Editor

Gitaly Cluster read distribution

Gitaly Cluster read distribution

Repositories with many contributors combined with highly parallelized CI pipelines, or highly variable project access patterns can cause high CPU and memory usage, decreasing availability. Mitigating these performance problems by sharding generally results in over-provisioning to handle peak load.

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes, and can be used to scale performance by distributing read operations between up-to-date replicas. From GitLab 13.3, when using Gitaly Cluster, read operations will automatically be distributed between up-to-date replicas. This better utilizes the available CPU and memory resources, and scales better in comparison to sharding. Read the Cluster or Shard documentation to learn more about the benefits of Gitaly Cluster.

Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.

Squash Commits Options

Squash Commits Options

Squashing commits in Git is a great way to combine several commits into a single one. It’s great for grouping several commits, which by themselves may provide little historical value, into a single large commit before pushing upstream. Pushing a single commit allows for a more meaningful commit message, as well as ensuring the group of commits provides a “green” continuous integration pipeline.

In GitLab 13.3 we are adding configurable defaults for squashing commits, allowing project maintainers to configure the option to suit their preferred workflow. Because changing squash configuration may introduce unwanted behavior, configuration has not been changed for new or existing projects. With 314 upvotes 👍, this is one of the most highly requested improvements by the community and we hope it allows more users to use this powerful feature.

Squash Commits Options

WIP merge requests renamed Draft merge requests

WIP merge requests renamed Draft merge requests

WIP (work in progress) status for merge requests provide a clear signal to reviewers that the merge request in question is not yet ready to be merged.

In order to use a more inclusive and self-explanatory term, the WIP (work in progress) feature for Merge Requests has been renamed to “Draft”. This term clearly communicates the MR in question is not ready for review as well as not making any assumptions about the progress being made towards it. Additionally, it reduces the cognitive load for new users, non-English speakers, and anyone not familiar with the WIP acronym.

WIP merge requests are now deprecated in favor of draft merge requests, however both terms will be supported until the next major GitLab release (14.0), after which it will be removed.

Better linting for .gitlab-ci.yml files

Better linting for .gitlab-ci.yml files

When reviewing your CI definitions, you can now use our CI linter to go deeper into pipeline processing to validate the correctness of your .gitlab-ci.yml. The CI linter provides feedback not only for syntax validation, but it also validates other kinds of logical errors and invalid configurations by simulating the pipeline as if you were running on master (without actually running anything). This helps you produce a properly configured pipeline faster and helps you avoid situations where a pipeline passed the linter but still could not run.

CI/CD rules:if support logical expressions with parentheses

CI/CD rules:if support logical expressions with parentheses

If you use the rules keyword with if clauses, it’s now even more powerful, with support for bracketed expressions evaluated by the pipeline processor. You can use more complex and efficient AND (&&) / OR (||) expressions, making your pipelines rules more logical, powerful, and easier to manage.

GitLab Runner 13.3

GitLab Runner 13.3

We’re also releasing GitLab Runner 13.3 today! GitLab Runner is the lightweight, highly-scalable 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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

JUnit Report Improvements

JUnit Report Improvements

We introduced the JUnit report in GitLab 12.5 which provides a view of all JUnit tests that run in a pipeline. The wider community helped identify some readability and usability issues in the report interface that made it hard to use, especially when the names of tests or suites exceeded a specific number of characters. Additionally, performance of the page could be slow when parsing very large files or a large quantity of junit.xml files. Now, you’re presented with a JUnit report that’s easier to read and you can take confidence in the fact that the pipeline page will load quickly even when loading thousands of tests. This feature is no longer behind a feature flag by default and is enabled for all users on GitLab.com.

Improved presentation of package metadata and activity

Improved presentation of package metadata and activity

The GitLab Package Registry is where you store and share a variety of package formats. When you navigate to the user interface, you want to quickly understand how the package was built and how to install it. We’ve redesigned the package details page to prioritize recent activity, code snippets, and additional metadata. We removed the two-column table that had data that was duplicated or not useful.

The main section of the package detail UI now includes:

  • A new “History” feed that shares the time-based metadata related to a package.
  • The installation commands and registry setup instructions.
  • A way to add “Additional Metadata” to capture any metadata not related to time. This additional metadata section offers the flexibility of including a variety of details specific to different package formats.

This change is a clear sign that the Package Registry capabilities with GitLab are maturing. The ‘ugly’ table that we removed was a carry-over from the original Maven Repository. Back then, we only presented basic metadata like name and created_date. Now you can see how a package was built and trace back to which pipeline and which commit was responsible. We look forward to the continued evolution of this product. Enjoy and let us know what you think!

Confirmation dialog before regenerating Feature Flag instance ID

Confirmation dialog before regenerating Feature Flag instance ID

It is too easy to accidentally regenerate an instance ID for a feature flag when you actually intend to copy the instance ID. If the instance id gets regenerated, you need to update it in your application and then restart the application in all environments. Now there is a confirmation step that requires you to type the name of the project before regenerating the ID. This will greatly reduce the risk of unintentional ID regeneration.

Confirmation dialog before regenerating Feature Flag instance ID

Until now, you weren’t able to see Review App links on a Merge Request if you weren’t a member of the respective project where the MR was originally created. In 13.3, we have made review apps accessible to any user, allowing you to get feedback on your code changes from anyone, even your customers. By allowing everyone to contribute, you can better collaborate and shorten your feedback loop.

Track deployment events in GitLab with webhooks

Track deployment events in GitLab with webhooks

GitLab has made it easier for you to build deployment automation with a webhook that supports successful, failed, and canceled deployments.

Add runbooks to GitLab Alerts

Add runbooks to GitLab Alerts

When an incident occurs, knowing how to respond can be difficult if the on-call engineers didn’t write the code causing an incident. Having access to runbooks, or knowledge about a metric causing alerts, is critical to identifying the root cause of a problem and solving it quickly. You can now add runbooks to the alerts you configure in GitLab so that triggered alerts provide your on-call team the steps needed to resolve the issue.

Add runbooks to GitLab Alerts

Display metrics dashboard data in gauge format

Display metrics dashboard data in gauge format

We’ve introduced gauge charts as a new visualization option on your monitoring dashboard to show progressive values for a single metric.

Display metrics dashboard data in gauge format

When triaging alerts, there’s no time to lose: you must investigate quickly without context-switching. GitLab 13.3 saves you time by linking from the chart, located in the Metrics tab of an alert, to the logs for a metric.

Link alerts from GitLab-managed Prometheus to logs

Organize Incidents by status in list view

Organize Incidents by status in list view

When coordinating response teams across multiple incidents, it’s extremely important to know which Incidents are open - and require immediate attention - and which ones are resolved and closed. GitLab 13.3 now separates Incidents by status and organizes them into tabs, helping you to focus on the relevant, open Incidents.

Organize Incidents by status in list view

Additional details on Project Security Dashboard

Additional details on Project Security Dashboard

The Project Security Dashboard is getting even more useful with the addition of new data fields to the vulnerability list. Putting more details on the main dashboard provides an even better overview of a project’s vulnerabilities without having to open the individual vulnerability pages.

For scanners that run against source code, you can now see the line number in the vulnerable file. We’re also including the scanner type (SAST, DAST, etc.) which you can filter by. This makes it easy to quickly drill into a specific subset of vulnerabilities.

We’ve also improved the display of vulnerability identifiers. Many scanners can include more than one identifier for a given vulnerability such as a CVE, CWE, or a proprietary ID. Previously, we picked the first identifier provided to display on the vulnerability list. Now, we always show the CVE if one is available. We also indicate the total number of other identifiers.

Additional details on Project Security Dashboard

We’re enhancing the Vulnerability Management workflow by enabling users to link existing issues to vulnerabilities. Previously, you could only associate a single issue with a vulnerability by creating a new issue from the vulnerability record. These issues were automatically created in the same project as the vulnerability record.

With this new functionality, you can link one or more existing issues to a vulnerability. It is also possible to link issues from other projects. This provides security and development teams greater flexibility and visibility when managing vulnerabilities, especially across projects.

Link existing Issues to a Vulnerability

Geo is faster and easier to maintain

Geo is faster and easier to maintain

Geo replicates data from a primary Geo node to one or several Geo secondary nodes. Backfilling data to secondary nodes as quickly as possible is critical to ensure that secondary nodes don’t fall too far behind.

After a number of iterations (51 MRs!), Geo no longer requires PostgreSQL Foreign Data Wrappers (FDW). This eliminates the possibility of some database timeouts and increases the overall performance of backfill operations. Additionally, this change reduces a step when configuring Geo and makes it easier to maintain a Geo deployment. To give an idea of the reduction in complexity, this change resulted in 3,823 net lines of code being removed.

Omnibus improvements

Omnibus improvements

  • To prevent PostgreSQL upgrade failures due to insufficient space, and to make the upgrade experience smoother, GitLab now checks to make sure you have sufficient free space before performing a PostgreSQL upgrade with the pg-upgrade command.
  • It is now easier to specify a timeout value for PostgreSQL upgrades. Previously, the timeout value for pg-upgrade could only be specified in units of milliseconds. It is now also possible to specify the value in days, hours, minutes, seconds, or milliseconds, or some combination of these. For example, 1d2h3m4s5ms.

Faster loading of content with many references

Faster loading of content with many references

One of the benefits of GitLab being a single application for DevOps, is that it is really easy to link content together. We support referencing labels, milestones, snippets, commits, merge requests, issues, and epics in all parts of GitLab. It is not uncommon for a single piece of content to reference tens or even hundreds of other items. This connectedness however can cause delays in rendering the content to users, as the GitLab server needs to look up each reference to present additional context.

In GitLab 13.3, the performance of reference lookups has been improved significantly. For a sample piece of content with 165 references, it was generated 75% faster with half the memory footprint, resulting in a significantly faster user experience with less load on the GitLab server.

The current code analyzer for the Elasticsearch integration doesn’t take all code cases into account. For example, if you have a file with a.b.c=one_two_three and you search for one_two_three, you wouldn’t get the file returned in the search. In GitLab 13.3, we have improved the code analyzer in Elasticsearch, and it is now more robust at matching searches with special characters.

Deprecations Deprecations

Debian Jessie and Raspbian Stretch to be deprecated

Debian Jessie and Raspbian Stretch to be deprecated

Debian Jessie and Raspbian Stretch hit end of life in June 2020. GitLab 13.3 is the last supported version for these distributions. Please visit the Deprecated OSes page for more information.

Planned removal date: GitLab 13.3

Deprecate Container Registry log formatters

Deprecate Container Registry log formatters

Currently, GitLab supports text/json/logstash log formatting for app logs and text/json/combined for access logs. We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options, text (for development) and json.

Planned removal date: January 22nd, 2021

Deprecate Container Registry logging hooks

Deprecate Container Registry logging hooks

The Container Registry supports logging hooks, which currently can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Planned removal date: January 22nd, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich and better-supported alternative. To do this we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to remove the redis.pool.maxidle and redis.pool.maxactive settings and add redis.pool.size (maximum number of connections), redis.pool.miniddle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused).

Planned removal date: January 22nd, 2021

Deprecate Container Registry proxy pull-through cache

Deprecate Container Registry proxy pull-through cache

After a recent survey of GitLab Admin, we’ve decided not to deprecate this feature.

The proxy section allows the Container Registry to be set up as a local mirror to an upstream repository.

Planned removal date: Postponed indefinitely

Deprecate Container Registry support for Bugsnag

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Planned removal date: January 22nd, 2021

Deprecate Container Registry support for NewRelic

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Planned removal date: January 22nd, 2021

Deprecation of SAST_EXCLUDED_PATHS in Secret Detection Template

Deprecation of SAST_EXCLUDED_PATHS in Secret Detection Template

To keep our managed CI templates consistent and streamlined, we are renaming the SAST_EXCLUDED_PATHS variable in the Secret Detection CI template to SECRET_DETECTION_EXCLUDED_PATHS. This will consistently name all Secret Detection CI template variables to start with SECRET_DETECTION_. Please note that SAST_EXCLUDED_PATHS is still a valid variable in the SAST CI template. This change only impacts the Secret Detection CI Template. To transition, if you use a customized Secret Detection CI template, update the name of the variable in your template. If you use Auto DevOps or inherit GitLab’s managed Secure templates, no action is required.

Planned removal date: August 22, 2020

Geo Foreign Data Wrapper settings deprecated

Geo Foreign Data Wrapper settings deprecated

Since GitLab 13.2, Geo does not require Foreign Data Wrappers (FDW) to be configured for data replication. As a result, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:

  • geo_secondary['db_fdw']
  • geo_postgresql['fdw_external_user']
  • geo_postgresql['fdw_external_password']
  • gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']

Planned removal date: GitLab 14.0

WIP (work in progress) merge requests term deprecated

WIP (work in progress) merge requests term deprecated

We renamed the WIP (work in progress) term for merge requests to “draft”, because it’s more inclusive and self-explanatory. The WIP term is now deprecated. We will support its use through the next major GitLab release (14.0), after which it will be removed.

Planned removal date: Apr 17, 2021

Removals and breaking changes Removals and breaking changes

Geo rake task to refresh foreign tables removed

Geo rake task to refresh foreign tables removed

Since GitLab 13.2, Geo does not require Foreign Data Wrappers (FDW) to be configured for data replication. As a result, the rake task geo:db:refresh_foreign_tables is no longer needed and has been removed in this version.

Removal date: GitLab 13.3

Removal of SAST Secret Detection job in favor of new template

Removal of SAST Secret Detection job in favor of new template

Since GitLab 13.1, the Secret Detection CI/CD configuration settings are now provided in a separate GitLab-provided template and run as a new Secure scan type. This new Secret Detection template is also now included in Auto DevOps for easy setup.

In 13.4 we will remove the old SAST secrets-sast job definition and if you have not switched to the new Secret Detection template you will not continue to scan for secrets. You can easily transition by adding the new template.

Before upgrading to GitLab 13.4 we recommend you add the new Secret Detection template to your gitlab-ci.yml file, and then remove the old SAST secrets-sast job definition from the SAST configuration template in SAST.gitlab-ci.yml file. We have made a video to guide you through the process of transitioning to this new template.

You can follow the removal issue for further details.

Removal date: September 22, 2020

Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

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

GitLab Subscription Plans 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 CC0

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source