GitLab.org/GitLab: Release v13.6.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.6
Released: 2020-11-22
License: MIT
Release Assets:
##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)
[Support for post-processing of leaked secrets](https://docs.gitlab.com/ee/user/application_security/secret_detection/#post-processing) (SaaS only):
> GitLab.com now supports post-processing hooks for [Secret Detection](https://docs.gitlab.com/ee/user/application_security/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](https://forms.gle/wWpvrtLRK21Q2WJL9). Learn more about the [technical details of post-processing secrets](https://gitlab.com/groups/gitlab-org/-/epics/4639).
Secret Detection[Generate a chain of custody report for a commit SHA](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/#commit-specific-chain-of-custody-report):
> In 13.3, we released the [chain of custody](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/#chain-of-custody-report) 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.
Audit Reports[Define test cases in GitLab](https://docs.gitlab.com/ee/ci/test_cases/index.html):
> 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.
Quality Management[Track issue health status from the issue list](https://docs.gitlab.com/ee/user/project/issues/#health-status):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/218711) in a future iteration.
Issue Tracking[Postman collection support for API fuzz testing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/index.html#postman-collection):
> You can now use a [Postman collection](https://www.postman.com)
> 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](https://gitlab.com/gitlab-org/security-products/demos/api-fuzzing/postman-api-fuzzing-example)
> you can look at to quickly get started!
Fuzz Testing[Use a URL path list to guide DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/#available-variables):
> 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.
DAST[Coverage-guided fuzz testing artifacts available in merge request widget](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#interacting-with-the-vulnerabilities):
> 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.
Fuzz Testing[New fuzz engine for Java coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#supported-fuzzing-engines-and-languages):
> 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`](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/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!
Fuzz Testing[Support for disabling pre-existing SAST rules](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets):
> GitLab [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/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](https://docs.gitlab.com/ee/user/application_security/#security-approvals-in-merge-requests) as well as reduce the number of vulnerabilities reported in the [security dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).
> 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](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets). We aim to provide [additional improvements](https://gitlab.com/groups/gitlab-org/-/epics/4179) like importing custom rulesets in `.gitlab-ci.yml` files in the future.
SAST[New vulnerability trends chart](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#project-security-dashboard):
> 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.
Vulnerability Management[Pipeline status in Project Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#vulnerability-report):
> 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.
Vulnerability Management[Coverage-guided fuzz test results are now human-readable](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#coverage-guided-fuzz-testing-ultimate):
> 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.
Fuzz Testing[Change Canary weights through the API](https://docs.gitlab.com/ee/user/project/canary_deployments.html):
> 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.
Advanced Deployments[Advanced Search Background Migrations for Elasticsearch Indexing](https://docs.gitlab.com/ee/integration/elasticsearch.html#background-migrations):
> 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](https://docs.gitlab.com/ee/integration/elasticsearch.html#trigger-the-reindex-via-the-advanced-search-administration) when needed.
Global Search[Date filtering and improved data table for MR Analytics](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/262061), as well as [approvals metadata](https://gitlab.com/gitlab-org/gitlab/-/issues/251079) and [pagination](https://gitlab.com/gitlab-org/gitlab/-/issues/229842) for the data table.
Code Analytics[Associate a release to a group milestone](https://docs.gitlab.com/ee/user/project/releases/#associate-milestones-with-a-release):
> In GitLab 13.0, you could [associate a release to a milestone](https://docs.gitlab.com/ee/user/project/releases/#associate-milestones-with-a-release) via a picker in the Gitlab UI. However, users leveraging [group milestones](https://docs.gitlab.com/ee/user/project/milestones/#project-milestones-and-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.
Release Orchestration[Milestone Burnup Charts and historically accurate reporting](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#burnup-charts):
> 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](https://docs.gitlab.com/ee/api/resource_state_events.html#issues) 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](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html#fixed-burndown-charts).
Issue Tracking[Filter by iterations in boards and issue lists](https://docs.gitlab.com/ee/user/search/#filtering-issue-and-merge-request-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.
Issue Tracking[Use a button to promote an issue to an epic](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#promote-an-issue-to-an-epic):
> Promoting an issue to an epic previously relied on the `/promote` [quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html) 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.
Issue Tracking[Display code coverage data for selected projects](https://docs.gitlab.com/ee/user/group/repositories_analytics/index.html#latest-project-test-coverage-list):
> In 13.4, we released the first iteration of [Code Coverage data for Groups](https://about.gitlab.com/releases/2020/09/22/gitlab-13-4-released/#code-coverage-data-for-all-projects-in-a-group) 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](https://gitlab.com/gitlab-org/gitlab/-/issues/231515).
Code Testing and Coverage[Auto Deploy to EC2](https://docs.gitlab.com/ee/ci/cloud_deployment/#custom-build-job-for-auto-devops):
> 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](https://aws.amazon.com/cloudformation/) API. Then, you can push your previously built artifact to an [AWS S3](https://aws.amazon.com/s3/) bucket, and deploy the content to an [AWS EC2](https://aws.amazon.com/ec2/) instance. Your EC2 deployment then automatically builds you a complete, automatic delivery pipeline without extra manual steps.
Continuous Delivery[Fire Webhook on Feature Flag change](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#feature-flag-events):
> 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](https://gitlab.com/ksashikumar) for a great community contribution!
Feature Flags[Sort releases by name in UI](https://docs.gitlab.com/ee/user/project/releases/#sort-releases):
> 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.
Release OrchestrationBug fixes
> Some of the notable bug fixes in 13.6 are:
>
> - [Packages/Composer: semantic version not fully supported](https://gitlab.com/gitlab-org/gitlab/-/issues/240887)
> - [Can't see multiple tags on Packages mobile](https://gitlab.com/gitlab-org/gitlab/-/issues/238594)
> - [Deploy tokens with `write_package_registry` should also have read permission](https://gitlab.com/gitlab-org/gitlab/-/issues/282499)
> - [Value Stream Analytics: Author and Assignees labels not working](https://gitlab.com/gitlab-org/gitlab/-/issues/276955)
> - [Value Stream Analytics: A deleted value stream remains active in the dropdown](https://gitlab.com/gitlab-org/gitlab/-/issues/263392)
> - [Code Quality merge request widget shows irrelevant data with pipelines for merged results](https://gitlab.com/gitlab-org/gitlab/-/issues/217981)
> - [Web IDE: Search text color is unreadable in Web IDE using the Monokai theme](https://gitlab.com/gitlab-org/gitlab/-/issues/235385)
> - [SAST Configuration UI: SAST_DEFAULT_ANALYZERS is incorrectly written with default value](https://gitlab.com/gitlab-org/gitlab/-/issues/260331)
> - [Can't update any release if milestone is linked to it](https://gitlab.com/gitlab-org/gitlab/-/issues/277369)
> - [Permanent links to release assets: not found (404)](https://gitlab.com/gitlab-org/gitlab/-/issues/217553)
> - [Timeout when using release-cli on private runners](https://gitlab.com/gitlab-org/release-cli/-/issues/63)
> - [Deployment status badges are not displaying properly](https://gitlab.com/gitlab-org/gitlab/-/issues/273393)
> - [dotenv variables are not available in bridge jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/233289)
> - [`interruptible` does not cancel child pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/208411)
> - [Some unicode characters in markdown are transformed into pictures](https://gitlab.com/gitlab-org/gitlab/-/issues/16309)
> - [Markdown with YAML rendering doesn't handle UTF8 BOM](https://gitlab.com/gitlab-org/gitlab/-/issues/20099)
> - [Focus broken on Issues "Labels" selector](https://gitlab.com/gitlab-org/gitlab/-/issues/276086)
> - [Issue label selection scrolling too far leading to usability problems](https://gitlab.com/gitlab-org/gitlab/-/issues/258602)
> - [Quick actions do not work when description contains code block](https://gitlab.com/gitlab-org/gitlab/-/issues/244289)
> - [Fix failing health status update](https://gitlab.com/gitlab-org/gitlab/-/issues/268161)
> - [Remove duplicate `iids` for Epics](https://gitlab.com/gitlab-org/gitlab/-/issues/277354)
> - [Fix link for attachments in Service Desk emails](https://gitlab.com/gitlab-org/gitlab/-/issues/254666)
> - [Apply Group-level labels with Service Desk templates](https://gitlab.com/gitlab-org/gitlab/-/issues/243790)
> - [workflow:rules variables can not access passed variables from upstream and trigger variables](https://gitlab.com/gitlab-org/gitlab/-/issues/206929)
> - [Missing "before_script" / "script" section in job output](https://gitlab.com/gitlab-org/gitlab/-/issues/270078)
> - [`artifacts:expire_in` in .gitlab-ci.yml does not practically work](https://gitlab.com/gitlab-org/gitlab/-/issues/220422)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - 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](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html#resources) now requests significantly more resources, 2G of memory instead of 650M and nearly a full core.
> - [Webservice](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html#memory-requestslimits) requests an additional 1GB of RAM, for 2.5G total.
> - NGINX controller [default replica count](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/1635/diffs) has been changed from 3 to 2, to reduce some resource consumption.
Cloud Native Installation[Install Runners with the GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/#example-projects):
> 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](https://docs.gitlab.com/ee/user/clusters/agent/#example-projects) 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.
Kubernetes Management, Infrastructure as Code[Export merge requests as a CSV](https://docs.gitlab.com/ee/user/project/merge_requests/csv_export.html):
> 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](https://docs.gitlab.com/ee/api/merge_requests.html#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.
Audit Reports[GitLab web interface now faster with automatic image resizing](https://docs.gitlab.com/omnibus/settings/image_scaling.html):
> 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](https://gitlab.com/gitlab-org/gitlab/-/commits/master), 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%](/blog/2020/11/02/scaling-down-how-we-prototyped-an-image-scaler-at-gitlab/).
Memory[Visualize users, projects, groups, issues, MRs, and pipeline activity](https://docs.gitlab.com/ee/administration/analytics/usage_trends.html) (self-managed only):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/233855), 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.
DevOps Reports[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - 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](https://www.pgbouncer.org/config.html#generic-settings).
> - 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](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4586), 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](https://mattermost.com/blog/mattermost-release-v5-28/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes in-product notifications for product updates, and much more.
Omnibus PackagePerformance 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](https://gitlab.com/gitlab-org/gitlab/-/issues/267010)
> - [More performant cleanup policy for tags](https://gitlab.com/gitlab-org/gitlab/-/issues/208193)
> - [Reduced site footprint by downscaling images](https://gitlab.com/groups/gitlab-org/-/epics/3822)
> - [Investigate and reduce end-points with biggest amount of CACHE SQL calls](https://gitlab.com/groups/gitlab-org/-/epics/4508)
> - [Snippets: Pre-fetch GraphQL requests with startupJS](https://gitlab.com/gitlab-org/gitlab/-/issues/271542)
> - [Remove complexity from blocking issue relationships](https://gitlab.com/gitlab-org/gitlab/-/issues/225919)
[Add chat notification when deployment starts](https://docs.gitlab.com/ee/user/project/integrations/slack.html#triggers-available-for-slack-notifications):
> 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](https://gitlab.com/ksashikumar)! This allows you to keep better track of the status of your deployments without disrupting your normal workflow.
Continuous Delivery[Create job to stop ECS review Apps](https://docs.gitlab.com/ee/ci/cloud_deployment/#deploy-your-application-to-the-aws-elastic-container-service-ecs):
> 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.
Continuous Delivery[Warn users on retrying outdated jobs](https://docs.gitlab.com/ee/ci/pipelines/settings.html#retry-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.
Continuous Delivery[Searchable user list in feature flag strategy](https://docs.gitlab.com/ee/operations/feature_flags.html#user-list):
> 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.
Feature Flags[Set Auto-Stop Environment Expiry Period on environment creation](https://docs.gitlab.com/ee/ci/environments/#environments-auto-stop):
> 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.
Review Apps[Use dedicated signing key for CI_JOB_JWT Vault Integration](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/#how-it-works):
> 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.
Secrets Management[Improved user experience for the group member list](https://docs.gitlab.com/ee/user/group/#add-users-to-a-group):
> Our group members list has been redesigned using the [Pajamas Design System](https://design.gitlab.com/). 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.
Subgroups[Admin approval required by default for new user registrations](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#require-administrator-approval-for-new-sign-ups):
> In GitLab 13.5, we introduced the option to [require administrator approval for new user registrations](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#required-approval-for-new-user-registration). 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.
Authentication and Authorization[Group-level management of project integrations](https://docs.gitlab.com/ee/administration/settings/project_integration_management.html):
> In GitLab 13.3, we added the ability to [enable an integration across an entire instance](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#instance-level-project-integration-management-for-external-services). 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](https://docs.gitlab.com/ee/integration/jira/). 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](https://about.gitlab.com/blog/2020/11/19/integration-management/).
Integrations[Unique design identifier](https://docs.gitlab.com/ee/user/project/issues/design_management.html#adding-designs):
> 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](https://gitlab.com/groups/gitlab-org/-/epics/3035), [Epics](https://gitlab.com/groups/gitlab-org/-/epics/2565) and the [Project Level](https://gitlab.com/groups/gitlab-org/-/epics/3033).
Design Management[Improved Design Management notifications](https://docs.gitlab.com/ee/user/profile/notifications.html#gitlab-notification-emails):
> 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.
Design Management[Customize the initial branch name for new projects within a group](https://docs.gitlab.com/ee/user/group/#custom-initial-branch-name):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/221013) 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.
Source Code Management[Include Git LFS files in repository archive](https://docs.gitlab.com/ee/topics/git/lfs/#lfs-objects-in-project-archives):
> 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.
Source Code Management[Filter Merge Requests by environment and deployment times](https://docs.gitlab.com/ee/user/search/#filtering-merge-requests-by-environment-or-deployment-date):
> 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.
Source Code Management[Merge Request templates for Static Site Editor changes](https://docs.gitlab.com/ee/user/project/static_site_editor/#edit-content):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/216861), 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.
Static Site Editor[Insert GitLab Snippets directly in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#insert-snippet):
> 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](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow), you can now insert snippets in to your working file, both single and [multi-file](/releases/2020/10/22/gitlab-13-5-released/#snippets-with-multiple-files) snippets are supported.
Editor Extension, Snippets[Issues and Merge Requests in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#view-issue-and-mr-details-and-comments-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](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#360-2020-10-26) of [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.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](https://gitlab.com/groups/gitlab-org/-/epics/4607).
Editor Extension[Configure destination for images uploaded from the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/index.html#static-site-editor-configuration-file):
> GitLab 13.6 introduces the ability to [upload image assets directly to your project from the Static Site Editor](#upload-images-in-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.
Static Site Editor[Upload images in the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#images):
> 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.
Static Site Editor[Display Code Quality severity ratings](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-widget):
> 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.
Code Quality[Generate HTML reports for Code Quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#generating-an-html-report):
> 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](https://gitlab.com/vicken.papaya)!
Code Quality[GitLab Runner 13.6](https://docs.gitlab.com/runner):
> 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](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/106)
> - [Enable PowerShell Core support in Docker-Windows executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/13139)
> - [Expose services to custom executor with $CI_JOB_SERVICES](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4358)
> - [Add Kubernetes Volumes subPath support](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3223)
> - [Add Kubernetes runners allowPrivilegeEscalation security context configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26998)
> - [Improve artifact/cache performance behind feature flag `FF_USE_FASTZIP`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26490)
> - [Set service entrypoint and command in `config.toml`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27173)
> - [Manage driver-defined job variables in custom executor](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2032)
> - [Cap maximum Docker Machine provisioning rate](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1038)
>
> ### Bug fixes
> - [Fix large cache uploads using Azure blob storage](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27123)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-6-stable/CHANGELOG.md).
GitLab Runner[Show coverage data even if the pipeline fails](https://docs.gitlab.com/ee/ci/pipelines/settings.html#pipeline-badges):
> 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.
Code Testing and Coverage[Unit Test Report UX improved](https://docs.gitlab.com/ee/ci/unit_test_reports.html#viewing-unit-test-reports-on-gitlab):
> 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.
Code Testing and Coverage[Support variables in rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges):
> 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.
Pipeline Authoring[Pipeline status in branch and tag lists](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines):
> 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](https://gitlab.com/leetickett) for this contribution!
Continuous Integration (CI)[Include multiple CI/CD configuration files as a list](https://docs.gitlab.com/ee/ci/yaml/#includefile)):
> 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.
Pipeline Authoring[The Dependency Proxy is now open source](https://docs.gitlab.com/ee/user/packages/dependency_proxy/):
> Docker Hub recently began to enforce [rate limits on pull requests from Docker Hub](https://docs.docker.com/docker-hub/download-rate-limit). 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.
Dependency Proxy[The npm project-level endpoint works with all npm commands](https://docs.gitlab.com/ee/user/packages/npm_registry/#project-level-npm-endpoint):
> 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.
Package Registry[New SAST severity data for Rails vulnerabilities](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data):
> When available from our security scan analyzers, GitLab [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/) 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](https://docs.gitlab.com/ee/user/application_security/#security-approvals-in-merge-requests) as fewer vulnerabilities will report 'Unknown' severity.
> In the future, we will [augment other analyzers missing vulnerability metadata](https://gitlab.com/groups/gitlab-org/-/epics/4004) and add a mechanism to allow [customized vulnerability metadata](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) enabling organizations to tailor results to match their risk profiles.
SAST[Create alerts on custom dashboards](https://docs.gitlab.com/ee/operations/metrics/alerts.html):
> 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.
Metrics[Tracing has been moved to Core](https://docs.gitlab.com/ee/operations/tracing.html):
> As part of our effort to [make the three pillars of observability available in our Core product offering](https://gitlab.com/groups/gitlab-org/-/epics/2310), 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](https://docs.gitlab.com/ee/operations/tracing.html).
Tracing