GitLab.org/GitLab: Release v13.9.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.9
Released: 2021-02-22
License: MIT
Release Assets:
[Improve SAML Timeout Experience](https://docs.gitlab.com/ee/user/group/saml_sso/#sso-enforcement) (SaaS only):
> When a user's SAML session for a GitLab.com group reaches the 7 day timeout limit, the user will no longer need to click a confirmation page to renew their session. GitLab will automatically reach out to the Group's Identity Provider to check for a valid session and extend it as needed. This change improves the group member's experience and opens the door for decreasing the SAML session timeout in the future.
Authentication and Authorization[Release Analytics at the group level](https://docs.gitlab.com/ee/user/project/releases/#release-metrics):
> In GitLab 13.9, you can view group-level release analytics. This provides you with an aggregated view of all release metrics for each of the projects associated to that group. You can view how many releases belong to this group and what percent of the projects are associated with releases. This feature also serves as a first iteration towards supporting [DORA 4](https://gitlab.com/groups/gitlab-org/-/epics/4358) metrics at the group level.
Release Orchestration[Email notifications when PAT / SSH Keys are revoked](https://docs.gitlab.com/ee/administration/credentials_inventory.html) (self-managed only):
> Managing your namespace includes ensuring you know who has access and how. To promote the security of Personal Access Tokens (PATs), you should be able to revoke a user’s PAT when appropriate. To support this control, we’ve added a revoke button for self-managed administrators to revoke these credentials as needed. Now you can manage your users’ PATs [and SSH keys](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#add-delete-buttons-to-the-ssh-tab-of-the-credential-inventory) from the Credential Inventory in a single screen.
>
> Your users will now also receive an email notification when their PAT(s) or SSH key(s) are revoked or deleted by an administrator. These improvements provide more control for you to manage your users' credentials and also provides transparency to the user so they can take actions to replace their credentials with minimal disruption.
Compliance Management[Dedicated URL for CI/CD dashboard tabs](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts):
> In 13.8, we added support for [deployment frequency charts](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts) under CI/CD Analytics. In this milestone, we added the ability to navigate directly to each of the CI/CD analytics charts by introducing a URL for each tab, making it easy to bookmark this page or send it to additional colleagues to view.
Continuous Delivery[JavaScript and Python support for coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#supported-fuzzing-engines-and-languages):
> You can now run coverage-guided fuzz tests against your Python and
> JavaScript apps! These are two of the most popular languages and we're
> excited to support them for use in coverage-guided fuzz testing.
>
> To run fuzz tests against apps written in these languages, use the
> [same workflow](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#configuration)
> you would for any other supported language. Create a fuzz testing
> job to run in your pipeline. When GitLab runs it, any fuzzing results
> automatically appear in the Security Dashboard, and in the Security
> tab of the pipeline.
Fuzz Testing[Create Jira issues from Vulnerabilities](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability):
> Many customers use Jira as their single source of truth for tracking issues and engineering work. When using GitLab for SCM and CI/CD, they can take advantage of our existing integration to pass information from MRs and commits into existing Jira issues. However, until now there has been no way to automatically pass information about vulnerabilities detected by security scanners into Jira. This leaves users who rely on Jira to track work no choice but to manually copy vulnerability information into new Jira issues.
>
> To address this, we're introducing a new ability to create Jira issues directly from a vulnerability's details. You will see this as a new option in your existing Jira integration settings. Simply enable the new option and select the desired Jira issue type. Available issue types are pulled automatically based on the currently configured Jira target project. Once enabled, all places in your project where you can create GitLab issues from a vulnerability will instead directly create a Jira issue of the configured type.
Vulnerability Management[Dependency Scanning now supports npm lock files v2](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> Users with node projects using npm 7's lock file version 2 are now supported. Previously, Dependency Scanning would output the following error:`[FATA] [Gemnasium] [2020-10-29T19:02:20Z] ▶ Wrong file format version`.
Dependency Scanning[Dependency Scanning support added for sbt 1.3.0](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> Users with Scala projects using `sbt` 1.3 and later can now benefit from Dependency Scanning. Previously only `sbt` versions 1.2 and below were supported.
Dependency Scanning[License Scanning now starts within its stage](https://docs.gitlab.com/ee/ci/yaml/#needs):
> Previously, the default behavior was to start License Scanning when the pipeline started. This behavior was unexpected and inconsistent with other GitLab Secure jobs. The default behavior has now been changed so that License Scanning starts when the stage it's in starts, not when the pipeline starts. If you have customized your `.gitlab-ci.yml` file and want your License Scanning job to only start when its stage starts, remove the `needs: []` statement. If you use the default template and wish to revert the behavior, add the `needs: []` statement.
License Compliance[Vulnerability Report Activity filter](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/):
> Vulnerability Reports are often the primary way security teams triage and manage vulnerabilities. The current filtering and sorting options provide quick ways to focus the list view on a subset of vulnerabilities for more efficient workflows. You can also see any vulnerabilities that have associated issues or which subsequent scans indicate are resolved. This Activity column indicates at a glance which vulnerabilities might be ready to close out, which are in progress, and which ones might need some attention. However, this column was not one you could filter or sort on!
>
> Now have even more control of your Vulnerability Report experience with the introduction of an Activity filter. Available in the Project, Group, and Security Center Vulnerability Reports, this new filter allows you to view vulnerabilities with issues that are not yet resolved, that are resolved but have no associated issues, that have issues and are resolved, or that have no activity. The available filter options are mutually exclusive sets, allowing you to drill into precisely the vulnerability list view you need for any task.
Vulnerability Management[Security Alert Dashboard for Container Network Policy Alerts](https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#configuring-network-policy-alerts):
> We're pleased to announce the first release of a dashboard for security
> alerts! Users can now configure Container Network Policies to send alerts
> to the security alert dashboard. This is especially useful when traffic
> must be closely monitored but cannot be blocked entirely without negatively
> impacting the business. You can configure the alerts at
> **Security & Compliance > Threat Management > Policies**, and view them at
> **Security & Compliance > Threat Management > Alerts**.
Security Orchestration, Container Network Security[Maintenance Mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html) (self-managed only):
> Systems administrators occasionally perform maintenance operations on their GitLab instance to keep it performing optimally. Administrators want to offer the highest level of access to their users while these operations are taking place. For example, you may want to perform [a failover test to a secondary site](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html) as part of the company's business continuity plan. Prior to the failover, you want to pause changes for a short period to ensure the secondary is fully synchronized. Until GitLab 13.8, you could [restrict users from logging in](https://docs.gitlab.com/omnibus/maintenance/#restrict-users-from-logging-into-gitlab), but this would block the entire UI and would render GitLab inaccessible to users.
>
> GitLab 13.9 introduces [maintenance mode](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html), where write operations are disabled at the application level. This means that GitLab is effectively in a read-only state for all non-administrative users (administrators are still able to edit application settings and [background jobs continue](https://docs.gitlab.com/ee/administration/maintenance_mode/index.html#background-jobs)). Regular users are able to log in to GitLab, view the interface and perform other read-only operations, such as `git clone` or `git pull`. Using maintenance mode, systems administrators can perform maintenance operations, such as failing over to a secondary site, with minimal disruption to regular users.
>
> Note that GitLab already [supports zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates) and enabling maintenance mode is not required to keep your instance up-to-date.
Disaster Recovery[ConfigMap support for Kubernetes Agent Server](https://docs.gitlab.com/ee/user/clusters/agent/#install-with-the-helm-chart):
> Users of Kubernetes Agent Server (kas) until now had to use command line arguments to customize their Agent Server installations. This setup proves inadequate for large-scale installations where declarative, repeatable setups are a core part of the workflow, and many arguments need custom settings. With the current GitLab release, the [Kubernetes Agent Server helm charts](https://docs.gitlab.com/charts/charts/gitlab/kas/) can be installed by custom configs that get merged with the default configurations to make it simple to integrate an Agent Server installation with existing observability and monitoring tools.
Kubernetes Management[Group webhooks for subgroups](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#subgroup-events):
> GitLab has made it easier for you to build subgroup management automation with a subgroup webhook. This webhook is triggered when a subgroup is created or deleted. Automation can now be built without relying on continuous API calls, which is cumbersome and puts an unnecessary performance load on your GitLab instance.
Subgroups[New merge request metric: mean time to merge](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html#mean-time-to-merge):
> A new metric, mean time to merge (MTTM), is available in project-level merge request analytics. MTTM is the average time from when a merge request (MR) is created, until the time it is merged. By selecting different dates in the date range selector, you can see how your time to merge MRs changes over time and understand whether you are becoming more efficient at reviewing and merging code.
Code Analytics[Show epic comments on user activity feeds](https://docs.gitlab.com/ee/user/#user-activity):
> Until now, interacting with epics didn't add a note to the user's activity page. This could have caused user to think they weren't creating, managing or interacting with an epic properly, or may simply have made it more difficult for them to find their recent activity.
>
> As of this release, you'll be able to view all of your epic activity on the user activity page and in user profiles and use it to track your collaboration on epics.
Epics[Filter roadmaps by confidentiality](https://docs.gitlab.com/ee/user/group/roadmap/#sort-and-filter-the-roadmap):
> When viewing a roadmap, there used to be no way to hide confidential epics from the main view. This could be frustrating if you wanted to share your roadmap with a public audience.
>
> In this release we've updated the search bar filter to include confidentiality. You now have another layer in which you can refine your roadmap.
Roadmaps[Filter roadmaps by milestones](https://docs.gitlab.com/ee/user/group/roadmap/index.html#sort-and-filter-the-roadmap):
> Communicating your strategic plans or reporting on current work in flight requires being able to focus and filter the view of your roadmap. Further refine your roadmap view by filtering the visible epics by milestone.
>
> This feature was behind a feature flag since GitLab 13.7, and now it's available for everyone.
Roadmaps[Bulk edit iterations on issues in groups and projects](https://docs.gitlab.com/ee/user/group/bulk_editing/index.html#bulk-edit-issues-at-the-group-level):
> Instead of having to manually update the iteration on issues one at a time, you can now bulk update iterations from the issue list of a group or project.
Issue Tracking[Override Gitaly Cluster replication factor for specific repositories](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#replication-factor) (self-managed only):
> Previously, the replication factor of a Gitaly Cluster was the number of nodes in the cluster. This made it impossible to enable Gitaly Cluster for GitLab instances with very large storage requirements. For example, a 500 TB cluster with 50 nodes would require 25 PB of storage space to be provisioned. To enable Gitaly Cluster to be used for instances with large storage requirements, a way was needed to specify a replication factor less than the total number of nodes in the cluster.
>
> In GitLab 13.9, the replication factor for each repository can be set individually to any number less than the number of nodes in the cluster. This allows for replication of only the most important or active repositories, leaving other less critical repositories on a smaller number of nodes. This will allow organizations to tune their clusters to their own storage and budget constraints. We have also enabled a method to configure a default replication factor for all newly created repositories. This should provide users the necessary means to horizontally scale their Gitaly Cluster.
Gitaly[Group code coverage data graph](https://docs.gitlab.com/ee/user/group/repositories_analytics/index.html#current-group-code-coverage):
> Previously released, [group code coverage data](https://about.gitlab.com/releases/2020/11/22/gitlab-13-6-released/#display-code-coverage-data-for-selected-projects) is an easy way to see current test coverage of the projects in a group and to get raw data for visualization outside of GitLab. Group code coverage data now includes a graph of the average coverage for all of a group's projects so you can see how test coverage for the group is trending over time at a glance.
Code Testing and Coverage[Resource Group for multi-project and parent-child pipelines](https://docs.gitlab.com/ee/ci/resource_groups/index.html#pipeline-level-concurrency-control-with-cross-projectparent-child-pipelines):
> You can now benefit from using [resource groups](https://docs.gitlab.com/ee/ci/resource_groups/index.html#pipeline-level-concurrency-control-with-cross-projectparent-child-pipelines) if your deployment process uses [child pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html) or [multi-project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html). Such pipelines may contain multiple stages, multiple jobs, and even span across multiple projects. Resource groups ensure only one downstream deployment pipeline runs at a time so you can deploy safely. Previously, `resource_group` only supported deployment jobs in the same project.
Continuous Delivery[Follow user activity](https://docs.gitlab.com/ee/user/index.html#user-activity):
> GitLab users can now follow other users' activity in GitLab! Following users helps you to stay updated on activity by team mates and key project contributors. You can follow or unfollow other users from their user profiles. To see their activity go to the top-level Activity view, and select the Followed Users tab.
>
> Thanks to the amazing work from GitLab contributor [Roger Meier](https://gitlab.com/bufferoverflow) from [Siemens](https://gitlab.com/siemens) over the past 3 months, this feature is now available in 13.9.
Users[Markdown links for Feature Flags](https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references):
> This release adds Markdown linking for Feature Flags. Users can mention `[feature_flag:Feature Flags[Allow Deploy Keys to push to protected branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#allow-deploy-keys-to-push-to-a-protected-branch):
> Prior to GitLab 12.0, Deploy Keys with write access could push commits to protected branches. Support for this was removed due to security concerns, but many users still requested it, as they were using it to ensure that only users with Deploy Keys could push to their repositories. It also eliminates the need to use a service user or machine user, which ties up a license for any team that wants to allow Deploy Keys to push to protected branches just for this use case. We are excited to announce that we resolved this issue and now Deploy Keys can push to protected branches once more while abiding by security best practices. By moving towards an isolated permission model for Deploy Keys, users can now select Deploy Keys to link to protected branches directly from the settings page on protected branches.
Continuous DeliveryBug fixes
> Some of the notable bug fixes in GitLab 13.9 are:
>
> - [Opening Admin Settings page results in the 500 error](https://gitlab.com/gitlab-org/gitlab/-/issues/299991)
> - [Unit test report not populating when filename attribute is not present](https://gitlab.com/gitlab-org/gitlab/-/issues/301140)
> - [Builds with a dot "." in their name fails to load test details in the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/254643)
> - [SAST flawfinder fails in sast CI job with UnicodeDecodeError error](https://gitlab.com/gitlab-org/gitlab/-/issues/7020)
> - [SAST security-code-scan panics: index out of range error](https://gitlab.com/gitlab-org/gitlab/-/issues/321225)
> - [Housekeeping is not run on wiki repos, causing performance degradation over time](https://gitlab.com/gitlab-org/gitlab/-/issues/296892)
> - [Create issue from Vulnerability details - Edited text is discarded](https://gitlab.com/gitlab-org/gitlab/-/issues/299462)
> - [Description of Vulnerability is empty in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/issues/294173)
> - [Network policy preview for `deny all` shows as `allow all`](https://gitlab.com/gitlab-org/gitlab/-/issues/270130)
> - [Error "Filenames contained invalid characters" when attaching images to ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/320903)
> - [`not_adjacent` error when moving designs around](https://gitlab.com/gitlab-org/gitlab/-/issues/300071)
> - [Bug with roadmaps where epics show up twice in the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/294428)
> - [When adding sub epic from sub group, wrong epic is added](https://gitlab.com/gitlab-org/gitlab/-/issues/224176)
> - [Geo: Fix concurrent VerificationBatchWorker jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/300051)
> - [gitlab-ctl promotion-preflight-checks incorrectly fails with 0%](https://gitlab.com/gitlab-org/gitlab/-/issues/298725)
> - [UpdatePagesService jobs may cause backup jobs to fail with error 'directory has vanished'](https://gitlab.com/gitlab-org/gitlab/-/issues/244397)
> - [Dependency Scanning analyzer was not updating the Vulnerability Database each scan for specific customers. Please read our blog for more details. Impacted customers are:](https://about.gitlab.com/blog/2021/02/19/secure-composition-analysis-bug-not-updating-database/)
> - Customers with an edited Dependency Scanning template that pins their analyzers to a non-major-only tag (for example gemnasium:2.27.0)
> - Customers running in an [Offline Environment](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)
> - Customers that have a mirror of the analyzer docker registry
> - self-managed customers with a pull policy of never or if-not-present.
> - [Resource events created via the issue update API does not follow the `updated_at` param](https://gitlab.com/gitlab-org/gitlab/-/issues/233708)
> - [Project labels API return "404 Label Not Found" if label name contains dot "."](https://gitlab.com/gitlab-org/gitlab/-/issues/223618)
> - [Project name to path conversion in API mangles dots](https://gitlab.com/gitlab-org/gitlab/-/issues/18292)
> - [Iteration reports not scoping correctly](https://gitlab.com/gitlab-org/gitlab/-/issues/299918)
> - ["List pipeline jobs" GitLab API does not return an information about retired jobs anymore](https://gitlab.com/gitlab-org/gitlab/-/issues/272627)
> - [Delayed and manual jobs with DAG are not skipped even they need a failed job](https://gitlab.com/gitlab-org/gitlab/-/issues/281878)
[User Busy status in issue and MR sidebar](https://docs.gitlab.com/ee/user/profile/#busy-status-indicator):
> In 13.8 we [added a User Busy indicator](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#busy-status-indicator) to indicate whether coworkers are available for code reviews and other tasks. In this release, we've now included the User Busy indicator in the Assignee section of issue and merge request sidebars.
Insights[Vault JWT (JSON Web Token) supports GitLab environments.](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html):
> To simplify integrations with HashiCorp Vault, we've shipped
> Vault JWT token support. From the launch, you could restrict access based on
> data in the JWT. This release gives you a new dimension for restricting
> access to credentials: the environment a job targets.
>
> This release extends the existing Vault JWT token to support environment-based
> restrictions too. As the `environment` name could be supplied by the user running
> the pipeline, we recommend you use the new environment-based restrictions with the
> already-existing `ref_type` values for maximum security.
Secrets Management[Sort global search results by last updated time](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> You can choose to sort search results on the GitLab search result page. In GitLab 13.9, we added the ability to sort issues and merge requests results by their last updated time.
Global Search[Access Control for Pages is now supported for Kubernetes deployments of GitLab](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html) (self-managed only):
> [In GitLab 13.8](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#gitlab-pages-is-now-available-for-kubernetes-deployments-of-gitlab) initial support for GitLab Pages was introduced for deployments of GitLab on Kubernetes, allowing users to easily deploy static websites.
>
> With the release of GitLab 13.9, [Access Control](https://docs.gitlab.com/ee/user/project/pages/pages_access_control.html) is now supported, optionally restricting access to the pages site to members of the project. All Pages features are now supported in the [GitLab Helm chart](https://docs.gitlab.com/charts/).
Cloud Native Installation[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - Access Control for GitLab Pages is [now available for Kubernetes deployments](#access-control-for-pages-is-now-supported-for-kubernetes-deployments-of-gitlab).
> - It is now possible to set labels on all objects, such as deployments and horizontal pod autoscalers, in a more configurable manner. A new [`common.labels` setting](https://docs.gitlab.com/charts/charts/gitlab/gitaly/#installation-command-line-options) is available for each subchart.
> - It is now possible to [enable proxy protocol support](https://docs.gitlab.com/charts/charts/globals.html#tcp-proxy-protocol), to support SSH in environments with an upstream proxy that adds the proxy protocol header, such as AWS ELB's.
> - `redis` has been updated to 6.0.10, and `gitlab-exporter` to v10
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab's repository installation script now [utilizes CentOS 7 packages for Amazon Linux 2 systems](https://docs.gitlab.com/omnibus/update/#gitlab-137-and-later-unavailable-on-amazon-linux-2). Existing deployments of GitLab on Amazon Linux 2 can re-run the installation script to update. Note Amazon Linux 2 is not currently [officially supported](https://gitlab.com/groups/gitlab-org/-/epics/2195).
> - `redis` has been updated to 6.0.10, `logrotate` to 3.18.0, and `libtiff` to 4.2.0
> - GitLab 13.9 includes [Mattermost 5.31.1](https://mattermost.com/blog/mattermost-release-v5-31/), an [open source Slack-alternative](https://mattermost.com/) whose newest Extended Support Release offers bug fixes for increased stability and improvements in plugins. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
Omnibus Package[Manage Project Access Tokens through the API](https://docs.gitlab.com/ee/api/resource_access_tokens.html):
> In GitLab 13.9, we introduced an API to manage [project access tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens). API Access for project access tokens enable integration for users that want to control project access tokens provisioning in external systems or through custom automation.
Authentication and Authorization, API[GitLab Exporter uses significantly less memory](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_exporter.html) (self-managed only):
> GitLab exporter measures various metrics from Redis and the database. We've reduced the memory consumption of GitLab exporter by ~60% (~67-71MB) by optimizing its configuration.
>
> This is especially important when running GitLab exporter in memory-constrained environments.
Metrics[Reduced Puma memory consumption on small instances](https://docs.gitlab.com/omnibus/settings/puma.html#running-in-memory-constrained-environments):
> By default Puma, the web server used by GitLab, uses multiple workers
> to improve performance. This is important for scaling GitLab but also results in increased memory consumption.
>
> Small instances with few users and limited resources might not require
> multiple workers. For this use case, GitLab now supports running Puma in
> single mode, which reduces the memory consumption of the application at
> rest by around 250 MB.
>
> Check out the [list of current limitations](https://docs.gitlab.com/omnibus/settings/puma.html#running-in-memory-constrained-environments).
> when running Puma in single mode.
MemoryPerformance 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.9, we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.9 are:
>
> - [Multi-label search 5x-10x faster](https://gitlab.com/gitlab-org/gitlab/-/issues/259719#note_453699556)
> - [MR Analytics page load over 7x faster](https://gitlab.com/gitlab-org/gitlab/-/issues/276386#note_495096013)
> - [Set 1 second server side timeout on Elasticsearch counts](https://gitlab.com/gitlab-org/gitlab/-/issues/301146)
> - [Remove N+1 when loading labels in search dropdowns](https://gitlab.com/gitlab-org/gitlab/-/issues/299467)
> - [Improve epics limit in when rendering Roadmaps](https://gitlab.com/gitlab-org/gitlab/-/issues/285440)
> - [Remove `blocked_by` from issue link queries](https://gitlab.com/gitlab-org/gitlab/-/issues/281703)
[Support PRIVATE-TOKEN to create releases using the Release-CLI](https://docs.gitlab.com/ee/api/releases/#create-a-release):
> In this milestone, we added the ability to use the release-cli with a `PRIVATE-TOKEN` as defined in the [Create a release](https://docs.gitlab.com/ee/api/releases/#create-a-release) API documentation. This enables overriding the user that creates a release, and supports automation by allowing connection of a project-level `PRIVATE-TOKEN` or by using a bot user account's `PRIVATE-TOKEN`.
Release Orchestration[Keyboard shortcut to toggle between GitLab and GitLab Next](https://docs.gitlab.com/ee/user/shortcuts.html):
> This milestone introduces a keyboard shortcut that toggles between [GitLab](https://gitlab.com/) and [GitLab Next](https://next.gitlab.com/). By using the `g` and `x` keys, which work from any area of GitLab, you can easily switch between GitLab and GitLab Next. A huge thanks to [Yogi](https://gitlab.com/yo) for a great community contribution!
Advanced Deployments[Improved user experience for the projects member list](https://docs.gitlab.com/ee/user/project/members/):
> Our project members list has been redesigned to help project administrators quickly identify key attributes about their members for more effective user management. It includes more descriptive terminology, a new layout, headers for all columns, tooltips for key data elements, and more!
Authentication and Authorization[Request a follow-up review from a Reviewer](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#request-a-new-review):
> Merge request authors receive [feedback from reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/). Often, this feedback needs to be re-reviewed to make sure all issues have been appropriately addressed. As the author of the contribution, you need to communicate the need for a follow-up to your reviewer.
>
> For reviewers who have already [reviewed a merge request](https://docs.gitlab.com/ee/user/discussions/#merge-request-reviews), you can now request a re-review. This request triggers a To-Do item and email notification to alert the user that you need a follow-up review of your contribution.
Code Review[Improvements to the GitLab.com for Jira Cloud Application](https://docs.gitlab.com/ee/integration/jira/connect-app.html):
> You can now sync your Jira Cloud project data with GitLab by using the [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?tab=overview&hosting=cloud) application, available on the Atlassian Marketplace. This plugin displays information about your branches, commits, merge requests, deployments, and feature flags in the Jira Development Panel. Use it to see the current status of work in progress, then quickly navigate back to those pages inside of GitLab.
>
> To make these features easier to use, we've made significant improvements to the initial setup process over the last few milestones, and now getting your GitLab namespaces connected is easier than ever. To get started, check it out on [the Atlassian Marketplace](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?tab=overview&hosting=cloud).
Integrations[Autocomplete GitLab CI Variables in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#ci-variable-autocompletion):
> GitLab CI is fast and highly configurable, but it can be hard to remember all the [predefined environment variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), and the wrong typo can make your `.gitlab-ci.yml` file invalid. To make it easier to configure your GitLab CI pipeline, the [3.11.0 Release](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3110-2021-01-25) of [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) provides auto completion for predefined environment variables when editing your `.gitlab-ci.yml` file.
>
> Tooltips in the auto complete dialog provide information on what the variable can be used for as well as information on supported GitLab and Runner versions. These additional pieces of information really help to ensure your CI configuration will be valid.
>
> Thanks to [@KevSlashNull](https://gitlab.com/KevSlashNull) for the contribution!
Editor Extension[Merge Refs for changes in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/versions.html#head-comparison-mode-for-merge-requests):
> Merge request diffs have been calculated by `git diff target...source` which compares `HEAD` of the target with the merge base of `target` and `source`. This works well, until changes from the target branch are merged into the source branch, creating a complete mess of the diff.
>
> Merge requests now compare to `Code Review[View code review comments in VS Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#merge-request-reviews):
> In a previous release of GitLab Workflow for VS Code it became possible for you to view [merge request changes](/releases/2020/12/22/gitlab-13-7-released/#view-merge-request-changes-in-vs-code) in VS Code. However, seeing the changes proposed by a merge request is only part of reviewing that change and being able to respond to feedback.
>
> With [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) [3.10.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3100-2021-01-19), comments provided on changes are now available as part of the diff view. This greatly improves your ability to action feedback provided on your merge request directly in the editor without the additional context switch between VS Code and GitLab.
>
> We're continuing to expand on [Code Review experiences in VS Code](https://gitlab.com/groups/gitlab-org/-/epics/4607). [Responding to comments](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/269) is up next.
Editor Extension[Apply a suggestion with a custom commit message](https://docs.gitlab.com/ee/user/discussions/#suggest-changes):
> [Suggesting changes](https://docs.gitlab.com/ee/user/discussions/#suggest-changes) to a merge request makes code review faster and easier by quickly proposing changes and applying the given feedback at a click of a button. However, we had a default commit message for applied suggestions that couldn't be customized, preventing users from describing the change and eventually violating the project's commit messages guidelines.
>
> As a result, merge request authors were often forced to squash commits for the whole merge request, or having to manually apply suggestions locally, or going back and rewording the commits after applying the suggestions.
>
> When applying a suggestion you're now able to write a custom commit message. This allows authors and contributors to accept suggestions and follow commit message best practices for their projects. If no custom commit message is specified the suggestion is committed with a default commit message.
Code Review[Mark changes as viewed in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#mark-files-as-viewed):
> When reviewing a merge request that changes many files, it is challenging to keep track of which files you have already reviewed. Reviews are inefficient when you're required to re-review or spend additional time regaining context on each file in the merge request.
>
> Files can now be marked as **Viewed** in merge requests to help signal to yourself that the file has been reviewed. This change allows reviewers to quickly stay up to speed on what they've reviewed and what still needs to be reviewed for the merge request.
Code Review[Create changelogs using the GitLab API](https://docs.gitlab.com/ee/api/repositories.html#generate-changelog-data):
> Previously, generating a changelog using GitLab was a manual process. Release Managers had to collect all the changes for a given release and then manually add them to a changelog file, which was time-consuming and prone to error. To make this process easier, we have now added an API that will automatically generate a changelog for a given release based on commit history. This enables development teams to better communicate changes to end users by delivering a consistent and comprehensive set of changelogs for every release.
Source Code Management, Release Orchestration[Easily see repeat failed tests in Unit Test Reports](https://docs.gitlab.com/ee/ci/unit_test_reports.html#number-of-recent-failures):
> When you are reviewing failed tests in a pipeline, it's difficult to tell if a failing test is a legitimate failure that needs investigation or a flaky test that will pass on the next execution.
>
> The next iteration of the [repeat failed test counter](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#repeat-failed-test-counter) adds the repeat failed test counter to the unit test report. Now you can see how often a test has failed on the default branch without needing a merge request associated with the test execution.
Code Testing and Coverage[Select CI/CD configuration from any job and reuse it](https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#reference-tags):
> Previously, if you wanted to reuse the same configuration in multiple jobs, you had two options: add YAML anchors, which don't work across different configuration files, or use `extends` to reuse an entire section.
>
> In this release, we've added a new YAML function called `!reference`, which lets you target the exact configuration you want to reuse as part of your CI/CD pipeline, even if it's in another file.
Pipeline Authoring[View an expanded version of the CI/CD configuration](https://docs.gitlab.com/ee/ci/pipeline_editor/#view-expanded-configuration):
> When configuring pipelines, you use keywords like [`include`](https://docs.gitlab.com/ee/ci/yaml/#include) and [`extends`](https://docs.gitlab.com/ee/ci/yaml/#extends) often. These keywords help break down one long pipeline configuration file into multiple files, which increases readability and reduces duplication. Unfortunately, those keywords can make a pipeline configuration hard to follow. In some configurations, a [pipeline configuration file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab-ci.yml#L91) can be mostly composed of a list of other included configuration files.
>
> In this release, you can view a version of your pipeline configuration with all of the `include` and `extends` configurations merged together. It's now much easier to understand more complex pipeline flows and simplifies the debugging process.
Pipeline Authoring[Install GitLab Runner more easily with in-product help](https://docs.gitlab.com/runner/install/):
> When you're not using the shared runners on GitLab.com, getting started with GitLab CI requires installing GitLab Runner and registering the runner to execute jobs in your pipeline. While the GitLab Runner installation process is well-documented, one of our goals is to make it as easy as possible for users to get started with GitLab CI. An initial step on this journey is to release a new GitLab Runner guided install modal window. With this feature, you can select a target platform, copy, and run the install commands without navigating away from the GitLab UI.
GitLab Runner[GPU and smart scheduling support for GitLab Runner](https://docs.gitlab.com/runner/executors/docker_machine.html#using-gpus-on-google-compute-engine):
> Specialized compute workloads like those used in machine learning can significantly benefit from access to GPUs. Developers can configure GitLab Runner to leverage GPUs in the Docker executor by forwarding the `--gpu` flag. You can also use this with recent support in [GitLab's fork of Docker Machine](https://docs.gitlab.com/runner/executors/docker_machine.html#using-the-forked-version-of-docker-machine), which allows you to [accelerate workloads with attached GPUs](https://cloud.google.com/compute/docs/gpus/create-vm-with-gpus). Doing so can help control costs associated with potentially expensive machine configurations.
GitLab Runner[GitLab Runner 13.9](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.9 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:
>
> - [Add support for Nvidia docker runtime to the Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4355)
> - [Control cache ZIP compression level](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4907)
> - [Show artifact/cache upload progress](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27429)
> - [Upgrade to PowerShell Core in Windows helper an CI image to 7.1.1](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2696)
> - [Enable PowerShell Core support in Docker executor on Linux](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4021)
> - [Enable PowerShell Core support in Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/13145)
> - [Automatically authenticate with the Dependency Proxy](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27302)
> - [Use configured helper image for updating permissions in Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27393)
> - [Connect to gitlab instance using self-signed cert with runner on OpenShift](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/12)
>
> Bug Fixes:
>
> - [Gitlab CI script doesn't pass exit code of previous command properly](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25394)
> - [Windows service "shutdown timed out"](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4173)
> - [Variable masking issue with repeating characters](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/16705)
> - [OpenShift Operator-concurrent property of config.toml defined in config map not used](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26898)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-9-stable/CHANGELOG.md).
GitLab Runner[Instance configuration to control latest artifacts storage](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#keep-the-latest-artifacts-for-all-jobs-in-the-latest-successful-pipelines)
> In the [last release](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#project-configuration-to-control-storage-of-latest-artifacts),
> we wanted to improve storage consumption management by adding a project setting
> to disable keeping the latest artifacts. GitLab recognizes that as a self-managed
> user, you may want to opt-out for your entire instance, so we have added a
> one-click option for you to disable keeping the latest artifacts for all your projects.
[Access webhook pipeline trigger payloads in CI/CD jobs](https://docs.gitlab.com/ee/ci/triggers/#use-a-webhook-payload):
> When triggering a pipeline with a webhook, the webhook's payload was not accessible from any jobs in the resulting pipeline. In some cases, the payload carries important information that can determine how the triggered pipeline should work. In this release, we've added a new predefined variable to capture the webhook payload so you can easily incorporate it within your triggered pipelines.
Pipeline Authoring[Automatically authenticate when using the Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-within-cicd):
> By proxying and caching container images from Docker Hub, the Dependency Proxy helps you to improve the performance of your pipelines. Even though the proxy is intended to be heavily used with CI/CD, to use the feature, you had to add your credentials to the `DOCKER_AUTH_CONFIG` CI/CD variable or manually run `docker login` in your pipeline. These solutions worked fine, but when you consider how many `.gitlab-ci.yml` files that you need to update, it would be better if the GitLab Runner could automatically authenticate for you.
>
> Since the Runner is already able to automatically authenticate with the integrated GitLab Container Registry, we were able to leverage that functionality to help you automatically authenticate with the Dependency Proxy.
>
> Now it's easier to use the Dependency Proxy to proxy and cache your container images from Docker Hub and start having faster, more reliable builds.
Dependency Proxy[Allow or prevent duplicate Maven uploads](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagesettings):
> You can use the GitLab Package Registry to publish your Java dependencies with Maven or Gradle. By default, you can publish the same package name and version multiple times. This default was chosen based on the behavior of the most common public registries.
>
> However, many of you have expressed that you'd like to prevent duplicate uploads, especially when it comes to releases. We've added a new group setting for the Package Registry, and you can now choose whether you'd like to allow or prevent duplicate Maven or Gradle uploads. As mentioned, to match the behavior of the public registries, duplicates will be allowed by default.
>
> You can adjust this setting by using the [GitLab API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagesettings) or from the application by navigating to **Settings > Packages & Registries**. In the coming milestones, we plan to expand this setting for each package manager format and add it to the user interface. Please follow along in the [epic](https://gitlab.com/groups/gitlab-org/-/epics/5070) or consider contributing a change!
Package Registry[Multi-project support for .NET SAST scanning](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> GitLab [security scans](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools) automatically detect code language and run appropriate analyzers. With monorepos, microservices, and multi-project repositories, more than one project can exist within a single GitLab repository. Previously our .NET SAST tool could only detect single projects in repositories. With this release, our .NET SAST analyzer can [now intelligently detect multiple solution files (.sln) in .NET projects](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) and report vulnerabilities across them. This will make it easier and more streamlined for users with multi-project .NET repos to leverage our SAST scanning.
SAST[SAST Support for .NET 5](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data):
> Microsoft's [release of .NET 5.0](https://docs.microsoft.com/en-us/dotnet/core/dotnet-five) is the next major release of .NET Core which supports more types of apps and more platforms than .NET Core or .NET Framework. We have updated our .NET SAST analyzer, [Security Code Scan](https://security-code-scan.github.io/) to support this new version which is also now supported with [our SAST language detection](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) allowing GitLab SAST to automatically detect .NET 5 projects. This change was part of a community contribution by [@shaun.burns](https://gitlab.com/shaun.burns).
SAST[Improved Android SAST Support](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v250):
> Since GitLab 13.5, we've supported [mobile SAST](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps) via MobSF. We've updated this analyzer to version 2.5 which includes many improvements to mobile scanning capabilities for Android. Major improvements include: adding OWASP MSTG mappings for improved vulnerability information, support for [Android 10 API 29](https://developer.android.com/about/versions/10/features), xapk support, and National Information Assurance Partnership (NIAP) [analysis](https://www.niap-ccevs.org/MMO/PP/394.R/pp_app_v1.2_table-reqs.htm) for Android.
>
> Our Mobile SAST security scanner is still considered experimental and requires [enabling experimental features](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features) via a CI variable, `SAST_EXPERIMENTAL_FEATURES`. We expect to remove this requirement in an upcoming GitLab release.
SAST[Security Configuration page for all users](https://docs.gitlab.com/ee/user/application_security/configuration/):
> With SAST and Secret Detection [available to all GitLab customers](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#sast-security-analyzers-available-for-all), we wanted to improve the experience for developers enabling available security scans. We have had a guided configuration experience for Ultimate users and have now made a simplified version of this experience available to all users. This new configuration experience makes it easier for developers to understand which security scans are available to them, find relevant documentation, and provide simple enablement tools. With this initial release, we support a button to create a merge request for SAST. In a future release, we will add additional buttons to easily enable other scan types.
SAST, Secret Detection[Expanded support for Ruby in SAST scans](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> We want to help developers write better code and worry less about common security mistakes. [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being contributed and mitigate proactively. We've updated our Ruby on Rails [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) (Brakeman) to [a new version](https://brakemanscanner.org/blog/2021/01/26/brakeman-5-dot-0-dot-0-released) (v5) which adds support for most Ruby files, not just Rails projects. This change expands the types of Ruby projects we support and introduces new detection rules. If you have a custom [`SAST.gitlab-ci.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml), or [override the GitLab SAST brakeman job](https://docs.gitlab.com/ee/user/application_security/sast/#overriding-sast-jobs), you may need to [update your CI file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L55) to enable this additional scanning.
SAST[Assign incidents to milestones](https://docs.gitlab.com/ee/operations/incident_management/manage_incidents.html#other-actions):
> Not all incidents have the same severity. Many incidents must be immediately addressed to restore the services customers depend on. But some incidents are less critical and can be prioritized against other work and scheduled for a specific release or milestone for implementation. You can now assign low-severity incidents to a milestone from the right sidebar to manage them from your issue boards.
Incident Management