Nov 22, 2020 - James Heimbuck  
13.6

GitLab 13.6 released with Auto Deploy to EC2 and Usage Trends Dashboard

GitLab 13.6 released with Auto Deploy to EC2, Usage Trends Dashboard, Full Code Quality Report and much more!

At GitLab, we are focused on improving developer productivity and satisfaction. And GitLab 13.6 has all the right ingredients to help you achieve all that and more! We hope that you find these top features, and the 60+ new features and improvements packed in this release, useful.

Improved ease of use and automation for efficiency

To make it easy for you to get started with GitLab CI/CD with Amazon Web Services (AWS), Auto DevOps has now been extended to support AWS, so you can now Auto-Deploy to Amazon EC2 using Auto DevOps without using Kubernetes (as previously required by Auto DevOps).

Docker Hub has enforced rate limits on docker pull requests. We have mitigated the impact for our SaaS and self-hosted users and have shared ways to monitor the limits with Prometheus in your environments. We want all our users to stay safe with their CI/CD pipelines and Kubernetes clusters. We are moving the Dependency Proxy to Core available for everyone.

Listening to the community’s feedback to have a more descriptive default branch, Group owners now have more flexibility in configuring a custom default initial branch name for new repositories as opposed to the master branch. Speaking of defaults, the Static Site Editor can use a default merge request template across a project, reducing the need to navigate to the merge request after submission to update the description.

Improved visibility for faster decision making

You cannot fix what you cannot find. With 13.6, we’ve made improvements to several dashboards and reports to aid you with faster decision making.

With the code quality severity included within the merge request and the Full Code Quality Report, you can now quickly determine which code quality violations are critical to resolve before merging. Thanks for the community contribution with Code Quality Report, Vicken Simonian!

We’ve made updates to the Project Security Dashboard to include the results of the latest run pipeline security scan and also a dynamic vulnerability trend chart to help you stay on top of the real time and historical vulnerability trends. We've also added the fuzz testing results in the merge request along with the other security results and improved the readability of this report by adding the source file name and line number to help you quickly find the exact crash location and fix it.

GitLab Self Managed Administrators can now see their organization's usage trends for popular features such as users, projects, groups, issues, and pipelines over the last 12 months.

Improved extensibility for a seamless workflow

We aim to play well with other popular tools you may be using in your environment so that you have a seamless experience, even when you use only a few parts of GitLab. With 13.6, to enable easy access and collaboration from within VS Code, we’ve improved our extension with VS Code to insert Snippets, view and comment on merge requests and issues directly from VS Code rather than switching to the GitLab interface.

GitLab integrations can now be configured at a group level in addition to instance and project level - helping group owners manage integrations with ease.

And more

To enable you to grow beyond the 10GB per project storage limit, we recently introduced an add-on to purchase additional storage for your group or personal name space. In addition to Dependency Proxy, we've also moved Tracing to Core as part of this release.

These are just a few highlights from the many new features and performance improvements described below. If you'd like to preview what's coming in next month’s release, check out our Upcoming Releases page as well as our 13.7 release kick off video series where the Product Managers highlight key features coming in the next release.

Join us for an upcoming event

GitLab MVP badge

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

Sashi contributed a key set of capabilities to the GitLab webhook that adds events when a feature flag is changed or a deployment is started. Sashi also added a chat notification for when a deployment starts.

A big thanks for those contributions Sashi!

Key features released in GitLab 13.6


Auto Deploy to EC2

Auto DevOps has been expanded to support deployments to Amazon Web Services. You can now deploy to AWS Cloud Compute (EC2) and take advantage of Auto DevOps, even without Kubernetes. To enable this workflow, you must enable Auto DevOps and define the AWS-typed environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION. This allows you to provision your own infrastructure by leveraging the AWS CloudFormation API. Then, you can push your previously built artifact to an AWS S3 bucket, and deploy the content to an AWS EC2 instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps.


Postman collection support for API fuzz testing

You can now use a Postman collection to do API fuzz testing! Postman collections are pre-defined descriptions of your APIs that you may have already created as part of your testing efforts. It’s straightforward to create them if you haven’t already done so.

This is a great way to use fuzz testing with the resources that you already have. To use a Postman collection with fuzz testing, add the Postman collection to your repo and indicate its location in the .gitlab-ci.yml file. The fuzz engine then references it to do fuzz testing.

API fuzz testing with a Postman collection runs all the same checks as fuzz testing with an OpenAPI specification or an HAR recording. We have an example project you can look at to quickly get started!

Postman collection support for API fuzz testing

Display Code Quality severity ratings

The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today.

With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.

Display Code Quality severity ratings

Display code coverage data for selected projects

In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis. In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. We welcome feedback on the functionality and possible iterations for this feature in our feedback issue.

Display code coverage data for selected projects

Define test cases in GitLab

The first step towards project-level quality management is here! This initial release allows users to define and view test cases from within GitLab.

Keeping all of your quality management tools in a single DevOps system is essential to ensuring a single source of truth and a single place for all participants to collaborate and understand context. Being able to define test cases from within GitLab is the first step in this vision. We intend to build upon this foundation with the creation of Test Sessions, an overall quality management dashboard, and the ability to view test histories across multiple deployment targets, such as staging and production.

For more information on our vision, and to collaborate with us, please see the Quality Management Category Direction.

Define test cases in GitLab

Group-level management of project integrations

In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!

Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.

A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.

With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!

Read more in our announcement on the GitLab blog.

Group-level management of project integrations

Milestone Burnup Charts and historically accurate reporting

A milestone or iteration burndown chart helps track completion progress of total scope, but it doesn’t provide insight into how the scope changed during the course of the timebox. Neither has it previously retained historical accuracy regarding how much of the initial committed scope of the milestone or iteration was actually completed.

To solve these problems and help teams have better insights into scope creep, milestones and iterations now show a burnup chart that tracks the daily total count and weight of issues added to and completed within a given timebox.

We also refactored burndown charts to use immutable resource state events that ensure that milestone and iteration charts remain historically accurate[1] even after you’ve moved issues to another timebox.

[1] Only applies to milestones and iterations created in GitLab 13.6 or later. Milestones created prior to 13.6 will still have access to legacy burndown charts.

Milestone Burnup Charts and historically accurate reporting

Change Canary weights through the API

Adding support for canary-weight ingress annotation is a first iteration towards implementing a load balancer in GitLab. The goal is to provide you with an easy way to configure NGINX annotations so you can customize their behavior. Simply put, this gives you additional flexibility when configuring advanced deployments. Previously, changing canary weights was only supported in the .gitlab-ci.yml file. You now have more control over your advanced rollouts, as well as the ability to introduce trigger-based rollouts.

Change Canary weights through the API

Fire Webhook on Feature Flag change

As a developer, you can use GitLab’s webhook features for various events, such as MR events, pipeline events, job events, and deployment events. In this release, you can now use webhook events when a feature flag is toggled either on or off. This addition streamlines the process to update your CI/CD pipelines, receive Slack notifications for events, and more. A huge thanks to Sashi for a great community contribution!


Sort releases by name in UI

A Release Page can be both confusing and difficult to navigate if you have hundreds of release tags with release notes. With the implementation of a new sorting component, gone are the days when you needed to manually sift through your releases each time you deploy. You can now quickly sort releases by date and name to find relevant information more efficiently.

Sort releases by name in UI

Other improvements in GitLab 13.6

Admin approval required by default for new user registrations

In GitLab 13.5, we introduced the option to require administrator approval for new user registrations. To increase security of our default configuration, GitLab 13.6 makes this option the default experience for new instances. We have also introduced email notifications to instance administrators when a new signup occurs and to users when their registration is approved. Email notifications at these critical steps in the process help reduce the turnaround time to onboard users when administrator approval is required.

Export merge requests as a CSV

Many organizations are required to document changes (merge requests) and the data surrounding those transactions such as who authored the MR, who approved it, and when that change was merged into production. Although not an exhaustive list, it highlights the recurring theme of traceability and the need to export this data from GitLab to serve an audit or other regulatory requirement.

Previously, you would need to use GitLab’s merge requests API to compile this data using custom tooling. Now, you can click one button and receive a CSV file that contains the necessary chain of custody information you need.

Export merge requests as a CSV

Improved user experience for the group member list

Our group members list has been redesigned using the Pajamas Design System. The new experience includes more descriptive terminology, a new layout, headers for all columns, tooltips for key data elements, and more! The new experience helps group administrators quickly identify key attributes about their group members for more effective group management.

Improved user experience for the group member list

Filter by iterations in boards and issue lists

As part of our ongoing efforts to improve using timeboxes to plan and track work in GitLab, you can now filter issue lists and boards by iteration. For example, a team using iterations for two-week sprints can now use a scoped issue list or board as a single source of truth on objectives in a specific sprint.

Filter by iterations in boards and issue lists

Track issue health status from the issue list

When managing a large number of in-flight issues, it can be difficult to track their health status, especially if you are working across multiple epics. You can now see an issue’s health status in the issue list UI, enabling you to get a quick view of the current status of your work. We’re excited to add filtering in a future iteration.

Track issue health status from the issue list

Configure destination for images uploaded from the Static Site Editor

GitLab 13.6 introduces the ability to upload image assets directly to your project from the Static Site Editor. Images uploaded from your computer are included in the resulting merge request and the default destination for uploaded assets is the source/images directory. Depending on the structure of your project, however, this might not be where you want to store your images. It may not even exist.

The configuration file .gitlab/static-site-editor.yml allows you to customize the behavior of the editor. Setting the entry image_upload_path to the absolute path to your asset directory will let the Static Site Editor know where you want images to be stored in your project.

Filter Merge Requests by environment and deployment times

You can now filter merge requests by environment and deployment times (in addition to the existing ability to filter by deployment ID). This means you can now find merge requests that match an environment name, deployment ID, or that are deployed before or after a given time. Using these filters in combination can help you determine what’s been deployed to an environment over a specified timeframe.

Filter Merge Requests by environment and deployment times

Include Git LFS files in repository archive

Git Large File Storage (LFS) is one of Git’s solutions to handle large files; it replaces large files with text pointers while storing the file contents on a remote server (like GitLab). It allows developers to version very large files with Git and keep Git operations between a local host and a server speedy and performant.

Downloading the source archive of a project that contains LFS files from GitLab used to export a pointer to the file instead of the file itself. This made the archives smaller, but the archive would not hold a complete snapshot of the repository. Having an incomplete repository generally meant more manual work to add those LFS files individually to have an accurate export of the repository.

GitLab 13.6 will now export the LFS files instead of the pointer to the files, making it seamless to export the contents of your repository.

Issues and Merge Requests in VS Code

Issues are the source of truth for collaboration and what needs to be implemented. Referring back to user stories, designs, and discussions on the issue involves switching between your editor and browser. Merge Requests are the place where feedback on contributions is provided. Referencing this feedback and continuing to make changes requires this same context-switch between browser and editor.

Reducing the friction of context-switching between tools makes it more efficient to contribute changes to a project. With the 3.6.0 Release of GitLab Workflow, issues and merge requests are available directly in VS Code for easy access and collaboration. You can find issues and merge requests assigned to you or created by you and open those directly inside VS Code. This gives quick access to the information needed and the ability to respond directly to issues and merge requests via comments.

This is the first step in enabling more complete Merge Request reviews in VS Code.

Issues and Merge Requests in VS Code

Unique design identifier

Right now, all designs are scoped to issues and have a URL that includes the Issue ID and the design filename. This has a lot of limitations for the architecture of Design Management because you cannot refer to a design IID (internal identifier) field.

While this feature is very technical in nature, it sets the stage to use designs in more places in GitLab. With unique IIDs, we can then associate designs to MRs, Epics and the Project Level.

Generate HTML reports for Code Quality

Code Quality reports provide you with a variety of information about code quality violations found on the current branch, but they are not in an easily readable format.

Now, this report is available as an .html file so you can more easily see the code quality violations in your project and determine the impact. You can even host the file on GitLab Pages for even easier reviewing!

Thanks for the contribution Vicken Simonian!

Include multiple CI/CD configuration files as a list

Previously, when adding multiple files to your CI/CD configuration using the include:file syntax, you had to specify the project and ref for each file. In this release, you now have the ability to specify the project, ref, and provide a list of files all at once. This prevents you from having to repeat yourself and makes your pipeline configuration less verbose.

Include multiple CI/CD configuration files as a list

Show coverage data even if the pipeline fails

As project maintainers, you can use badges to show the current test coverage of your project. Unfortunately, if a pipeline takes a long time, has manual steps, or fails for the branch mapped to the badge, the coverage will show up as unknown. This makes badges less useful for you.

With the coverage badge, your pipeline does not have to be completely successful to display a value, making it easier to see at a glance the status. You can be confident of the test coverage value for your project, for example before a manual release step, without having to dig into the jobs list.

Unit Test Report UX improved

The Unit Test Report is a great way for you to review test results from a pipeline, but the presence of large traces could make the page very long and hard to navigate. It could also be hard to find the test you want to check in the Unit Test report because the test file name was not presented on the report page.

With GitLab 13.6, the filename present in the unit test report file is available on the page to make it easier to find. Also, the contents of traces are removed from the main list, and made available in an easily accessible modal window, greatly improving the usability of the list.

Unit Test Report UX improved

The npm project-level endpoint works with all npm commands

When you use the Package Registry to publish and share Node packages, you can choose to use an instance or a project endpoint. The project endpoint is best when you have a few packages in the same group. The instance endpoint is best when you have many packages in different groups.

The problem has been that the project endpoint does not support many of the common npm commands, including npm dist-tag, npm add, and npm view. As a workaround, you had to specify a publishConfig in each package.json. While this was a viable workaround, it had a few downsides:

  • It added friction to publishing packages, because each package had to be configured to publish to the project’s registry.
  • It made it harder to automate. For example, environment variables could be replaced inside a .npmrc, but it wasn’t possible in package.json. Because of this, you had to hard-code the GitLab project ID in your package.json.
  • It didn’t match the expectations of developers who were not used to this workflow.

To fix these problems, we made all supported endpoints available for both the instance and project level endpoints. Now you can rely on your .npmrc to configure the registry. You are no longer required to add and maintain publishConfig in each package.json. The exceptions to this are:

  • The upload endpoint must be at the project level. It can’t be at the instance level, because the backend would receive an upload request without a group or project and not know where to store the package.
  • The tarball endpoint remains at the project level. During npm install, npm inquires about the tarball URL. The Package Registry only needs to reply with the location, which can be anywhere. To keep things simple, we will keep it where it is now: at the project level.

Coverage-guided fuzz testing artifacts available in merge request widget

Coverage-guided fuzz testing results are now shown in the security results alongside other security scan results on merge requests. This allows you to quickly see if fuzz testing found issues, get details about them, and download the relevant artifacts needed to reproduce the issue locally before the code is merged.

Coverage-guided fuzz testing artifacts available in merge request widget

New fuzz engine for Java coverage-guided fuzz testing

We’re introducing a new fuzz engine for Java coverage-guided fuzz testing. This is the underlying engine that runs your fuzz tests in the pipeline. The new engine is called javafuzz and can be used by specifying --engine javafuzz in your pipeline file.

We recommend using the new javafuzz engine over the existing JQF engine going forward. The new engine supports Java Spring applications, where we expect it to be very helpful.

Additionally, the new engine is open source under the Apache license. We’d love to hear what you think and review any enhancements you make!

Pipeline status in Project Security Dashboard

Project Security Dashboards provide security and engineering teams with a centralized place to manage vulnerabilities. Because the reports are based on the latest successful pipeline scan of the default branch, it is important to know if the results are up to date. Previously, there was no way to determine the time or status of the latest default pipeline scan from these pages. This required navigating away to the Pipelines list and digging for the relevant information.

You can now see at the top of a Project Security Dashboard when the last default pipeline completed. A link to the corresponding pipeline page is conveniently provided. And in the case of any pipeline failures, you will see the number of failures clearly indicated. The failure notification takes you directly to the Failed jobs tab of the pipeline page. After addressing the failure conditions, running a new pipeline will update the vulnerability data for the project along with the new pipeline status area on the Security Dashboard.

Pipeline status in Project Security Dashboard

Support for post-processing of leaked secrets

GitLab.com now supports post-processing hooks for Secret Detection. These can be used to take actions like notifying the cloud service that issued the secret. The cloud provider can confirm the credentials and take immediate remediation actions like revoking or reissuing a new secret, and notifying the owner of the leaked secret. Post-processing workflows vary by supported cloud providers. With this initial release, GitLab is providing support for Amazon Web Services (AWS) secrets.

We look to expand integration with other third party cloud and SaaS providers. Vendors can express integration interest by filling out this form. Learn more about the technical details of post-processing secrets.

Add chat notification when deployment starts

Previous GitLab releases added notification support for successful, cancelled, and failed deployments. In this release, you can also receive chat notifications at the start of your deployment. This is thanks to a great community contribution by Sashi! This allows you to keep better track of the status of your deployments without disrupting your normal workflow.

Create job to stop ECS review Apps

We recently added support for AWS ECS so you can use it as a deployment target for Auto DevOps. However, review apps for ECS targets weren’t automatically stopped. To rectify this, the Deploy_ECS template has been extended to automatically stop review apps as part of the Auto DevOps flow so that resources don’t go to waste. This ensures a similar experience for Auto DevOps users deploying to ECS and those using Kubernetes, where things work automatically without the need to manually stop and keep track of review apps.

Create job to stop ECS review Apps

Set Auto-Stop Environment Expiry Period on environment creation

In this release, you now have the option to create an expiration time for review apps when an environment is created. Expiration time was previously set according to the deployment date, but some environments are never deployed to. This new feature creates an automatic way to stop environments based on the creation date, regardless of deployment status.

Warn users on retrying outdated jobs

If you retry a failed deployment job, the environment could be overwritten with older source code. To prevent this from happening unintentionally, we have added a message that warns you before retrying the outdated job.

Warn users on retrying outdated jobs

Create alerts on custom dashboards

Alerts are critical to make developers and operators aware of the health and performance interruption to their service. Previously, you could only create alerts for metrics in GitLab’s out-of-the-box dashboards. Starting in this version of GitLab, you can configure alerts on any metric in any custom dashboards that your team creates.

Advanced Search Background Migrations for Elasticsearch Indexing

Adding features to Advanced Search, often means adding or changing the way content is indexed, and this index change would happen incrementally over several days. The past few releases, we have been adding a lot of features to Advanced Search, which meant GitLab administrators would have to perform a reindex manually after each upgrade.

From GitLab 13.6 and onwards, when new Advanced Search features are added, reindexing will happen in the background without manual intervention. Reindexing can still be performed manually when needed.

GitLab web interface now faster with automatic image resizing

GitLab displays many user provided images, such as user avatars and images attachments in issues and comments. Prior to GitLab 13.6, this content would be delivered to users unmodified, regardless of how the image was being used on a page. For example, we allow avatars up to 200kb in size, and on pages like the commit list, we can display 20+ avatars at once. If each of these averages 100kb in size, that is 20mb of image data, significantly slowing down page load.

To improve performance, GitLab now automatically resizes avatars to the size used on the page, dramatically reducing the content size needed to render. On our test pages, content size was reduced 10 fold. This not only causes the page to load faster, but uses less network bandwidth as well.

You can read more about our approach and results in our Unfiltered blog post Scaling down: How we shrank image transfers by 93%.

Bug fixes

Some of the notable bug fixes in 13.6 are:

Date filtering and improved data table for MR Analytics

In GitLab 13.3, we introduced Merge Request Analytics, which helps you to more effectively evaluate the efficiency and productivity of your merge request throughput. GitLab 13.6 introduces further enhancements to Merge Request Analytics, and you now have the ability to filter by date ranges, as well as approvals metadata and pagination for the data table.

Date filtering and improved data table for MR Analytics

Generate a chain of custody report for a commit SHA

In 13.3, we released the chain of custody report for all merge commits in a group. Since then, your feedback inspired us to add support for exporting this report based on an initial commit SHA. Now, when exporting this report, you will have an option to enter a commit SHA, which will then generate a chain of custody report specific to that commit.

Generate a chain of custody report for a commit SHA

Visualize users, projects, groups, issues, MRs, and pipeline activity

Admins often need an “at-a-glance” view of how GitLab is being used. The Instance Statistics feature helps admins quickly understand trends on key feature usage across the entire instance. Admins can now see charts depicting popular features such as users, projects, groups, issues, and pipelines over the last 12 months.

In its first iteration, Instance Statistics requires Administrator permissions, which means it is only available on self-hosted installations of GitLab. In a future iteration this data will be made more accessible to other users, including GitLab.com users, with the option to restrict access. Note that Instance Statistics will be renamed Usage Trends in 13.7 in support of the roadmap to make this feature more widely available.

Visualize users, projects, groups, issues, MRs, and pipeline activity

Organize boards with epic swimlanes

Oftentimes, when viewing an issue board, it can be difficult to identify work that is associated with a specific stream of work. To provide more clarity and help you organize work across your teams, we are releasing our first issue board swimlane option, epics! Quickly group your work in a horizontal lane across your issue board columns, allowing you to easily see all work related to an epic, and what state it is in!

Please share any feedback with us on epic swimlanes by leaving a comment!

Organize boards with epic swimlanes

Use a button to promote an issue to an epic

Promoting an issue to an epic previously relied on the /promote quick action in an issue description or a comment, adding some friction to a common and important action. To make this action more discoverable, we’ve introduced a new secondary actions menu in the issue header and added a button to quickly promote an issue to an epic with a single click.

Use a button to promote an issue to an epic

Customize the initial branch name for new projects within a group

When creating a new Git repository, the first branch created is named master by default. In coordination with the Git project, broader community, and other Git vendors, GitLab has been listening to the development community’s feedback on determining a more descriptive and inclusive name for the default branch, and is now offering users options to change the name of the default branch name for their repositories.

Previously, we shipped the ability to customize the initial branch name at the instance-level and as part of 13.6, GitLab now allows group administrators to configure the default branch name for new repositories created through the GitLab interface.

Improved Design Management notifications

Up until now, notifications on designs were fairly inconsistent with other GitLab notifications, because you did not receive an email unless you were @mentioned. This made it very difficult to keep track of design discussions.

In 13.6, we’ve added consistent notifications so if you have participated in any way on a design (left a comment, replied, or were @mentioned), you will receive an email for each new comment.

Improved Design Management notifications

Insert GitLab Snippets directly in VS Code

Project snippets are a place to share code fragments among your team. These snippets often contain fragments of code that are re-used in multiple places or help to bootstrap similar pages and components.

When contributing to a project, it can be important to find these snippets and insert their contents in to your working file. Finding these requires context switching out of your editor and then copy/pasting the correct information.

Using the VS Code extension GitLab Workflow v3.5.0, you can now insert snippets in to your working file, both single and multi-file snippets are supported.

Insert GitLab Snippets directly in VS Code

Merge Request templates for Static Site Editor changes

For websites created using a static site generator, the Static Site Editor can be used to quickly edit page content in a familiar and intuitive interface. Once your edits are complete, you can even create a merge request directly from the editor. In GitLab 13.5, we added the ability to set the merge request title and description, but merge request description templates were not available. This meant merge requests created from the Static Site Editor would have inconsistent descriptions, and be missing any useful information from templates, like checklists.

In GitLab 13.6, merge requests created from the Static Site Editor will use the default merge request description template if one has been configured. Additionally, you can select from and apply any other description templates defined in .gitlab/merge_request_templates, ensuring consistent messaging for reviewers and making it less likely that you’ll have to navigate to the merge request page to update the description after submission.

Merge Request templates for Static Site Editor changes

Upload images in the Static Site Editor

GitLab 13.1 added support for linking to and previewing images in the Static Site Editor, which is great as long as your images are already hosted somewhere on the web. However, adding new images to your site still required using alternate methods to upload the assets to the project repository.

In GitLab 13.6, you can not only link to an image, but also upload an image directly to your project from the Static Site Editor and preview it alongside your edits immediately. Clicking the Add Image icon in the formatting bar reveals the new option to choose a file from your computer. Once uploaded, the image is displayed in the WYSIWYG mode of the editor, and upon submitting the changes, the file itself is included in the merge request.

Pipeline status in branch and tag lists

If you use CI/CD pipelines with tags or branches and want to know the latest pipeline status, you previously had to navigate away from the branch list or tag list to get to the pipeline page. Now, pipeline status icons are displayed for each branch or tag in their respective list views so you can quickly get to this information for many tags or branches in less clicks.

Thanks to Lee Tickett for this contribution!

Pipeline status in branch and tag lists

Support variables in rules:changes

The longer your gitlab-ci.yml scripts are, the more difficult they are to maintain and scale. By adding support for environment variables in the rules: changes keyword, you can now use variables for paths or filenames without making your CI file overly verbose. Variables help you reduce your configuration file’s overall length when running the same CI jobs to test changes in different file sets.

The Dependency Proxy is now open source

Docker Hub recently began to enforce rate limits on pull requests from Docker Hub. Pull rates are now limited based on your individual IP address for anonymous users or on your pricing tier if you are authenticated and signed in.

The Dependency Proxy can help reduce the amount of pull requests you make from Docker Hub by caching images previously pulled through the proxy. So, we are moving the feature to Core to help address these new limits. By supporting proxying and caching in Core, you can now enjoy increased reliability and performance of your pipelines.

Coverage-guided fuzz test results are now human-readable

After fuzz testing finds a crash, the next step is to debug it and find out where the crash occurred. This can be difficult to do with only hex addresses, so we are happy to announce that we now provide human-readable, coverage-guided fuzz test results for all supported languages.

This means that when you look at the stack traces for a crash, you can see the accompanying file name and line number. This allows you to easily go to the place the crash occurred and fix it.

Coverage-guided fuzz test results are now human-readable

New SAST severity data for Rails vulnerabilities

When available from our security scan analyzers, GitLab Static Application Security Testing provides severity data for identified vulnerabilities. We recently updated our Brakeman analyzer to add support for severity data. This data will help increase the usability and accuracy of Security Approval Rules as fewer vulnerabilities will report ‘Unknown’ severity. In the future, we will augment other analyzers missing vulnerability metadata and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.

New SAST severity data for Rails vulnerabilities

Basic vulnerability trend visualizations have long been available on Group Security Dashboards and the Instance Security Center. However, the Project Security Dashboard lacks these, making it difficult to quickly understand any project-level trends on number and type of vulnerabilities over time.

Our new vulnerability trends chart provides this needed visibility at the project level. Plus, this new chart is even more capable than the existing Group and Security Center visualizations because it is interactive. Toggle severity trend lines on or off with a single click to show just the data you want. You can also change the timeframe to see up to a year’s worth of data. The trend chart is dynamic so it updates in real time to reflect your changes.

With the inclusion of this chart, you will also notice that the single-page Project Security Dashboard is now split into dedicated pages for charts and for vulnerability lists, respectively, mirroring the Group and Instance Security Center layouts. The Vulnerability Report page contains all functionality previously under the Project Security Dashboard. The Security Dashboard page remains but will now contain the new vulnerability trends chart. Separating these features gives us a dedicated space to grow project-level security metrics and visualizations in the future.

New vulnerability trends chart

Support for disabling pre-existing SAST rules

GitLab Static Application Security Testing (SAST) now supports disabling predefined detection rules. By changing the vulnerability detection defaults, organizations can tailor security scanning results. Disabling predefined rules will exclude irrelevant vulnerability findings which will help to reduce false positives and improve the accuracy of security gates like merge request security approval rules as well as reduce the number of vulnerabilities reported in the security dashboards. To disable the default rulesets, add to the .gitlab folder a new file named sast-rulesets.toml that contains customizations in the correct notation. You can learn more about this file format and see examples in our documentation for SAST custom rulesets. We aim to provide additional improvements like importing custom rulesets in .gitlab-ci.yml files in the future.

Support for disabling pre-existing SAST rules

Use a URL path list to guide DAST scans

DAST web testing within GitLab has always been dependent on a successful spider session to crawl the site and find the pages that the DAST scanner should test. This works in a large number of cases, but it can cause problems when a site has hidden pages, sections of a site aren’t linked to each other, or if the spider reaches the time limit for it to stop looking for pages. If the response time of the site is slow, due to being on a development instance or any other number of situations, the last scenario can significantly reduce the coverage of the DAST test when it scans for vulnerabilities.

In order to reduce the issues related to spidering and allow users to control exactly what parts of a site are tested during a DAST scan, we have introduced a way for a URL list to be used to guide the scan, instead of the results of the DAST spider. Using the new variable DAST_PATHS, you can include a list of paths within the website specified in the DAST_WEBSITE variable for the scanner to cover. This comma separated list will act as the guide and allow pages to be covered that may not have been found by the spider. This will also allow you to use existing site maps, exported as a comma separated list, to make sure that the DAST scan covers every page you wish to test.

Associate a release to a group milestone

In GitLab 13.0, you could associate a release to a milestone via a picker in the Gitlab UI. However, users leveraging group milestones were unable to associate a release to that milestone. Now, you have the ability to easily connect your group milestone plans with releases.

Searchable user list in feature flag strategy

We previously added support for user lists as a feature flag strategy. If there are many user lists defined, it can be very hard to find the one that you wish to apply to a specific strategy. To make user lists easier to find and use, we have added the ability for you to search for a user list from within the strategy.

Searchable user list in feature flag strategy

Use dedicated signing key for CI_JOB_JWT Vault Integration

Your security is of the utmost importance to us here at GitLab. Ensuring that the features you rely on are kept up-to-date not only provides the latest and greatest in terms of functionality, but keeps you safe, secure, and protects your sensitive data. To improve overall security, you can now use a dedicated signing key for your HashiCorp Vault JSON Web Token (JWT) authentication method and rest assured knowing that the JWT cannot be used to impersonate another user through OpenID Connect.

Install Runners with the GitLab Kubernetes Agent

Users of custom GitLab Runners can use GitLab Managed Apps or manual installation for setting up the Runners. While Managed Apps are easy to use, this approach isn’t flexible for advanced use cases, and manual installation means maintenance tasks for our users because it isn’t integrated with GitLab. The GitLab Kubernetes Agent can be used to turn any GitLab project into a Kubernetes management project so we have created an example repository and documentation to show you how to use the Agent to install the GitLab Runner, giving you an integrated, GitLab-centered GitOps workflow for managing your custom runners.

Tracing has been moved to Core

As part of our effort to make the three pillars of observability available in our Core product offering, we have completed the final piece, and moved our Tracing category to GitLab Core. To learn more about the features of Tracing, read the documentation.

GitLab chart improvements

  • Requested default resources for Webservice and Sidekiq pods have been significantly increased, to better represent the resources consumed. This change is intended to prevent deployments from encountering memory issues, especially when under load. Please ensure you have sufficient memory and CPU available in your cluster, or GitLab may fail to start with the new resource requests.
    • Sidekiq now requests significantly more resources, 2G of memory instead of 650M and nearly a full core.
    • Webservice requests an additional 1GB of RAM, for 2.5G total.
  • NGINX controller default replica count has been changed from 3 to 2, to reduce some resource consumption.

Omnibus improvements

  • Additional authentication options are now supported for pgbouncer, including scram-sha-256. Previously we supported the auth_type configuration, but it was hardcoded to only utilize md5. For a full list of available authentication types, see the pgbouncer documentation.
  • The default set of postgres_exporter metrics has been changed, to reduce the overall load on Prometheus. By default, pg_stat_user_tables is now disabled, saving approximately 9500 metrics.
  • git has been updated to 2.29.0, ruby to 2.7.2, rake to 13.0.1, registry to 2.11.0-gitlab, prometheus to 2.22.0, and grafana to 7.3.1.
  • GitLab 13.6 includes Mattermost 5.28, an open source Slack-alternative whose newest release includes in-product notifications for product updates, and much more.

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 users!

In GitLab 13.6 we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.6 are:

Deprecations

Deprecate Container Registry log formatters

Currently, GitLab supports:

  • Text, JSON, and logstash log formatting for app logs.
  • Text, JSON, and combined log formatting 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.

Deprecation date: January 22nd, 2021

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that 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.

Deprecation date: January 22nd, 2021

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 alternative that can be better supported. 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.
  • Add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused) settings.

Deprecation date: January 22nd, 2021

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.

Deprecation date: January 22nd, 2021

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.

Deprecation date: January 22nd, 2021

Deprecate Container Registry support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed from GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.

We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.

Deprecation date: January 22nd, 2021

Deprecate pulls that use v1 of the Docker registry API

GitLab is disabling pulls via the Docker registry v1 APIs on January 22nd, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

  1. Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
  2. If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

Deprecation date: January 22nd, 2021

Deprecate support for Kubernetes 1.14

GitLab will deprecate Kubernetes 1.14 support on December 22, 2020.

Deprecation date: December 22, 2020

Elasticsearch 6.7 is deprecated and will stop being supported in GitLab 13.9.

Elasticsearch 6.7 will no longer be compatible with GitLab 13.9 and higher.

All customers using Advanced Search should plan to upgrade to Elasticsearch 6.8 or greater before upgrading to GitLab 13.9. If you are currently running a GitLab version older than 13.2, refer to the version requirements for GitLab and Elasticsearch versions.

Deprecation date: February 22, 2021

End of support for CentOS 6

CentOS 6 reaches end of life in November 2020. GitLab 13.6 will be the last supported version for deploying GitLab on CentOS 6. You are advised to upgrade to CentOS 7 or 8. Visit the deprecated OSes page for more information on the supported distributions.

Deprecation date: November 22, 2020

Make pwsh the default shell for newly-registered Windows runners

In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.

Deprecation date: Jun 22, 2021

In GitLab Runner 13.3, a symlink was added from /usr/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.

Deprecation date: Jun 22, 2021

Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag

In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.

Deprecation date: Jun 22, 2021

Remove Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.

Deprecation date: Jun 22, 2021

Remove off peak time mode for Docker Machine autoscaling

In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.

Deprecation date: Jun 22, 2021

Remove success and failure for finished build metric conversion

In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.

Deprecation date: Jun 22, 2021

Remove translation from step_script to build_script in custom executor

In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.

Deprecation date: Jun 22, 2021

Sidekiq Cluster queue selector configuration option has been renamed

GitLab contains a large number of background job queues. Some administrators may want to have multiple background job processes, each running different workloads.

Previously, we only supported specifying the queues handled for a particular process by name, or using an experimental option to allow selecting queues by attributes.

This option - previously experimental_queue_selector - is no longer experimental and has been renamed to queue_selector. experimental_queue_selector will continue to work until GitLab 14.0.

Deprecation date: May 22nd, 2021

Web Application Firewall (WAF)

GitLab’s Web Application Firewall (WAF) is deprecated in GitLab 13.6. As this is a breaking change, the WAF will be removed from the product on May 22, 2021 in GitLab 14.0. GitLab’s WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By deprecating and removing the WAF, GitLab will be able to focus its efforts on furthering other areas in the product where more value can be provided to users. Users who currently rely on GitLab’s WAF can continue to use the free and open source modsecurity project which is independent from GitLab. Additional details are available in the deprecation issue.

Deprecation date: November 22nd, 2020

Removals

We are building deeper integration with Opsgenie and other alerting tools via HTTP endpoint integrations so that you can see alerts within the GitLab interface. As a result, the previous link to Opsgenie in the alerts list will be deprecated following the 13.8 release on January 22, 2021.

Removal date: January 22, 2021

Important notes on upgrading to GitLab 13.6

  • For users of the GitLab helm chart, resource requests have been increased to better represent the amount consumed under load. We encourage administrators to review the changes and ensure their cluster has sufficient headroom, or services may fail to start.
  • Ruby 2.7.2 is now required. Users of source installs will need to install GitLab with Ruby 2.7.2, or GitLab will not start. This is already handled for GitLab Omnibus and Helm Chart users.

Changelog

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

Installing

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

Updating

Check out our update page.

Questions?

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

GitLab Subscription Plans

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

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

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

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

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

Cover image licensed under CC0

Try all GitLab features - free for 30 days

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

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg