GitLab 13.6 Release

Admin approval required by default for new user registrations

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Associate a release to a group milestone

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.

Install Runners with the GitLab Agent for Kubernetes

Install Runners with the GitLab Agent for Kubernetes

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 Agent for Kubernetes 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.

Set Auto-Stop Environment Expiry Period on environment creation

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

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.

Tracing has been moved to Core

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.

Coverage-guided fuzz testing artifacts available in merge request widget

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

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

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

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.

GitLab chart improvements

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.

Advanced Search Background Migrations for Elasticsearch Indexing

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.

Bug fixes

Bug fixes

Some of the notable bug fixes in 13.6 are:

• Packages/Composer: semantic version not fully supported
• Can’t see multiple tags on Packages mobile
• Deploy tokens with write_package_registry should also have read permission
• Value Stream Analytics: Author and Assignees labels not working
• Value Stream Analytics: A deleted value stream remains active in the dropdown
• Code Quality merge request widget shows irrelevant data with pipelines for merged results
• Web IDE: Search text color is unreadable in Web IDE using the Monokai theme
• SAST Configuration UI: SAST_DEFAULT_ANALYZERS is incorrectly written with default value
• Can’t update any release if milestone is linked to it
• Permanent links to release assets: not found (404)
• Timeout when using release-cli on private runners
• Deployment status badges are not displaying properly
• dotenv variables are not available in bridge jobs
• interruptible does not cancel child pipelines
• Some unicode characters in markdown are transformed into pictures
• Markdown with YAML rendering doesn’t handle UTF8 BOM
• Focus broken on Issues “Labels” selector
• Issue label selection scrolling too far leading to usability problems
• Quick actions do not work when description contains code block
• Fix failing health status update
• Remove duplicate iids for Epics
• Fix link for attachments in Service Desk emails
• Apply Group-level labels with Service Desk templates
• workflow:rules variables can not access passed variables from upstream and trigger variables
• Missing “before_script” / “script” section in job output
• artifacts:expire_in in .gitlab-ci.yml does not practically work

Date filtering and improved data table for MR Analytics

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

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

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-managed 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

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

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

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

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

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

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

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

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.

What’s new:

• Allow user to specify any runner configuration in the GitLab Runner Helm chart
• Enable PowerShell Core support in Docker-Windows executor
• Expose services to custom executor with $CI_JOB_SERVICES
• Add Kubernetes Volumes subPath support
• Add Kubernetes runners allowPrivilegeEscalation security context configuration
• Improve artifact/cache performance behind feature flag FF_USE_FASTZIP
• Set service entrypoint and command in config.toml
• Manage driver-defined job variables in custom executor
• Cap maximum Docker Machine provisioning rate

Bug fixes

• Fix large cache uploads using Azure blob storage

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

Pipeline status in branch and tag lists

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

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

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.

Add chat notification when deployment starts

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

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.

Searchable user list in feature flag strategy

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

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.

Create alerts on custom dashboards

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.

Coverage-guided fuzz test results are now human-readable

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 SAST severity data for Rails vulnerabilities

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 vulnerability trends chart

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

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

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.

Omnibus improvements

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.

GitLab web interface now faster with automatic image resizing

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%.

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.6 we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.6 are:

• Faster Packages API for large groups
• More performant cleanup policy for tags
• Reduced site footprint by downscaling images
• Investigate and reduce end-points with biggest amount of CACHE SQL calls
• Snippets: Pre-fetch GraphQL requests with startupJS
• Remove complexity from blocking issue relationships