GitLab.org/GitLab: Release v13.5.0-ee

Name: GitLab

Owner: GitLab.org

Release: GitLab 13.5

Released: 2020-10-22

License: MIT

Release Assets:

 

[Configuration option to allow Deploy Keys to push to protected branches](https://docs.gitlab.com/ee/ssh/#deploy-keys) (self-managed only): Continuous Delivery

> In release 12.0, we updated Deploy Keys so that keys with write access could no longer push commits to protected branches. As a workaround for this limitation, some users removed access restrictions to the master branch, leaving it unprotected and allowing all developers to push to master. > > This increases security risks, so in order to provide a better option we have decided to re-enable the previous behavior through a configuration setting.

[Project access tokens for GitLab.com](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) (SaaS only): Authentication and Authorization

> In GitLab 13.3, we introduced [project-level access tokens for self-managed instances](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#project-access-tokens), allowing access to a project without the need to provision a new user. > > We are now making project-level access tokens available in GitLab.com! Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API and Git. Project access tokens will not increase the licensed seat count and are authorized as Maintainers. This new functionality will make programmatic access to GitLab easier, more secure, and less cost prohibitive.

#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)  

[Add Delete buttons to the SSH tab of the Credential Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html#delete-a-users-ssh-key): Compliance Management

> Managing your namespace includes ensuring you know who has access and how. To promote the security of SSH keys, you should be able to delete a user's SSH key when appropriate. To support this control, we've added a delete button for self-managed administrators to delete these keys as needed. > > Now you can manage your users' SSH keys from the [Credential Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html#credentials-inventory) from a single screen.

##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)

[Add requirements description](https://docs.gitlab.com/ee/user/project/requirements/index.html): Requirements Management

> Requirements Management improves productivity when it's possible to add additional details such as verification criteria, acceptance criteria, and rationale from within your tool. > > GitLab Requirements Management now supports users adding detail information and content to streamline managing their requirements in a GitLab Markdown-enabled description field for each requirement.

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[SAST configuration UI improvements](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui): SAST

> The [GitLab SAST configuration UI tool](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui) has been extended to support additional setting options and can now update simple existing GitLab CI/CD files. We believe that [security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort) and this configuration experience makes it easier for non-CI/CD experts to get started with GitLab SAST. The tool helps a user create a merge request to enable SAST scanning while leveraging best configuration practices like using the GitLab-managed [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) and properly [overriding template settings](https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings). > > The Configuration UI now supports the configuration of [specific SAST analyzer settings](https://docs.gitlab.com/ee/user/application_security/sast/index.html#analyzer-settings) which allow organizations to tailor SAST results to their security preferences. The Configuration UI can now also update existing simple `.gitlab-ci.yml` files, allowing the tool to be used with projects that already have GitLab CI/CD setup. We will also [expand access to this tool to GitLab Core users](https://gitlab.com/gitlab-org/gitlab/-/issues/241377) in an upcoming GitLab release.

[Customizing SAST & Secret Detection rules](https://docs.gitlab.com/ee/user/application_security/sast/#custom-rulesets): SAST, Secret Detection

> GitLab [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) and [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/) now support customizing detection rules. This allows GitLab users to change the vulnerability detection defaults to tailor results to their organization's preferences. SAST custom rulesets allow you to exclude rules and modify the behavior of existing rules. Secret Detection now supports disabling existing rules and adding new regex patterns that allow the detection of any type of custom secret. > > Custom rulesets can be defined by adding a new file to the `.gitlab` folder named `sast-ruleset.toml` or `secret-detection-ruleset.toml` containing customizations written 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/#custom-rulesets) and [Secret Detection custom rulesets](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-rulesets). We [intend to provide additional support for importing custom rulesets](https://gitlab.com/gitlab-org/gitlab/-/issues/257928) in `.gitlab-ci.yml` files in the future.

#### [Premium](https://about.gitlab.com/pricing/premium/)  

[Failed two-factor authentication sign-ins now captured in Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html#instance-events): Audit Events

> Full traceability and auditability of your GitLab namespace is critical to a successful security compliance program. It is important to know when a two-factor authentication attempt has failed, since it suggests that a user or bad-faith actor knows an account password but does not have access to the second factor device. > > In GitLab 13.5, you can now evaluate the number of failed two-factor authentication attempts to help inform your decisions. You can find failed two-factor authentication attempts tracked in the Audit Events table at the instance level. Support for group level is coming in a future iteration.

[View Kubernetes Agents list](https://docs.gitlab.com/ee/user/clusters/agent/): Kubernetes Management

> GitLab now helps you manage your Kubernetes agents by displaying your agents and their configurations in the GitLab user interface. More insights and management tools for your agents [are planned for future releases](https://gitlab.com/gitlab-org/gitlab/-/issues/230571).

[Delete a value stream](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#deleting-a-value-stream): Value Stream Management

> Previously in GitLab 13.3, we introduced [multiple value streams per group](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#create-multiple-custom-value-streams) into Value Stream Analytics. Now, you can delete any custom value streams created in your groups.

[Geo replicates external merge request diffs and Terraform state files](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only): Geo-replication, Disaster Recovery

> Geo now supports replicating [external merge request > diffs](https://docs.gitlab.com/ee/administration/merge_request_diffs.html#using-external-storage) and > [Terraform state files](https://docs.gitlab.com/ee/administration/terraform_state.html) > to secondary nodes, allowing distributed teams to access them from the > closest Geo node, which reduces latency and improves the overall user > experience. Additionally, this data can also be restored from a > secondary node when failing over to that node. > > We currently [don't support > verification](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#limitations-on-replicationverification) > of these assets but future support is planned.

[Experimental Geo support for PostgreSQL high-availability](https://docs.gitlab.com/ee/administration/geo/setup/database.html#patroni-support) (self-managed only): Disaster Recovery

> [Patroni](https://github.com/zalando/patroni) is a solution for > PostgreSQL high-availability which is available in GitLab as an > experimental alternative to [repmgr](https://repmgr.org/). One of the > limitations of using repmgr with GitLab is that it does not allow the > configuration of a high-availability PostgreSQL standby cluster on a Geo > secondary. This configuration is important when a secondary is used as > part of a disaster recovery strategy because it allows systems > administrators to mirror the number of database nodes on the primary and > secondary. This means that after a failover no additional database nodes > need to be provisioned to regain high-availability. > > Geo now provides experimental support for high-availability PostgreSQL > configurations using [Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#patroni). > Due to its experimental nature, Geo's Patroni support is subject to > change without notice and not recommended yet for production use.

[Merge request analytics filter controls](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html): Code Analytics

> In GitLab 13.3, we introduced [merge request analytics](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#merge-request-analytics), which helped you to more effectively evaluate the efficiency and productivity of your merge request throughput. > > GitLab 13.5 introduces filter controls to merge request analytics. This helps you refine the scope of your data within merge request analytics based on filter criteria such as assignee, author, labels, milestone, or branch.

[Support Group Milestones to be associated with Project Releases in API](https://docs.gitlab.com/ee/api/releases/#group-milestones): Release Orchestration

> If you're a release manager working across multiple projects in GitLab, you often use Group Milestones to collect related items for a scheduled a release. You may have realized that GitLab Releases can be associated with a Project Milestone, but now you can associate a Group Milestone with a Project Release via the Releases API. As a release manager, this helps you and your teams work more efficiently when coordinating releases with milestones.

[Provide minimal access to a top-level group](https://docs.gitlab.com/ee/user/permissions.html#users-with-minimal-access-premium): Authentication and Authorization

> To help organizations using SAML SSO with finer grained access control, group owners can assign users a minimal access role. Users with minimal access can list the group in the UI and through the API. However, they cannot see details such as resources, projects or subgroups. This role can be set as the default role at provisioning time for SSO/SCIM or assigned to an existing user in a top level group.

[Install the GitLab Agent for Kubernetes with Omnibus GitLab](https://docs.gitlab.com/ee/user/clusters/agent/) (self-managed only): Kubernetes Management

> Last month we introduced the [GitLab Agent for Kubernetes](/releases/2020/09/22/gitlab-13-4-released/#introducing-the-gitlab-kubernetes-agent) for self-managed GitLab instances installed with Helm. > > This release adds support for the [official Linux package](/install/). In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster. You can learn more about [how the Kubernetes Agent works now](https://docs.gitlab.com/ee/user/clusters/agent/) and [check out our vision](/direction/configure/kubernetes_management/) to see what's in store.

##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)

[Synchronize iterations across subgroups & projects](https://docs.gitlab.com/ee/user/group/iterations/#view-an-iteration-report): Issue Tracking

> Iterations are currently created at the group level and there is no way to view an iteration's report within the context of a subgroup or project. This is problematic for organizations that operate according to the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). It also makes it difficult and confusing for a larger organization to use the same iteration cadence, while also providing a way for each group and project to track their progress. > > To solve this, iterations are now inherited down a group's hierarchy, providing each subgroup and project the ability to view an iteration report scoped to the context in which it's being viewed. > > This change also allows organizations to have more flexibility and control over how they want to use iterations. You can configure iterations from the top-level group to align all groups and projects on the same schedule, or each subgroup can manage its own iteration cadence independently.

##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)

[Branch access control overrides Code Owners requirements](https://docs.gitlab.com/ee/user/project/codeowners/#approvals-by-code-owners): Source Code Management, Code Review

> Merge request approvals restrict how code is pushed to protected branches. It's helpful for promoting code quality and implementing compliance controls. It's useful to require Code Owner approval for specific branches, to prevent direct changes to files without a Code Owner’s approval. However, it lacks flexibility for use cases like automatically updating tags, versions, or deployment trackers on your default branch. > > Now, if a user or group is designated as "allowed to push" in branch protection settings, they can push directly to a protected branch that is configured for Code Owner approval. Because branch protection settings are the main access control mechanism for GitLab projects, this setting now takes precedence over Code Owners settings.

[Group wikis](https://docs.gitlab.com/ee/user/group/index.html#group-wikis): Wiki

> For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience. > > In Gitlab 13.5, we are so excited to bring you group wikis! With [680 upvotes](https://gitlab.com/gitlab-org/gitlab/-/issues/13195) this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can't wait to get it in your hands and hear your feedback. > > Group-level wikis open up tons of possibilities to keep your information at a higher level and accessible to a broader set of people. A few examples of what you can put in your group wikis include team-specific information, coding style guides, and designs for your brand or your company. > > We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a [dedicated issue for your feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/267593).

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[Service Level Agreement countdown timer for incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#service-level-agreement-countdown-timer): Incident Management

> Service level agreements (SLA) are important to keep for customers. SLA breaches can cost you revenue, and decrease customer satisfaction and confidence, but it's challenging to monitor SLA for multiple active incidents. The SLA countdown timer allows you to configure the length of your specific SLAs, and display SLA countdowns on Incidents to help ensure you meet your SLAs and keep your customers happy.

[Timeline view for discussions on incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html): Incident Management

> GitLab comments and threads are a great way to collaborate on incidents, but how can you understand everything that happened in a chronological order from threaded discussions? > > You can now view discussions as a comment timeline to help your team understand the sequence of events during a fire-fight, and hold an effective post-incident review.

#### Core  

Bug fixes

> Some of the notable bug fixes in GitLab 13.5 are: > > - [NuGet packages with extended versions fail to upload](https://gitlab.com/gitlab-org/gitlab/-/issues/217157) > - [Container Registry cleanup policy policy doesn't remove images](https://gitlab.com/gitlab-org/gitlab/-/issues/219915) > - [Reporter level not enough for browsing package lists](https://gitlab.com/gitlab-org/gitlab/-/issues/249101) > - [Group-level deploy tokens fail on Maven group endpoint](https://gitlab.com/gitlab-org/gitlab/-/issues/235822) > - [`Go get` fails with a 500 error for deep nested projects](https://gitlab.com/gitlab-org/gitlab/-/issues/220561#note_426372220) > - [Can't install Python packages when the package name contains a period](https://gitlab.com/gitlab-org/gitlab/-/issues/241678) > - [Auto Deploy encounters an error when Legacy PostgreSQL instance exists](https://gitlab.com/gitlab-org/gitlab/-/issues/262015) > - ["Preview changes" on New/Edit Release and New Snippet page doesn't work](https://gitlab.com/gitlab-org/gitlab/-/issues/241777) > - [Latest docker tag was not updated after latest release v0.4.0](https://gitlab.com/gitlab-org/release-cli/-/issues/58) > - [Various UI fixes to Threat Monitoring Policy Editor](https://gitlab.com/gitlab-org/gitlab/-/issues/247958) > - ["Hide dismissed" toggle doesn't work in Pipeline Security Dashboards ](https://gitlab.com/gitlab-org/gitlab/-/issues/213039) > - [Create issue from vulnerability generates empty issue](https://gitlab.com/gitlab-org/gitlab/-/issues/243394) > - [SAST spotbugs setting SAST_JAVA_VERSION: 11 does not work](https://gitlab.com/gitlab-org/gitlab/-/issues/258815) > - [SAST eslint with custom CA fails to write gitconfig](https://gitlab.com/gitlab-org/gitlab/-/issues/254939) > - [Allow use of Project Access Tokens with Git](https://gitlab.com/gitlab-org/gitlab/-/issues/219551) > - [Allow use of Project Access Tokens for instances that require Terms of Service acceptance](https://gitlab.com/gitlab-org/gitlab/-/issues/225222) > - [Delete Project Access Token users after Tokens are deleted](https://gitlab.com/gitlab-org/gitlab/-/issues/244545) > - [Epic filter doesn't work with start date or due date sorting](https://gitlab.com/gitlab-org/gitlab/-/issues/230827) > - [Issue Search by "Epic !=" doesn't work](https://gitlab.com/gitlab-org/gitlab/-/issues/222597) > - [Search returns unsorted results for eager loaded scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/255947) > - [Code search does not identify the correct blob of code in the search result](https://gitlab.com/gitlab-org/gitlab/-/issues/239386) > - [Code link in the search result should use default branch name instead of commit hash](https://gitlab.com/gitlab-org/gitlab/-/issues/254932) > - [Geo: Fix project/design/wiki repo unable to resync after storage move](https://gitlab.com/gitlab-org/gitlab/-/issues/260337) > - [Geo: Fix wikis/designs with no repository on primary trying to sync over and over](https://gitlab.com/gitlab-org/gitlab/-/issues/258658) > - [Geo: Fix package files view not working by default](https://gitlab.com/gitlab-org/gitlab/-/issues/255280)

[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only): Cloud Native Installation

> - [Documentation](https://docs.gitlab.com/charts/charts/gitlab/task-runner/index.html) has been added for the Task Runner chart. Task Runner is used for administrative tasks such as rake tasks and backups. The new documentation explains the settings that can be configured for Task Runner and provides usage examples. > - The [CNCF Stable Helm chart repository is being deprecated on November 13th](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/). In preparation for this, the Grafana chart is now pulled from [Grafana Community Kubernetes Helm Charts](https://grafana.github.io/helm-charts).

[Get started quickly with GitLab and Terraform](https://docs.gitlab.com/ee/user/infrastructure/): Infrastructure as Code

> A new GitLab CI/CD template enables you to set up Terraform pipelines without any manual work, lowering the barrier to entry for your teams to adopt Terraform.

[Customizable namespaces for GitLab Managed Clusters](https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html): Kubernetes Management

> Users of GitLab Managed Clusters can now choose to use a single namespace per project, or a single namespace per environment, when creating clusters. While single namespaces per project simplified finding review apps, separate namespaces per environment can provide additional security.

[Auto DevOps code intelligence for Go projects](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-code-intelligence): Auto DevOps

> GitLab's built-in [code intelligence](https://docs.gitlab.com/ee/user/project/code_intelligence.html) is a great way to easily add code navigation features to your project, improving your code review workflow with useful features such as type signatures, symbol documentation, and go-to definition. > > As part of GitLab 13.5, automatic setup and configuration of code intelligence for Go projects has been added to Auto DevOps. Once you run a new pipeline you will be able to take advantage of GitLab code intelligence. As more languages become available as part of the [LSIF standard](https://lsif.dev/), we plan to update Auto DevOps to support them. You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org/-/epics/4212) for future updates.

[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only): Omnibus Package

> - Additional functionality has been added for Patroni, the new solution for PostgreSQL replication and failover in Omnibus. The [new `restart` and `reload` sub commands](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#interacting-with-patroni-cluster) let you restart Patroni or reload the Patroni configuration on the leader database node without triggering an automatic failover. The [`revert-pg-upgrade` command is now supported](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#upgrading-postgresql-major-version-in-a-patroni-cluster) for reverting a PostgreSQL upgrade of a cluster managed by Patroni. Finally, use of the `pg-upgrade` command on a Patroni cluster has been validated. > - SSL certificates can now be used for client authentication to the PostgreSQL database as an alternative to using passwords. You will need your own SSL certificate management solution to make use of this feature. For more details, see the [Database Settings](https://docs.gitlab.com/omnibus/settings/database.html#configure-ssl-client-authentication). > - GitLab 13.5 includes [Mattermost 5.27](https://mattermost.com/blog/mattermost-release-v5-27/), an [open source Slack alternative](https://mattermost.com/). The newest release includes Mattermost Omnibus (Beta) for easy installation and maintenance of Mattermost, and [security updates](https://mattermost.com/security-updates/). Upgrading from earlier versions is recommended.

Performance improvements

> In every release, we continue to make great strides improving GitLab's performance. We're committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users! > > In GitLab 13.5, our performance improvement efforts focused on [Cache dataOffset and symlink when requesting zip files](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/474)

[PostgreSQL 12 availability](https://docs.gitlab.com/omnibus/update/gitlab_13_changes.html#postgresql-123-support) (self-managed only): Omnibus Package, Cloud Native Installation

> In GitLab 13.3, [initial compatibility with PostgreSQL 12 was launched](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#postgresql-12-is-now-available), and it became available as an opt-in version in self-managed GitLab. > > With GitLab 13.5, PostgreSQL 12 is now fully supported, including on deployments with Geo and PostgreSQL clusters. To use PostgreSQL 12 in a cluster, you **must** use Patroni for replication and failover. Using repmgr for replication and failover is not supported with PostgreSQL 12. For information on migrating from repmgr to Patroni, see [Switching from repmgr to Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#switching-from-repmgr-to-patroni). For instructions on upgrading PostgreSQL in a Patroni cluster, see [Upgrading PostgreSQL major version in a Patroni cluster](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#upgrading-postgresql-major-version-in-a-patroni-cluster). Note that major PostgreSQL version upgrades in a Patroni cluster require downtime. > > PostgreSQL 12 will [become the default version for new GitLab installations in 13.6](https://gitlab.com/groups/gitlab-org/-/epics/3835). For upgrades of existing GitLab deployments it will become the default version in 13.7 with the option to opt out and stay on PostgreSQL 11.

[Allow for easier roll back from alerts page](https://docs.gitlab.com/ee/operations/incident_management/integrations.html): Continuous Delivery

> When you receive an alert triggered from a deployment, it's hard to immediately understand what happened because the alert is missing additional context. > > In this milestone, you can now click a direct link to quickly navigate to your related environment and get the context you need. This makes it much simpler to understand which environment needs attention. From the environment page, you can also easily view related deployments and rollback to a previous deployment if needed.

[Incremental rollout via AutoDevOps is compatible with Kubernetes 1.16](https://docs.gitlab.com/ee/topics/autodevops/): Continuous Delivery, Auto DevOps

> Clusters in GKE were automatically upgraded to Kubernetes v1.16 on October 6th, 2020. We > updated [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) to support this version > for incremental rollouts to continue working as expected. This upgrade affects users who > continuously deploy to production using timed incremental rollout, and those who automatically > deploy to staging but manually deploy to production.

[Create release with image digest on new tag](https://docs.gitlab.com/ee/ci/cloud_deployment/): Continuous Delivery

> Docker supports immutable image identifiers and we have adopted this best practice to update our cloud-deploy images. When a new image is tagged, we also programmatically retrieve the image digest upon its build, and create a release note to effectively communicate this digest to users. This guarantees that every instance of the service runs exactly the same code. You can roll back to an earlier version of the image, even if that version wasn't tagged (or is no longer tagged). This can even prevent race conditions if a new image is pushed while a deploy is in progress.

[Upgrade Auto DevOps to Helm 3](https://docs.gitlab.com/charts/installation/): Continuous Delivery, Auto DevOps, Kubernetes Management

> Auto DevOps aims to bring outstanding ease of use and security best practices to its users, out of the box. Until now, Auto DevOps in Kubernetes environments required Helm v2 to be installed on the cluster. This presented a security risk given Tiller's root access rights. With the introduction of Helm v3, Tiller is no longer a requirement. > > The current GitLab version finally supports Helm v3 so you can rest assured you're getting the latest and great functionality and security updates. In the case of a GitLab Managed Cluster, you can upgrade your Helm installation by following our documentation. Note that Helm 2 support is expected to end around November 2020.

[Enable gitlab-pages daemon to send precompressed br files](https://docs.gitlab.com/ee/user/project/pages/introduction.html#serving-compressed-assets): Pages

> If you are looking for ways to improve your GitLab Pages load times, we are excited to announce a great community contribution from [feistel](https://gitlab.com/feistel) and [Ambyjkl](https://gitlab.com/Ambyjkl) that adds support for Brotli compressed files. This helps lower the required bandwidth per page, improving your site load times.

[Required approval for new user registration](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#require-admin-approval-for-new-sign-ups) (self-managed only): Authentication and Authorization

> To reduce the operational burden on GitLab administrators without compromising security, GitLab 13.5 introduces a new instance-level option to require administrator approval for any new user accounts. This option is disabled by default but when enabled, will require manual approval by instance administrators before users that completed the sign-up process can access the instance.

[View cluster cost management data in GitLab](https://docs.gitlab.com/ee/user/clusters/cost_management.html): Cluster Cost Optimization

> Many users created their own scripts to better understand their cluster costs. However, now you can see an overview of your cluster costs and resource usage in the GitLab user interface. Our integration builds on Kubecost's `cost-model` and gives you flexible insights into various levels of your clusters. Use the provided cost template to see your monthly node costs and the costs of your GitLab Managed Apps, or build more elaborate custom dashboards with the nine metrics provided by Kubecost and the Prometheus query features of GitLab.

[Generic Package Registry](https://docs.gitlab.com/ee/user/packages/generic_packages/): Release Orchestration, Package Registry

> GitLab supports a wide variety of languages in our [Package Registry](https://docs.gitlab.com/ee/user/packages/) offering. However, you may want to store other binary types in GitLab that are not yet supported. > > In GitLab 13.5, you now have the ability to add raw package feeds (like you could do in Nexus) to a Generic Package Registry. Looking forward, this feature helps create the foundation for [Release Assets](https://gitlab.com/groups/gitlab-org/-/epics/2207) and allows you to [attach binary assets](#attach-binary-assets-to-releases) making it easier for you to package and release your software with GitLab.

[Attach binary assets to Releases](https://docs.gitlab.com/ee/user/project/releases/index.html#release-assets-as-generic-packages): Release Orchestration

> If you aren't currently using GitLab for your releases because you can't attach binaries to releases, your workflow just got a lot simpler. > > You now have the ability to attach binaries to a release tag from the `gitlab.ci-yml`. This extends support of Release Assets to include binaries, rather than just asset links or source code. This makes it even easier for your development teams to adopt GitLab and use it to automate your release process.

[Feature Flags flexible rollout strategy](https://docs.gitlab.com/ee/operations/feature_flags.html#percent-rollout): Feature Flags

> When you use the `percent rollout` strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. > > We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.

[Feature Flags made available in all tiers](https://docs.gitlab.com/ee/operations/feature_flags.html): Feature Flags

> In GitLab 11.4, we [introduced](https://about.gitlab.com/releases/2018/10/22/gitlab-11-4-released/#create-and-toggle-feature-flags-for-your-applications-alpha) Feature Flags. In GitLab 12.2, we introduced [percent rollout](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/#percent-rollout-strategy-for-feature-flags) and [user ID](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/#user-id-rollout-strategy-for-feature-flags) Feature Flag strategies. In GitLab 13.1, we introduced Feature Flag [user lists](https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#control-feature-flags-with-user-lists) and support for [multiple Feature Flag strategies](https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#set-feature-flag-strategy-across-environments) per environment. > > Earlier this year, we committed to [moving 18 features](/blog/2020/03/30/new-features-to-core/) to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release. > > Now we've officially finished moving Feature Flags to our Core offering. We're excited about making these features available to more of the GitLab community and seeing the positive impact it'll have on your development workflow.

[Template for Deploying to AWS EC2](https://docs.gitlab.com/ee/ci/cloud_deployment/#provision-and-deploy-to-your-aws-elastic-compute-cloud-ec2): Continuous Delivery

> To help you deploy to AWS Elastic Cloud Compute (EC2) more efficiently, we created a template that shows you how to get started. This template allows you to provision your own infrastructure by first leveraging the [AWS CloudFormation](https://aws.amazon.com/cloudformation/) API. You then 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. > > Users can include the template in their configuration, specify a few variables, and their application will be deployed and ready to go in no time.

##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)

[Automatically add To Do and Doing lists on new boards](https://docs.gitlab.com/ee/user/project/issue_board.html#first-time-using-an-issue-board): Issue Tracking

> In most cases, teams will be best served by keeping their workflows as simple as possible. To encourage this and make the first experience with a board more efficient and approachable, creating a new board will now automatically pre-populate To Do and Doing lists so you can get straight to managing issues.

[Remove issue labels with a single click](https://docs.gitlab.com/ee/user/project/labels.html#assign-and-unassign-labels): Issue Tracking

> Removing a label from an issue used to require three clicks, fetching a fresh list of labels from the server, and using a search box to find the label you want to remove. This was unintuitive and inefficient, given that GitLab users remove labels from issues approximately 55,000 times per day. > It may not be [revolutionary](https://about.gitlab.com/handbook/values/#boring-solutions), but you can now remove an issue's label with a single click.

##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)

[Deep-level wiki navigation](https://docs.gitlab.com/ee/user/project/wiki/#viewing-a-list-of-all-created-wiki-pages): Wiki

> In GitLab 13.5, along with the release of group wikis, we have another huge improvement in how to view and navigate the file structure of a wiki. > > Currently, it's very difficult to see where you are or understand the structure of a wiki if you have multiple folder levels. This makes it difficult to navigate, find pages, and mentally map your information. > > With this release, we've introduced wiki deep nesting in the sidebar so you can see all of your pages and navigate accordingly.

[Mark merge request as 'draft' with a single click](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html#mark-merge-requests-as-drafts): Code Review

> Creating a merge request is a great way to share your contribution with others and get the conversation started, even if the code is not ready to be merged. In order to signal to others that a contribution is not ready to be reviewed or merged, you can prefix the merge request title with `draft` (formerly known as `wip`). This is useful, however it entails going into edit mode, navigating to the merge request title, and typing the required prefix. > > To make it faster to use this feature, we have introduced **Mark as draft** and **Mark as ready** buttons directly to the top-right corner of merge request pages (without having to edit its description to change it). With a single click, you can indicate that your work is in progress and not ready to be merged, and vice-versa.

[Embed a YouTube video in the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/index.html#videos): Static Site Editor

> GitLab 13.5 includes a new formatting option in the WYSIWYG mode of the Static Site Editor making it easier for you to embed a YouTube video with just a few clicks. After entering either the full embed URL or the YouTube video ID into the modal window, the Static Site Editor inserts the correct block of HTML at your cursor and displays a thumbnail of your video in the editor. > > You no longer have to copy and paste the properly-formated HTML in order to embed a video in a Markdown file and you can edit your document in confidence knowing the video you included is correct. We've optimized this for YouTube video embeds but we'll be working to add support for other services like Vimeo and self-hosted HTML5 videos in future releases.

[Edit merge request description from the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/index.html#edit-content): Static Site Editor

> Engineering best practices encourage you to include a concise title and description along with any changes you make to a file. The context provided is valuable during the review process and for documenting the justification or motivation for the change. > > The Static Site Editor abstracts as much of the Git workflow away from the editor as possible. One way it does this is by using a default branch name, merge request title, and description. This makes for a simple, one-click submission but the resulting merge request lacks that critical context. > > In GitLab 13.5, you can now include an optional—though strongly encouraged—title and description with your changes that will populate a more descriptive and useful merge request.

[Launch Gitpod Workspaces directly from GitLab](https://docs.gitlab.com/ee/integration/gitpod.html): Web IDE, Live Preview

> Engineers have complicated development environments that can take time to set up and make testing changes or exploring new projects challenging. Often getting started with a project involves following documentation, installing dependencies, and hoping there are no conflicts with other services running. This process can be time consuming, error prone, and may not replicate the configuration accurately to test and contribute to a project. > > With Gitpod integrated into GitLab, you can easily launch your Gitpod Workspace directly from the GitLab interface. When editing a project on GitLab, a new dropdown option exists to open that project in GitPod: > >  > > Gitpod allows you to define your [project's configuration](https://www.gitpod.io/docs/configuration/) in code so you can launch a prebuilt development environment with one click. These environments are configured through a `.gitpod.yml` file inside of the project and include options for Docker configuration, start tasks, editor extensions and more. This flexible configuration, which is part of the project's code, allows developers to get started working on a project quickly. > Try this today with the [GitLab project](https://gitpod.io/#https://gitlab.com/gitlab-org/gitlab/-/tree/master/) which is already setup to work with Gitpod. > > Thanks to [Cornelius Ludmann](https://gitlab.com/corneliusludmann) from [Gitpod](https://www.gitpod.io/) for contributing this!

[Snippets with multiple files](https://docs.gitlab.com/ee/user/snippets.html#multiple-files-by-snippet): Snippets

> Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented. > > In GitLab 13.0, we laid a foundation for Snippets by giving them [version control](/releases/2020/05/22/gitlab-13-0-released/#versioned-snippets) support based on a Git repository. Version control and the history it provides are an important piece of context when looking at code and understanding its purpose, but it may not be everything. > > GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities. For example: > > - A snippet that includes a script and its output. > - A snippet that includes HTML, CSS, and JS code, from which the result can be easily previewed. > - A snippet with a `docker-compose.yml` file and its associated `.env` file. > - A `gulpfile.js` file coupled with a `package.json` file, which together are used to bootstrap the project and manage its dependencies. > > Providing all of these files in a single Snippet gives more options for the types of content that can be shared and the context that is provided when looking at them. We're excited to see the types of content you will create and share using Snippets with multiple files!

##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)

[Optional caching for failed pipelines](https://docs.gitlab.com/ee/ci/yaml/#cachewhen): Continuous Integration (CI)

> When your pipeline fetches a lot of external dependencies (such as NPM), not having the option to cache dependencies on a failed pipeline means throwing away valuable cache that is otherwise unchanged by your code. Now you have the option to save the cache regardless of the job status, which can save time and resources when iterating on a failing pipeline. > > Caching only when the job/pipeline succeeds is still the default. This prevents an uncleared cache of incomplete dependencies from causing subsequent pipelines to fail. But now you can decide when it's safe to enable caching always, to support incremental builds and help speed up the process of getting to your first green pipeline.

[Track PipelineArtifact Storage on Usage page](https://docs.gitlab.com/ee/ci/pipelines/pipeline_artifacts.html#storage): Continuous Integration (CI)

> Following the initial release of PipelineArtifacts, there was a type of artifact that used storage but wasn't tracked on your [Storage Usage Quota page](https://docs.gitlab.com/ee/user/group/#storage-usage-quota). This meant that you didn't have an accurate representation of how much free storage was actually available. > > Now both Job and PipelineArtifacts are represented by the Artifacts label so you know exactly how much space Artifacts are taking of your Storage.

[GitLab Runner 13.5](https://docs.gitlab.com/runner): GitLab Runner

> We’re also releasing GitLab Runner 13.5 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 set kubernetes local ephemeral storage requests and limits](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6184) > - [Provide a Docker image to auto-install GitLab Runner on a Google Compute virtual machine](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25402) > - [Introduce variable to indicate current build status](https://gitlab.com/gitlab-org/gitlab/-/issues/16579) > - [Add labels to Docker cache volumes created by GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26505) > - [Runner on Windows using `bash` as a shell passes paths with backslash `\` instead of forward slash `/`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4524) > > #### Bug Fixes: > > - Fix: [Repository for Debian ships 32-bit ARM binaries for arm64](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27069) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-5-stable/CHANGELOG.md).

[Limit the number of unit tests parsed per report](https://docs.gitlab.com/ee/user/gitlab_com/#gitlab-cicd): Code Testing and Coverage

> There is now a limit to the number of tests that can be parsed from JUnit report-formatted files that are uploaded in one build for use in the Test Summary and Unit Test reports. For GitLab.com the maximum number of tests that can be parsed is 500,000 for all JUnit report formatted-files in a build.

[Validate expanded GitLab CI/CD configuration with the API](https://docs.gitlab.com/ee/api/lint.html#yaml-expansion): Pipeline Authoring

> Writing and debugging complex pipelines is not a trivial task. You can use the [`include`](https://docs.gitlab.com/ee/ci/yaml/#include) keyword to help reduce the length of your pipeline configuration files. However, if you wanted to validate your entire pipeline via the API previously, you had to validate each included configuration file separately which was complicated and time consuming. > > Now you have the ability to validate a fully-expanded version of your pipeline configuration through the API, with all the `include` configuration included. Debugging large configurations is now easier and more efficient.

[Allow one dimensional parallel matrices](https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs): Pipeline Authoring

> Previously, the `parallel: matrix` keyword, which runs a matrix of jobs in parallel, only accepted two-dimensional matrix arrays. This was limiting if you wanted to specify your own array of values for certain jobs. > > In this release, you now have more flexibility to run your jobs the way that works best for your development workflow. You can run a parallel matrix of jobs in a one-dimensional array, making your pipeline configuration much simpler. Thanks [Turo Soisenniemi](https://gitlab.com/Turmio) for your amazing contribution! > > Here's a basic example of this in practice that will run 3 test jobs for different versions of Node.js, but you can apply this approach to your specific use cases and easily add or remove jobs in your pipeline as well: > > 

[Pre-collapse sections in the job logs](https://docs.gitlab.com/ee/ci/pipelines/#pre-collapse-sections): Continuous Integration (CI)

> Job logs often contain very long sections that make it difficult to parse when you are scanning the logs to find a specific piece of information. > > Now you can set job log sections to be collapsed by default. To make parsing much easier, simply add `[collapsed=true]` to your job scripts in your CI/CD configuration file as needed.

[Enable instance-level shared runners when viewing groups](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#disable-shared-runners): GitLab Runner

> GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI/CD pipeline jobs. These runners, visible in the GitLab.com UI as "shared runners," are enabled by default and can be disabled for each project. However, some organizations require their CI/CD jobs to run only on self-managed runners, and so disabling the use of instance-level shared runners on each project resulted in unnecessary administrative overhead. > > Now administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.

[Trigger downstream or child pipelines with manual jobs](https://docs.gitlab.com/ee/ci/yaml/#trigger): Pipeline Authoring

> Previously, it was not possible to configure a trigger job to wait on a manual action. This made it challenging to configure either downstream or child pipeline triggers to wait for a user to click on them before running. > > In this release, we've added the ability to add `when: manual` to trigger jobs. Use this keyword to make trigger jobs wait until you click on the play button. This gives you more control of your downstream and child pipelines, and they will only run when you want them to.

##### [Package](https://about.gitlab.com/stages-devops-lifecycle/package/)

[Major improvements to the Container Registry cleanup policy](https://docs.gitlab.com/ee/user/packages/container_registry/#cleanup-policy): Container Registry

> When using the cleanup policy for tags to remove unwanted tags from your Container Registry, you may have noticed that the tags aren't always removed like you'd expect them to be. As a result, it's likely that you had to manually intervene by using the GitLab API to [delete registry tags in bulk](https://docs.gitlab.com/ee/api/container_registry.html#delete-registry-repository-tags-in-bulk), or you ignored the problem and subsequently experienced higher storage costs. > > There are two potential issues that may have caused problems. The first issue is related to [gitlab-#219915](https://gitlab.com/gitlab-org/gitlab/-/issues/219915). This issue resolved a bug where some policies created in the user interface were failing, because the `user` wasn't passed to the [`DeleteTagService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/projects/container_repository/cleanup_tags_service.rb#L28). > > In addition, you may have encountered an issue in which the policy ran, but only partially completed. This occurs when a policy attempts to delete many images and instead times out. If that happens, it will continue removing the tags in the policy's next scheduled run. Moving forward, you will see a warning to signal that there are partially-run policies remaining. That way you can decide if you want to manually intervene or not. > > We have several other improvements planned for this feature, including [support for all historical projects](https://gitlab.com/gitlab-org/gitlab/-/issues/196124) and a [preview of tags that will be removed](https://gitlab.com/gitlab-org/gitlab/-/issues/223732).

[More Conan recipe information on the Package Registry page](https://docs.gitlab.com/ee/user/packages/conan_repository/): Package Registry

> You can use the GitLab Conan Repository to publish and share C and C++ dependencies. But, when using the Package Registry user interface to find or verify a dependency, it was difficult to differentiate between different versions of a dependency. The user interface presented the name and version, but did not include `conan_user` or `conan_channel`. Both of these are often used to differentiate between different packages. For example, the below recipe would have been displayed in the UI as `Hello version 1.0`. > > - Hello/1.0@trizzi/stable > - Hello/1.0@trizzi/beta > - Hello/1.0@other_user/stable > > Now the entire recipe is displayed in the user interface, making it easier to find and verify the package you are looking for.

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[Improved SAST severity data for C/C++ and NodeJS vulnerabilities](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#analyzers-data): SAST

> 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 analyzers for NodeJS (nodejsscan) and C/C++ (flawfinder) 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.

[Improved merge request experience for security scans](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) (self-managed only): SAST, Secret Detection

> With [SAST and Secret Detection now available to all users](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#sast-security-analyzers-available-for-all), we have improved the experience for all GitLab users [interacting with Secure scan results](https://docs.gitlab.com/ee/user/application_security/#interacting-with-the-vulnerabilities) in a merge request, making it easier for anyone to access [Secure scanning findings](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools). Security scan results previously were only accessible on the [Pipeline Overview page](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts) and users had to know where to look to find them. > > Now all merge requests will show if there have been security scans run and help users find the job artifacts. We plan to [continue improving this experience](https://gitlab.com/groups/gitlab-org/-/epics/4388) over the next few releases. This change does not [modify the MR experience for Ultimate users](https://docs.gitlab.com/ee/user/application_security/sast/#summary-of-features-per-tier).

[Update nodejs-scan SAST analyzer to use njsscan v0.1.5](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> We have updated our Node.js SAST analyzer which adds 100+ new detection rules. This version also changes the detection rules to be powered by [v0.1.5](https://pypi.org/project/njsscan/0.1.5/) of [njsscan](https://github.com/ajinabraham/njsscan) and [semgrep](https://github.com/returntocorp/semgrep) which is now supported in our new [SAST Custom Rulesets](https://docs.gitlab.com/ee/user/application_security/sast/#custom-rulesets).

[SAST support for iOS and Android mobile apps](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> [GitLab SAST](https://docs.gitlab.com/ee/user/application_security/sast/) now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the [Mobile Security Framework (MobSF)](https://github.com/MobSF/Mobile-Security-Framework-MobSF). Initially this analyzer supports source code analysis but we [intend to expand support for binary scanning](https://gitlab.com/gitlab-org/gitlab/-/issues/269915) of `.ipa` and `.apk` files in the near future. > > This feature was a generous contribution by the [H-E-B Digital](https://digital.heb.com/) team. You can [read more about integrating with GitLab Secure](https://about.gitlab.com/blog/2020/10/22/integrating-with-gitlab-secure/) and view our [Secure scanning integration documentation](https://docs.gitlab.com/ee/development/integrations/secure.html).

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[View alert integrations list](https://docs.gitlab.com/ee/operations/incident_management/alert_integrations.html#integrations-list): Incident Management

> Operations teams manage many alerting tools integrated into their central incident management platform. Managing and maintaining these tools and integrations is complex and confusing when configuration interfaces, auth keys, and important URLs are located in different places. > > Your GitLab project's now provides your teams a single list at **Settings > Operations > Alerts** for viewing and modifying alerting configurations.