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.
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.
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.
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.
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.
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.
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.
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.
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 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
- 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.
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
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
Additionally, the new engine is open source under the Apache license.
We’d love to hear what you think and review any enhancements you
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.
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.
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.
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%.
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.
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.
Visualize users, projects, groups, issues, MRs, and pipeline activity
Admins often need an “at-a-glance” view of how GitLab is being used. The Usage Trends 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, Usage Trends 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 Usage Trends was released in 13.6.0 as Instance Statistics but the name was updated to Usage Trends in 13.6.1.
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!
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.
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.
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.
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.
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.
GitLab Runner 13.6
We’re also releasing GitLab Runner 13.6 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
The list of all changes is in the GitLab Runner CHANGELOG.
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!
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.
New vulnerability trends chart
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.
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.
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.
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.
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.
- Additional authentication options are now supported for
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.
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: