13.1

GitLab 13.1 Release

GitLab 13.1 released with Alert Management and Code Quality Enhancements

GitLab 13.1 released with Alert Management, Code Quality, Security & Compliance Improvements

GitLab 13.1 is now available, bringing you expanded alert management, new tools to help you track and improve code quality, and more ways to keep your code secure and compliant.

Automate and expand Alert Management

Alerts are essential to application maintenance, but understanding and triaging the range of alerts thrown can dramatically reduce productivity and response time. GitLab’s Alert Management aggregates and ranks IT alerts from all of your services to simplify assessment and remediation, increasing productivity and helping you research and address critical issues right away. Key features in 13.1 include alert assignments, Slack integration, and creating GitLab To-Dos when assigning alerts.

Improve code quality

Deployment velocity only matters if you’re deploying high quality code. By prioritizing tests on recently modified code, developers can address errors immediately, without running an entire test suite. Code coverage tracking over time surfaces quality trends to developers and managers alike, and native code intelligence boosts the speed and accuracy of code reviews by integrating reference material directly into GitLab.

Enhance and extend security and compliance

Security matters to everyone, and we're committed to lowering the barriers to a fully secure, compliant SDLC. That's why we're happy to announce that we've migrated Brakeman SAST scanning to Core, allowing every Rails developer—at every product tier—to scan their source code for known vulnerabilities. For compliance-focused organizations, we've released a policy management UI for network container policies, and we've enabled group-level vulnerability exports to a CSV file for audits or further internal review. In addition, we've made helpful UX improvements to the Security Dashboard, adding persistent filters and issue status icons to help maintain context as you work within the tool.

And much more!

These are just a few of the highlights in 13.1. For this release, we also achieved a new milestone in terms of community contribution. For the first time, more than 300 MRs from the wider community were merged during the release period, and we appreciate everyone's contributions! Read on to learn more about other fantastic productivity improvements, such as Accessibility Testing MR Widgets, Design Thread Resolutions, Pipeline Success Notifications, and more!

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

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Jacopo Beschi

Jacopo added new email notifications when pipelines are fixed. Until now, GitLab sent notification emails when a pipeline failed, but when the pipeline was fixed, no notification of the fix was sent. Developers needed to repeatedly reload the merge request or pipeline views to check the status. This great contribution solves this problem and saves developer frustration.

This contribution took about 8 months, but Jacopo worked on it and managed to get it across the finish line. It received approvals from 5 different reviewers. It’s received great feedback from everyone within GitLab and lots of interest, with over 30 upvotes on the issue, and nearly 70 active conversations related to it.

Jacopo, thanks for this wonderful contribution, we really appreciate it!

13.1 Key improvements released in GitLab 13.1

Manage IT Alerts in GitLab

Manage IT Alerts in GitLab

When firefighting, responders must coordinate multiple tools and evaluate different data sources to collect and assess metrics, logs, and traces. Sharing these with a response team involves screen-grabbing, then copying and pasting data into a single ticket, to keep all stakeholders informed. This work is manual, time-consuming, tiring, and stressful. It leads to alert fatigue, increased stress, sinking morale, and - most importantly - missed alerts.

GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents. We’ve added the ability to triage alerts in a list view, view alert details, assign alerts, update the status of alerts, and create Incident Issues from Alerts.

In GitLab 13.2 and beyond, we plan to improve alert and incident response workflows by integrating with PagerDuty, surfacing relevant metrics and logs on alerts, associating runbooks, and creating an Alert Integration Builder, so your operators can self-serve and seamlessly integrate GitLab with any monitoring tool. To view our progress and suggest ideas for future improvements, see the Alert Management epic.

Manage IT Alerts in GitLab

Set Feature Flag Strategy Across Environments

Set Feature Flag Strategy Across Environments

In this release, we redesigned the feature flags UI to enable setting strategies for multiple environments. Previously, it was much more difficult to manage Feature Flags and set strategies as the number of environments increased. This improvement gives you more flexibility to create and apply strategies to environments at-scale.

Set Feature Flag Strategy Across Environments

Accessibility Testing Merge Request Widget

Accessibility Testing Merge Request Widget

Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. GitLab’s full accessibility report was a start, but using that report to see what has changed in a single Merge Request is a manual and slow process.

In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed.

Accessibility Testing Merge Request Widget

Mark any Design thread as resolved

Mark any Design thread as resolved

When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.

With 13.1, you’ll have the ability to mark any comment as Resolved to signify that it is now complete. Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left! And, of course, if you need to revisit something, all of your resolved threads will be available in the Resolved Comment area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.

We think this will greatly improve your workflow so you can focus on what is important.

Mark any Design thread as resolved

Merge Request Reviews moved to Core

Merge Request Reviews moved to Core

Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process.

Since its introduction, we’ve re-evaluated its place in our buyer-based pricing model and as part of 13.1 we’re excited to announce this feature has now moved to GitLab Core.

Merge Request Reviews moved to Core

Code Intelligence

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. Easily browsing definitions while writing new code or reviewing changes to existing code allows developers to gain a better understanding of the software being written. This is extremely useful when reviewing new code as well as code changes in merge requests. However, setting up browsable definitions generally meant configuring external tools and resources, or using a dedicated IDE. With GitLab, this is no longer the case.

Taking inspiration in the great work done by our partners at Sourcegraph and powered by the LSIF format, GitLab’s native Code Intelligence can be added to any project by adding a new job to the project’s .gitlab-ci.yml file, which specifies an LSIF report. Once generated, hovering over objects in your code will present the available code intelligence actions. No external tools or IDEs required.

Future iterations will include the ability to find references, as well as API support. You can follow along in the Code Intelligence epic.

Code Intelligence

Control Feature Flags with User Lists

Control Feature Flags with User Lists

GitLab already supports the ability to control feature rollout based on user IDs. However, it’s tedious to repeatedly add more users for every flag or environment. To make this process more convenient, we have added a new Feature Flag strategy called “lists.” User lists are created and modified with the API. After creation, use them by choosing the “list” strategy for your feature flag and selecting the appropriate list. If you already have lists created, you can use them right away.

Control Feature Flags with User Lists

Graph code coverage changes over time for a project

Graph code coverage changes over time for a project

All too often, a project has a code coverage target but development teams might not have much visibility into which direction that target value is trending over time. There needs to be an easier way to track changes in code coverage over time without that extra hassle.

The Code Coverage graph now provides better visibility into how code coverage is trending over time. It displays a simple graph of the coverage value(s) calculated in pipelines. We are looking forward to feedback from customers on this feature as we plan improvements and future iterations.

Graph code coverage changes over time for a project

Satisfy requirements from a CI job

Satisfy requirements from a CI job

Now that you’re able to create requirements in GitLab, the next step towards a full requirements management solution is showing your requirements are satisfied.

We’re excited to release the first step by allowing you to configure jobs within the standard CI pipeline that, when triggered, will mark all existing requirements as satisfied. This CI job can be either manual or automatic, and like other CI jobs can be configured to allow failure so it doesn’t block the pipeline from completing. Future iterations will allow selectively satisfying requirements from pipeline testing as well as allowing our customers performing manual verification to indicate satisfied requirements through the interface.

13.1 Other improvements in GitLab 13.1

Add optional expires_at parameter to /user/keys endpoint

Add optional expires_at parameter to /user/keys endpoint

Thanks to Petar Prokic (@pprokic) for this community contribution!

The Users API /user/keys and /users/:id/keys endpoints now support an optional expires_at parameter to define an expiration date for SSH keys. This change can help users and organizations manage the impact of a compromised credential in a regulated environment.

Added projects endpoint for Audit Events API

Added projects endpoint for Audit Events API

Thanks so much to Julien Millau (@devnied) for this community contribution!

GitLab’s Audit Events API has been extended to add an endpoint for projects, enabling group owners to poll the API for specific project-level data. This change makes it easier to find and retrieve the data you need to manage your compliance programs, and build out tooling you need for the auditability and traceability of your GitLab projects.

Issue Analytics allows users to quickly spot trends in issue data. To enhance this ability, you now have a table that lists key details such as issue age, status, milestone, weight, due date, assignees, and author. With this additional visibility, users may now follow the thread of their inquiry beyond the chart and into the specific issues behind the trend.

Explore Trends & Details in Issue Analytics

IP access restriction available in Premium

IP access restriction available in Premium

IP access restriction is now available for Premium and Silver tiers. This feature allows you to restrict access to groups and their underlying content by one or more IP subnets. Enabling IP access restriction ensures that particular content doesn’t leave the premises, while not blocking off access to the entire instance.

Assign issues faster

Assign issues faster

GitLab loves to make user workflows as easy as possible. You can now assign an issue to a commenter, right next to the comment, with the click of a button. This keeps your focus and effort centered around the comments, rather than having to navigate to the side panel or use a quick assign command.

Assign issues faster

Distribute reads across Gitaly Cluster (beta)

Distribute reads across Gitaly Cluster (beta)

Gitaly Cluster allows you to replicate Git repositories on multiple warm Gitaly nodes, improving fault tolerance by removing single points of failure.

In GitLab 13.1, Git read operations can be distributed between up-to-date Gitaly replicas. This makes better use of the available resources, and can improve performance.

This feature is being released as beta while we evaluate its performance under production loads.

Gitaly Cluster automatic failover enabled by default

Gitaly Cluster automatic failover enabled by default

Gitaly Cluster improves fault tolerance of Git storage in GitLab by removing single points of failure, detecting outages, and automatically switching to a replica. From GitLab 13.1, when Gitaly Cluster is configured, SQL leader election and automatic failover are enabled by default.

If unreplicated write operations are detected during failover, the cluster is put into read only mode to prevent a split brain. In the future, strong consistency will require that write operations succeed on multiple Gitaly nodes before responding with a success signal, preventing this problem and the need to mark the cluster read only.

Previously in GitLab 13.0, in memory leader election was default instead of automatic failover.

The Static Site Editor offers immediate visual feedback when writing Markdown content, and intuitive formatting controls to ensure consistent and accurate markup. However, this visual editing experience introduced in GitLab 13.0 was limited to text content.

In GitLab 13.1, you can quickly add images to your pages using the Static Site Editor. After clicking the Image icon in the formatting bar, just link to a URL, add optional ALT text, and you’re done. The link can reference images already hosted in your project, an asset hosted externally on a content delivery network, or any other external URL. The editor renders thumbnail previews so you can verify the correct image is included and there aren’t any references to missing images.

Web IDE Terminal and File Sync moved to Core

Web IDE Terminal and File Sync moved to Core

GitLab 11.6 introduced Web Terminals for the Web IDE. Several releases later, file syncing to the Web Terminal was added, enabling the Web Terminal to interact with changes made in the Web IDE.

Earlier in 2020, GitLab committed to moving 18 features to our open source core product. With this release of GitLab we’ve completed the work to move both the Web Terminal and File Sync utility to Core. We’re excited about bringing these features to more users, and seeing what use cases and workflows you’re able to use them for.

Run tests for modified files first

Run tests for modified files first

As a developer, you want to get feedback quickly about your changes, including results of newly-written tests. In large projects like GitLab, this can be especially difficult with wait times up to 45 minutes just to see a new unit test pass, or — even worse — fail. This slowness can lead you to skip automated test development entirely.

Ruby developers can shorten the feedback loop by using the TestFileFinder gem to find tests that target the modified code, then running those tests in an early stage in the pipeline. This is an MVC approach to solving the problem, but one we hope you’re excited about. We look forward to feedback and ideas in the TestFileFinder project.

Use metadata to understand how your NuGet packages are built

Use metadata to understand how your NuGet packages are built

When a NuGet package is uploaded to GitLab, a job opens the archive and reads the .nuspec file. The package name and version are extracted, but several other fields, like dependencies, project_url and tags are available but not extracted. These fields are useful for understanding how a package has been built and what its dependencies are.

In GitLab 13.1, we are excited to announce that this metadata will now be extracted as part of the upload and included in the user interface so that you validate that package was built properly.

Documentation for blue-green deployments

Documentation for blue-green deployments

We’ve documented an example of a blue-green deployment using NGINX that swaps the deployments directly from the .gitlab-ci.yml file. This example will help you set up blue-green deployments if you’re using a similar configuration, and provides guidance you can customize for other types of applications.

Setting up AWS deployments is not always as easy as we’d like it to be. To make it easier for you to use our AWS features, we’ve added in-product links to our AWS templates and documentation when you start adding AWS CI/CD variables. These links should help you get up and running faster.

In-product link to guidance for deploying to AWS

Simplified setup for integrating Terraform

Simplified setup for integrating Terraform

You can run GitLab-integrated Terraform features more easily with one of the GitLab-provided Terraform images. The GitLab Terraform images extend the official Terraform images for Terraform versions 0.12 and 0.13 beta by including simple commands to use Merge Request widgets without bloating your CI/CD YAML files.

Alert assignments logged in system notes

Alert assignments logged in system notes

The ability to audit alerts is important for feedback and improvement, but there’s rarely time during a fire-fight to document the details you’ll need later. In GitLab 13.1, alert assignments are added to the system notes of an Alert so you can discuss them in your post-incident review.

Alert assignments logged in system notes

Collaborate on GitLab Alerts in Slack

Collaborate on GitLab Alerts in Slack

We’ve added commands to our Slack notifications service so you can forward Alerts to Slack, notifying responders of an outage, and enabling responders to begin collaborating without leaving their central communication platform.

Create GitLab To-Dos when assigning alerts

Create GitLab To-Dos when assigning alerts

Responders can now assign alerts to team members to help organize triggered alerts, delegating problems for investigation by a specific team member. Adding a GitLab To-Do list item tells the team member something needs their attention.

Metric panels are most useful when they facilitate drill-down. In GitLab 13.1, you can add custom URLs to the More actions menu for panels in your metrics dashboard, cross-linking your metrics panel and dashboard with other metrics dashboards and additional troubleshooting tools your team uses.

Metric dashboard panels display external links

Metric dashboards now support UTC

Metric dashboards now support UTC

GitLab 13.1 now enables metrics dashboards to display time in UTC, enabling distributed team members working together to see the same time-series data, regardless of the team members’ physical locations.

Metric dashboards now support UTC

Self monitoring dashboard for Omnibus GitLab users

Self monitoring dashboard for Omnibus GitLab users

In GitLab 13.1, Omnibus GitLab users will have a new out-of-the-box dashboard in their self-monitoring project to monitor the health of their GitLab instance.

Download job artifacts faster and easier

Download job artifacts faster and easier

GitLab allows you to define pipeline job artifacts, making them easy to browse and download in the GitLab UI. Previously, you could only download the entire artifact archive for a pipeline or job.

We wanted to make it faster and easier to quickly access any report artifact file directly. This is particularly useful for Security scanning reports and code quality reports which you may want to download for use in other tools.

With GitLab 13.1 we added support for downloading the following types of individual artifact reports:

  • accessibility
  • archive
  • cobertura
  • codequality
  • container_scanning
  • dast
  • dependency_scanning
  • dotenv
  • junit
  • license_management
  • license_scanning
  • lsif
  • metrics
  • performance

This feature is available for all GitLab users. However, artifact report types vary across GitLab tiers.

Download job artifacts faster and easier

Export vulnerabilities list from Group Security Dashboards

Export vulnerabilities list from Group Security Dashboards

From the Group Security Dashboard, you can now download a CSV file containing detected vulnerabilities for all projects in a group. This export list can then be used for things such as creating compliance reports or as a data source for external dashboards. This joins the ability to export reports from the Instance and Project Security Dashboards.

Simply go to any Group Security Dashboard and click the new ‘Export’ button. Your browser will automatically start the download.

Export vulnerabilities list from Group Security Dashboards

More prominent Secret Detection and new standalone Secret Detection template

More prominent Secret Detection and new standalone Secret Detection template

Secret Detection has been promoted from a sub-feature of SAST to a category of its own. Secret Detection findings are now more visible, displaying in their own section in merge requests and pipeline security tabs. Secret Detection will also now display configuration status on the Security Configuration Page and display findings in Project Security Dashboards.

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. We recommend you implement this new template 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. We will deprecate the old SAST secret job definition in a future GitLab release.

SAST Scanning for Helm Charts

SAST Scanning for Helm Charts

Our Static Application Security Scanning (SAST) analyzer for Kubernetes manifests has been updated to support Helm Charts. This update also adds support for two new environment variables to customize our analyzer settings: KUBESEC_HELM_CHARTS_PATH and KUBESEC_HELM_OPTIONS.

A special thanks to @agixid for their community contribution to this feature.

SAST Scanning for Helm Charts

GitLab chart improvements

GitLab chart improvements

  • The extraEnv pattern is now supported in the GitLab Helm charts. This allows you to expose additional environment variables, such as proxy servers, for specific GitLab charts or globally for all GitLab charts. Refer to the global settings documentation or subchart documentation for details on how to implement extraEnv.
  • Custom annotations configured in the deployment section of the global settings in values.yml are now available in all GitLab subcharts. Deployment annotations allow you to grant access at the deployment level rather than the node level, such as allowing a deployment to read an Amazon S3 bucket without having to grant the entire node access to the bucket. For details on how to set up deployment annotations, see the Annotations documentation.
  • The PostgreSQL libraries and client in the GitLab container images have been updated to PostgreSQL 12 to allow using more versions of PostgreSQL. Note that GitLab 13.1 still only supports PostgreSQL 11, but support for PostgreSQL 12 is planned for a future release.
  • For improved security, you can now pass a Kubernetes secret for sensitive header values such as Authorization token for the endpoints when configuring Registry notifications. For setup, see the Registry chart documentation.

Omnibus improvements

Omnibus improvements

  • GitLab packages are now available for Raspbian Buster. To download and install GitLab on Raspbian Buster, visit the Install page.
  • New documentation has been added to the Database Settings page to explain how to upgrade an external PostgreSQL database.
  • The version of NGINX bundled in Omnibus GitLab has been updated from 1.16.1 to 1.18.0.
  • The expiration of the GPG key used to sign GitLab Omnibus packages has been extended to July 2021. If you validate the signatures of the Omnibus package for your installation, you must also update your copy of the signing key. Note that this key is separate to the repository signing key that was updated in April 2020. See the Omnibus documentation for instructions on how to update the key.
  • GitLab 13.1 includes Mattermost 5.23, an open source Slack alternative. The newest release includes automatic hyperlinking to Jira issues and more. This version also includes security updates, and upgrade from earlier versions is recommended.

Improved Search API response time

Improved Search API response time

If you’ve ever used the search API, you might have noticed that some scope searches were averaging a response time of over 11000ms. This was clearly not very efficient.

In GitLab 13.1, we addressed some N+1 database calls and as a result, we saw a 40% improvement in the response times! Scope searches have never been faster.

Search in a group from a project in the search box dropdown

Search in a group from a project in the search box dropdown

In GitLab 13.1, the search dropdown now gives you the option of searching in the group from a project that belongs to the group. Before GitLab 13.1, the search dropdown options did not include in this group if searching from a project.

Search in a group from a project in the search box dropdown

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!

In GitLab 13.1, we’re shipping performance improvements for CI pipeline processing, viewing git blame, and much more! Some improvements in GitLab 13.1 are:

Added audit event when a new SSH key is created via the API

Added audit event when a new SSH key is created via the API

Thank you to Rajendra Kadam (@raju249) for this community contribution!

When an SSH key is created for a user via the API, either by the user or an administrator, you will now see this action logged in the audit events table. Previously, these actions were not logged and created a gap in the auditability of SSH credentials for a user.

Contribution Analytics now show approvals

Contribution Analytics now show approvals

Contribution Analytics helps teams understand how workload is balanced across many participants. Until now, the contributions of merge request approvers were overlooked, despite their valuable role in ensuring merge requests receive an appropriate level of review. The table of contributions per group member now includes a sortable Approved MRs column to display approvers by the number of approvals completed.

Contribution Analytics now show approvals

Group membership allow list supports multiple email domains

Group membership allow list supports multiple email domains

In GitLab 13.1, Owners can now restrict group membership to users with email addresses across multiple domains instead of a single domain. This new configuration option will give you greater flexibility while securing access to your group.

Group membership allow list supports multiple email domains

New API for generating user access reports

New API for generating user access reports

One of the most important aspects of compliance is knowing who can access your business systems and resources. You need to know what role or permissions they possess so you can audit that access against your policies. Generating this type of evidence should be easy, so we’ve added a new API to provide group and project memberships for a user. You can now programmatically list all of the groups and projects a user belongs to along with their respective role for each resource. You no longer need to search through groups, projects, and logs to aggregate this data.

Issue titles are now sticky

Issue titles are now sticky

Issue titles will now always remain visible at the top of the issue, regardless of what part of the issue you’re reading. This ensures that you’ll always have context, regardless of whether you’ve clicked a link to a deep conversation thread, scrolled deep within an issue, or you’re working with multiple tabs of similar issues.

Issue titles are now sticky

EditorConfig support in the Web IDE

EditorConfig support in the Web IDE

Developers collaborating on projects follow certain coding standards and styles to maintain consistent levels of readability and formatting in the project. This configuration is often done through an .editorconfig file inside of the project which provides instructions like indent style, indent size, and line endings.

When opening a file, the Web IDE looks for a file named .editorconfig in the current directory and all parent directories. If a config file is found and has settings that match the file’s path, the settings will be enforced on the opened file. The Web IDE provides support for most of the widely supported features of EditorConfig with an exception for charset.

Hide YAML front matter in the Static Site Editor

Hide YAML front matter in the Static Site Editor

Static site generators consume the first few lines (“front matter”) at the beginning of a Markdown file, between two --- lines, to format, configure, or parse the page. Front matter isn’t meant to be displayed alongside the content of the page, and must conform to specific formatting rules.

GitLab’s Static Site Editor now includes a rich content editing experience that parses the Markdown syntax and displays it in a more familiar style. However, the front matter, not being intended for display, gets rendered unexpectedly in this context, and editing it using the visual editor can have unintended consequences.

GitLab 13.1 hides any YAML-formatted front matter included at the beginning of the Markdown file to prevent any confusion or unintended formatting changes. The front matter remains editable in the raw source editor, available by toggling the editor mode in the bottom right of the Static Site Editor.

Paste image in Markdown in the Web IDE

Paste image in Markdown in the Web IDE

When working with Markdown content in the Web IDE, you may need to add images to the content. Adding images in most editors requires finding that image, adding it to the directory structure and then referencing it through markdown syntax.

The Web IDE now supports pasting images directly into the editing window. Copy an image to your clipboard, place your cursor in your the Web IDE where you’d like the image to appear, and paste. The image will automatically be uploaded to your project and appropriately referenced inside of your content, greatly speeding up the content creation process and reducing complexity for users.

Filter pipelines by pipeline status and tag name

Filter pipelines by pipeline status and tag name

You can now filter by pipeline status or by tag name on the pipelines page. With filtering, viewing all pipelines for a specific tag, or narrowing the list of pipelines to a specific pipeline status (such as failed or skipped) is much easier. With these additions to the existing filter options, pinpointing your desired pipeline is easier than ever, and saves time in your day.

Instance-level CI/CD variables

Instance-level CI/CD variables

GitLab now supports instance-level variables. With this ability to set global variables, you no longer need to manually enter the same credentials repeatedly for all your projects. This MVC introduces access to this feature by API, and the next iteration of this feature will provide the ability to configure instance-level variables directly in the UI.

Templates to simplify initial rules keyword configuration

Templates to simplify initial rules keyword configuration

It can be hard to figure out how to use the new rules keyword, especially if you previously used only/except, as the two are fundamentally different. The rules keyword creates a merge request pipeline by default, and only/except doesn’t.

To ease getting started, and getting to your first green pipeline with rules more quickly, we’ve added the two most common workflow: rules configurations as bundled templates. These make it much easier to get things working right away, letting you focus on what’s important.

API support for setting multiple Feature Flags strategies

API support for setting multiple Feature Flags strategies

You can now create feature flag strategies and apply them to environments via a public API. Previously, strategies were bound to environments. Introducing new strategies required defining additional environments and attaching them to these environments. This new API will allow for defining strategies independent of environments.

Improved authorization for GitLab-managed Terraform state

Improved authorization for GitLab-managed Terraform state

Changing your infrastructure is always a high-risk action; it should always be supervised, audited, and restricted to team members with permission. We introduced the GitLab-managed Terraform state with a known limitation in GitLab 13.0: you were required to provide a personal access token to work with the state file. This option did not scale well.

Starting with GitLab 13.1, we’ve extended the scope of the auto-generated CI token with the acting user’s credentials. The token is designed specifically to run Terraform state management jobs, enabling you to securely run Terraform job pipelines without any additional setup.

Pipeline success after failure notification

Pipeline success after failure notification

Each time a pipeline fails, you automatically receive an email notification. However, when the pipeline succeeds after failure, no automatic notification is sent, which requires you to manually check the pipeline’s status. In this release, we are excited to include a community contribution by @jacopo-beschi that solves this problem by automatically notifying you if a pipeline succeeds after a failure.

GitLab now lets you conveniently specify the kind of asset link you have added to your Release with a dropdown menu. Previously, if you added links to a release, you were unable to communicate what type of asset it was. With this addition, you can choose the type of asset from the following options: “Runbook”, “Package”, “Image”, or “Other.”

Specify asset types for Release links

Assign GitLab Alerts to team members

Assign GitLab Alerts to team members

In GitLab 13.1, you can assign GitLab alerts to specific users on your team, streamlining triage workflows, delegating problems that require investigation, and ensuring no critical alert gets dropped.

Assign GitLab Alerts to team members

Column sorting for Alert list

Column sorting for Alert list

Alerts are often noisy and plentiful. To make it easier for you to find the newest or most severe alerts quickly, you can now sort the alert list by descending and ascending values.

Column sorting for Alert list

Metric dashboard legends in table format

Metric dashboard legends in table format

Understanding charts without appropriate context can be difficult. In GitLab 13.1, we made it easier for you to compare data when inspecting charts by displaying chart legends in a tabular format.

Metric dashboard legends in table format

A Metric Dashboard is often related to other dashboards. With Dashboard Links, you can display links to related GitLab Metrics and Grafana dashboards that preserve the time window of the dashboard you’re currently viewing.

Metrics dashboard configuration validation

Metrics dashboard configuration validation

Configuring a dashboard YAML file can be complex and error-prone. GitLab 13.1 adds validation to your YAML file to help you diagnose problems with your metrics dashboard by displaying a warning message if your dashboard YAML definition is invalid.

Metrics dashboard configuration validation

Status pages display images

Status pages display images

Images included in issue descriptions published to GitLab status pages now render, giving meaningful context to customers, users, and stakeholders to help them make decisions about how to handle outages and performance degradations. Sharing visuals along with text raises transparency, which encourages user trust and confidence.

Dynamic Issue status icons on Security Dashboards

Dynamic Issue status icons on Security Dashboards

Previously, in Security Dashboards, vulnerability list items with an associated issue displayed a static icon with a link to the issue. With this usability improvement, the icon now dynamically reflects whether the issue is open or closed. At a glance, you can now tell if a vulnerability might need additional attention.

Dynamic Issue status icons on Security Dashboards

Filters persist on Security Dashboards

Filters persist on Security Dashboards

GitLab 13.0 introduced standalone vulnerability pages as an important step towards the future of Vulnerability Management. The switch from popup information boxes to independent pages, however, presented some new UI considerations.

Navigating from the Security Dashboards to a vulnerability page and back previously cleared any filters applied on the dashboard. We received good feedback that improving this experience would improve the vulnerability triage and management experience. Your filters now persist when moving between vulnerability pages and a dashboard, greatly improving the efficiency of managing vulnerabilities. It also matches a familiar UX pattern found elsewhere in GitLab, such as managing your To-Do list.

Rails SAST analyzer available for all

Rails SAST analyzer 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 contributed, and mitigate them proactively. As part of our community stewardship commitment, we are making our Rails SAST analyzer (Brakeman) available in every GitLab tier. This will allow ALL GitLab users developing in Rails to leverage SAST Security Scans for their projects. We will continue to move other open source (OSS) SAST analyzers to Core. You can follow our SAST to Core epic to see when other analyzers will become available, and contribute to this effort.

Rails SAST analyzer available for all

Policy Management for Container Network Policies

Policy Management for Container Network Policies

With the first release of a policy management UI for Container Network Policies, users can easily scan a list of Network Policies deployed in their project and enable or disable those policies through GitLab’s UI. You can find the new policy management experience at Security & Compliance -> Threat Management -> Policies.

Policy Management for Container Network Policies

New Geo Disaster Recovery command for failover preflight checks

New Geo Disaster Recovery command for failover preflight checks

When performing a failover using GitLab Geo, systems administrators should perform a number of preflight checks before promoting a secondary to a primary to ensure that the failover is successful. Many of these preflight checks are manual, thereby increasing the chance of user errors.

In GitLab 13.1, Geo includes a new command gitlab-ctl promotion-preflight-checks that lists all required preflight checks and asks systems administrators to confirm that these checks were executed. The command is automatically run when running gitlab-ctl promote-to-primary-node.

This is a first iteration towards a simpler failover process and we plan to automate preflight checks in future iterations.

Use IAM roles for encrypted Amazon S3 buckets

Use IAM roles for encrypted Amazon S3 buckets

You can now use AWS IAM roles for accessing encrypted S3 buckets. Previously, encrypted S3 buckets would not work at all. To learn more, see the Object Storage documentation.

In previous versions of GitLab, Advanced Global Search’s indexing process supported partial matching by storing a list of all partial words in the index. Partial words provide better results for natural-language search queries, but users performing code searches frequently search for specific text, like function definitions.

Partial matching for code has been disabled in GitLab 13.1, reducing the index size by 75%. If desired, users can continue using partial matching by using wildcards in their code search query. Partial matching for other content types, like issues or merge requests, is still supported.

Self-managed customers who have enabled Advanced Global Search must reindex after updating to take advantage of this reduction in index size.

Deprecations Deprecations

Default archive timing for jobs set to 3 months

Default archive timing for jobs set to 3 months

To help maintain overall performance for everyone using gitlab.com, the job archive date will be set to 3 months. Here’s a quick reminder of what you can and cannot do with an archived job. Once a job is archived:

  • You can still view the job, logs, associated pipelines, and deployments, as well as rerun the entire pipeline.
  • You can’t retry, rerun, or trigger the job, or trigger a deployment from the job.

Existing jobs that were generated before March 22nd, 2020 will be archived by September 22nd, 2020.

Planned removal date: June 22, 2020

Default artifact expiration changed to 30 days on gitlab.com

Default artifact expiration changed to 30 days on gitlab.com

To help maintain the overall performance for everyone using gitlab.com, the expiration for pipeline artifacts will be set to 30 days on gitlab.com. The artifacts from the last successful job will not be archived until 30 days after a newer job generates new artifacts. Artifacts without expiration dates will not be changed, but a future update will add an expiration date to them as well.

Planned removal date: June 22, 2020

Deployment template for AWS ECS is moving to a new location

Deployment template for AWS ECS is moving to a new location

We are changing the location of the Deploy to AWS ECS gitlab-ci.yml template. If you have referenced this template in your CI/CD configuration, please update it by replacing template: Deploy-ECS.gitlab-ci.yml with template: AWS/Deploy-ECS.gitlab-ci.yml. We are expanding our supported AWS targets, and all future AWS-related templates will be found in the AWS template folder.

Planned removal date: Jul 22, 2020

Deprecation of Secret Detection Job in SAST configuration

Deprecation of Secret Detection Job in SAST configuration

The Secret Detection CI/CD configuration settings are now provided in a separate GitLab-provided template and runs as a new Secure scan type. To ensure your project continues to run Secret Detection, we recommend you implement this new Secret Detection template 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. We will remove support for the old SAST secret job definition as soon as GitLab 13.4.

Planned removal date: September 22, 2020

Herokuish support deprecated in Auto DevOps

Herokuish support deprecated in Auto DevOps

GitLab is moving Auto DevOps from Herokuish buildpacks to Cloud Native Buildpacks, as Herokuish is essentially deprecated and Cloud Native Buildpacks are the next iteration of buildpack support. GitLab versions 12.10 and greater support Cloud Native Buildpacks. All new Auto DevOps projects will begin using Cloud Native Buildpacks in the next month, and Herokuish support will be dropped in October 2020.

Planned removal date: Oct 22, 2020

Kubernetes 1.12 and 1.13 support is being deprecated for integration

Kubernetes 1.12 and 1.13 support is being deprecated for integration

For integrating Kubernetes with GitLab, we’ve introduced a Kubernetes support policy to provide GitLab users with clear upgrade timelines. Two deprecations are scheduled:

  • GitLab’s support for Kubernetes 1.12 ends on September 22, 2020.
  • GitLab’s support for Kubernetes 1.13 ends on November 22, 2020.

Various GitLab features may still work following these deprecations, but are not officially supported. GitLab is simultaneously working on adding support for more recent Kubernetes versions.

Planned removal date: Sept 22, 2020

Kubernetes 1.12 no longer supported

Kubernetes 1.12 no longer supported

When deploying GitLab in Kubernetes, the minimum supported version of Kubernetes is now 1.13. Kubernetes 1.12 is no longer maintained upstream, and has recently been dropped by popular container management services such as GKE and EKS.

Planned removal date: GitLab 13.2

Legacy Feature Flags Deprecation

Legacy Feature Flags Deprecation

Feature Flag created before 13.1 are not compatible with the new architecture that we are developing. From 13.1, all new feature flags created on GitLab.com will be created with the new system by default. From 13.2, the same will be true for self-managed instances. Feature flags created in earlier versions can be edited until 13.4, and then they will become read-only. In 14.0, all legacy feature flags will be completely removed.

Planned removal date: Sep 22, 2020

Require Git 2.25 or later

Require Git 2.25 or later

From GitLab 13.1, GitLab requires Git 2.25 or later. Omnibus installations include Git 2.27. Installations from source must upgrade manually.

Planned removal date: June 22, 2020

Removals and breaking changes Removals and breaking changes

Planned removal of Docker-in-Docker (DinD) for security scanners

Planned removal 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 was deprecated in 13.0 and is scheduled for removal in 13.4. GitLab security products started 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 override or use custom Secure CI templates, you can follow the guides below to disable Docker in Docker (DinD) from your existing job templates:

Removal date: September 22, 2020

Important notes on upgrading to GitLab Important notes on upgrading to GitLab 13.1

  • Configuration values used by server-side Git hooks in Gitaly were stored in gitlab-shell/config.yml. They are now stored in Gitaly’s config.toml file under the [gitlab] and [hooks] TOML sections.

  • Before upgrading to GitLab 13.1, you must upgrade to GitLab 13.0, or — if you are using the Helm chart install — to the 4.0 version of the chart. For more information on recommended upgrade paths, see the Upgrade recommendations.

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