GitLab.org/GitLab: Release v13.10.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.10
Released: 2021-03-22
License: MIT
Release Assets:
##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)
[View your snippets at snippets.gitlab.com](https://docs.gitlab.com/ee/user/snippets.html#discover-snippets) (SaaS only):
> Now you can visit [snippets.gitlab.com](http://snippets.gitlab.com/) to access your snippets dashboard. This easy-to-remember URL is the quickest way to view all the snippets you've created and discover other public snippets.
Snippets[Deep link directly to lines of code](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#highlight-lines) (SaaS only):
> Collaborating on long files is easier when you can share a link to a specific line of code. Previously, you could only link to a line number when viewing a file in the repository, but now you can also link to specific lines of code in the context of editing a file.
>
> To get a link to a specific line, click the icon in the gutter next to the line number, or append `#L` followed by the line number to the edit URL. The link will open the editor, scroll to the line, and highlight it for you. Try it out in the single-file editor, the Web IDE, and the Pipeline Editor!
>
> Tip: you can even create a link to multiple lines by appending a range to the link, like `#L87-98`, even though the UI doesn't support creating these (yet).
Web IDE, Pipeline Authoring[DORA4-based lead time for changes](https://docs.gitlab.com/ee/api/dora/metrics.html#get-project-level-dora-metrics):
> Measuring the efficiency of your software development lifecycle is an important step to grow DevOps adoption for any organization. In the previous milestone, we added support for [DORA4-based Deployment Frequency](https://docs.gitlab.com/ee/api/dora4_project_analytics.html). In this release, we are excited to announce the support of a new API for lead time for changes (via merge requests) on the project level. The lead time for changes gives you an indication of how long it takes for code to be committed and deployed to your production environment. Understanding and tracking this data is a great starting point in your journey to continuous improvement in your DevOps process.
Continuous Delivery, Release Orchestration[Group-level API support for Deployment Frequency](https://docs.gitlab.com/ee/api/dora4_group_analytics.html):
> In [gitlab#279039](https://gitlab.com/gitlab-org/gitlab/-/issues/279039), we added support for Deployment Frequency at the project level. This release extends support for this API to the group level. This allows users to get a full picture of the Deployment Frequency across projects and teams, so they can assess their efficiency more accurately.
Continuous Delivery[Optional enforcement of SSH key expiration](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#optional-enforcement-of-ssh-key-expiration) (self-managed only):
> SSH keys have had an [optional expiration date](https://gitlab.com/gitlab-org/gitlab/-/issues/36243) since GitLab 12.9, however, there was no way to enforce that date.
>
> Administrators can now enforce SSH key expiration dates on their GitLab instances. Enforcing SSH key expiration will immediately make all expired SSH keys un-usable.
Compliance Management[API fuzz testing graphical configuration screen](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/#configuration-form):
> We know that it can be challenging to get started with API fuzz testing.
> Configuration settings can be difficult to remember and code into your pipeline.
> To make this easier, we are introducing
> a new user interface to simplify your API fuzz test settings!
>
> You can now enter the needed settings in the new API fuzz testing configuration screen rather than directly
> within a pipeline file. Once you are done, the page will give you a snippet you can copy into your `.gitlab-ci.yml` file
> and even start a merge request if you wish. This helps guide you to add the correct configuration to your own pipelines
> so you can get started with API fuzz testing more quickly and more efficiently than before.
Fuzz Testing[API fuzz testing parameter override](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/#overrides):
> When performing API fuzz testing, it's a common problem
> that various fields in the API request will need to be
> updated or added to allow the API request to be successful.
> Such changes are needed to support API authentication,
> environment-specific data, etc.
>
> This release expands on our existing [override support](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/#overrides),
> allowing changes to headers, cookies, query parameters,
> form data, JSON body data, and XML body data. Changes
> can be made using static values provided at runtime or
> dynamically by providing a script that is called to provide
> the values while the scan is running. Dynamic changes
> using a script allow updating authentication tokens
> that expire quickly.
>
> Customizing these attributes both improves the quality
> of the test and ensures it can complete successfully.
Fuzz Testing[API fuzz testing supports OpenAPI v3 files](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/#configuration):
> API fuzz testing now supports OpenAPI v3 specification files. This allows you to directly use
> the OpenAPI specifications your project already has without needing to downgrade them to OpenAPI v2.
> You provide OpenAPI v3 files in the same way you would provide an OpenAPI v2 file, as part of the
> `FUZZAPI_OPENAPI` variable in your `.gitlab-ci.yml` file.
Fuzz Testing[Add icons to the Vulnerability Trends Chart](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#project-security-dashboard):
> In 13.6, we released a new Project Security Dashboard with a vulnerability trends chart. This chart provides a historical view of vulnerability counts by severity over the past 365 days. It provides valuable insights into a Project's security health trends.
>
> We've enhanced the chart to include new interactive elements to make it more effective and efficient to use. You can now zoom in on a selected section of the chart, and zoom out to the default view. You can also export an SVG image of the chart for use in external documents.
Vulnerability Management[Clickable file and line number links on Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#view-vulnerable-source-location):
> Many of GitLab's security scanners output a file and line number where a potential vulnerability is detected. Users can see this information in the form of a clickable link when viewing a vulnerability's details. The link will take the user directly to the file and line number inside the repository for the default branch. This same information is also displayed on the Vulnerability Report. However, the file names were not clickable, requiring that you open a vulnerability's details page to access the link.
>
> This enhancement brings the convenience of linked filenames to the Vulnerability Report. From a Project, Group, or [Security Center](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#security-center) Vulnerability Report, you can go directly to the affected file and line number from any vulnerability reported from a scanner that outputs this information. Because you no longer need to first open each vulnerability record, it is much faster to do things like open multiple referenced lines of code in separate tabs for speedy triage.
Vulnerability Management[Support Java 15 for Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning):
> For customers using Java 15 you will be happy to know that you are now supported by our Dependency Scanning analyzers. Please set the `DS_JAVA_VERSION` environment variable to `15` to leverage this enhancement.
Dependency Scanning[Vulnerability bulk status updates](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#change-status-of-vulnerabilities):
> It is currently possible to select and dismiss multiple vulnerabilities in bulk from a Vulnerability Report. This is helpful in quickly removing redundant occurrences or false positives. However, you must still open up individual vulnerability details to change status to anything other than Dismissed. This is inefficient for doing routine activities such as resolving all vulnerabilities no longer detected by securing scanners.
>
> This bulk actions enhancement addresses this limitation. Selecting one or more vulnerabilities from a Vulnerability Report will now present the option to set any status. You can even move vulnerabilities back to Detected if they need further triage evaluation. Combined with the filtering capabilities, it is easier than ever to isolate and take action on a specific subset of vulnerabilities all at once.
Vulnerability Management[Configure the Kubernetes Agent Server as part of the core GitLab configuration](https://docs.gitlab.com/ee/user/clusters/agent/#install-the-kubernetes-agent-server):
> While GitLab administrators could install the Kubernetes Agent Server along with their GitLab instance, until now they lacked many configuration options. With this release, GitLab administrators can specify the Agent Server's external and internal URLs as well as their operational status (enabled or disabled) in the core GitLab configuration file (`config/gitlab.yaml`). GitLab will use these configuration values for every interaction with the Agent Server.
>
> The Kubernetes Agent Server is also now available on GitLab.com. We are [progressively making this feature available](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) to more projects over time.
Kubernetes Management[Elasticsearch cluster size estimate in Advanced Search](https://docs.gitlab.com/ee/integration/elasticsearch.html#gitlab-advanced-search-rake-tasks):
> If you are planning on enabling Advanced Search, you need to know the estimated size of the index so you can prepare sufficient storage in Elasticsearch. Prior to 13.10, this required a few different steps to determine the total combined size.
>
> To make this readily accessible, we have added a Rake command which aggregates all of the indexed content and multiplies by .5 to give an estimated size that is recommended for Elasticsearch.
Global Search[Geo verifies replicated package files](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#data-types) (self-managed only):
> Geo automatically verifies the data integrity of replicated [Package Registries](https://docs.gitlab.com/ee/user/packages/). This ensures that packages are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.
>
> [Geo's verification capabilities](https://docs.gitlab.com/ee/development/geo/framework.html#verification) are implemented generically in Geo's replication framework and we are planning to bring file verification to [all other replicated data types](https://gitlab.com/groups/gitlab-org/-/epics/5285) e.g. LFS files or attachments.
Disaster Recovery, Geo-replication[Geo supports replicating Group wikis](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only):
> Geo now supports replicating [Group Wikis](https://docs.gitlab.com/ee/user/group/index.html#group-wikis)
> to secondary sites, allowing distributed teams to access them from the
> closest Geo site, which reduces latency and improves the overall user
> experience. Additionally, this data can also be restored from a
> secondary site when failing over to that site.
>
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/323897).
Geo-replication, Disaster Recovery[Geo trusts a secondary site by default](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> A Geo secondary site uses an OAuth application on the primary site to perform authentication. When a new Geo secondary site was set up, the primary site did not trust the secondary site by default. This meant any user would have to confirm separately that the secondary could be trusted when connecting for the first time.
>
> In GitLab 13.10, the primary site trusts a secondary site by default as it is provisioned by GitLab. This eliminates an unneeded and potentially confusing OAuth dialog.
Disaster Recovery, Geo-replication[Horizontal navigation for Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/index.html#creating-a-value-stream-with-stages):
> The vertical value stream stages in the Group-level value stream analytics have been replaced with a horizontal layout to help visualize the flow of work through stages of a value stream. This change creates more space on the page to add additional graphs and metrics in the future.
> In addition, value streams are now much easier to create and edit using a new form that allows the creation of a value stream and all of the stages in one single step. In the form, pre-configured stages can be added, or custom stages created. This is a much improved user experience compared to the previous multi-step process. When editing your value stream, all of the start and end events for each stage are clearly visible in the form, helping you understand how the value stream has been mapped end to end.
Value Stream Management[View epics on a board (MVC)](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html):
> If you work on epics in GitLab, it can be tough to visualize your epics' workflow status. Often, when drafting or writing epics, you might want to use labels (like `Open`, `Doing`, or `Done`) to keep tabs on the next steps when creating your project plan.
>
> In this release, we took our awesome [Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html) feature and optimized it for viewing epics. You can now visualize the workflow status of your epics on an epic board by applying [labels](https://docs.gitlab.com/ee/user/project/labels.html#label-management) or [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) to them.
>
> We are releasing this early version of Epic Boards in 13.10, so we can start [gathering customer feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/324677). We will follow it up with [MVC 2](https://gitlab.com/groups/gitlab-org/-/epics/5069) and [MVC 3](https://gitlab.com/groups/gitlab-org/-/epics/5079), which will achieve parity with Issue Boards.
>
> Read about the current limitations in the [Epic Boards documentation](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html#limitations-of-epic-boards). We are targeting the full release of Epic/Program boards on the [parent epic](https://gitlab.com/groups/gitlab-org/-/epics/2864). Please leave feedback about your experience in the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324677).
Epics[View Jira issue details in GitLab](https://docs.gitlab.com/ee/integration/jira/issues.html#view-a-jira-issue):
> Users of our Jira issue list feature can now view the details of an issue directly inside of GitLab! This MVC enables developers to see the details, labels, and comments on an issue, giving them the ability to stay in GitLab while working on Jira issues.
>
> Our goal is to empower developers to _stay inside of GitLab_ during the majority of their day, and this is now one less trip to Jira you'll have to make.
>
> In GitLab 13.10, this feature is available if you [enable a feature flag](https://docs.gitlab.com/ee/integration/jira/issues.html). This feature will be [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/299832) in GitLab 13.11.
Integrations[API description templates: Issues and Merge Requests](https://docs.gitlab.com/ee/user/project/description_templates.html#set-a-default-template-for-merge-requests-and-issues):
> Setting the default description template for issues and merge requests can be valuable to ensure users provide the right content when creating these items. When you have many projects configuring each of these templates or updating them across all your projects, the process can be manual, error-prone, and time-consuming.
>
> With the new `issues_template` and `merge_requests_template` attributes available for the [projects API](https://docs.gitlab.com/ee/api/projects.html#templates-for-issues-and-merge-requests), you can automate setting and keeping these templates up-to-date for all of your projects.
Code Review[Integrate any IT alerting tool with GitLab](https://docs.gitlab.com/ee/operations/incident_management/integrations.html#http-endpoints):
> Alert integrations are a critical part of your Incident Management workflows. It's difficult to manage integrations between tools, especially when several monitoring tools like Nagios, Solarwinds, etc. alert on your services. These integrations notify you and your team of incidents, so it's critical for them to be easy to set up and maintain.
>
> In this version of GitLab, you can create multiple HTTP endpoints with unique auth tokens for each integrated monitoring tool. When you set up an HTTP endpoint with a unique auth token for each monitoring tool, your team can manage each tool separately without affecting alerts from other tools nor take down all of your alerting by resetting a single auth token!
>
> For each HTTP endpoint you create, you can transform each external alert's unique format in the GitLab user interface, and ensure your alerts display relevant data in the right places. Submit a sample payload for the tool by pasting it into GitLab, map fields from the payload to GitLab alert attributes, and your alerts will present consistent information regardless of their source.
Incident Management[Create a release from an existing tag](https://docs.gitlab.com/ee/user/project/releases/#create-a-release):
> Previously, creating a release was supported only for new tags. In GitLab 13.10, you can now create a release by selecting an existing tag, something that will give you more flexibility when planning releases.
Release Orchestration[Define environment type in .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/environments/#deployment-tier-of-environments):
> In GitLab 13.10, we are introducing a new `.gitlab-ci.yml` environment `type` keyword which will allow you to explicitly define the environment type and name. Supported environment types can be: `production`, `staging`, `testing`, `development`, or `other`. This is a first step towards group level environment management and the ability to create separation of duties for deployments to production environments. This new configuration will also provide users with much more flexibility in the production environment naming convention traditionally used, that is used to determine different metrics in GitLab, such as Dora4 metrics and Value stream Analytics.
Continuous Delivery, Release Orchestration[Notifications settings for 'merge when pipeline succeeds'](https://docs.gitlab.com/ee/user/profile/notifications.html#notifications-on-issues-merge-requests-and-epics):
> Previously, when [Merge when pipeline succeeds (MWPS)](https://docs.gitlab.com/ee/user/project/merge_requests/auto_merge.html) was set to on, all participating users within the merge request got a notification about this event. With GitLab 13.10, you can now choose to unsubscribe from the MWPS notification events with a new custom setting, allowing you to reduce unnecessary noise. Thanks to Ravishankar Gnanaprakasam for a great community contribution!
Continuous DeliveryBug fixes
> Some of the notable bug fixes in 13.10 are:
>
> - [Environments list is missing in Variables environment scope](https://gitlab.com/gitlab-org/gitlab/-/issues/26463).
> - [Milestones page on Gitlab.com throws a 500 error](https://gitlab.com/gitlab-org/gitlab/-/issues/301002)
> - [Update the `maven-metdata.xml`when a package is deleted](https://gitlab.com/gitlab-org/gitlab/-/issues/11424)
> - [Project tab count is incorrect when performing group level search](https://gitlab.com/gitlab-org/gitlab/-/issues/321620)
> - [Issues created on vulnerability are not shown as linked after merging the MR](https://gitlab.com/gitlab-org/gitlab/-/issues/294289)
> - [Vulnerability status dropdown actions should not scroll](https://gitlab.com/gitlab-org/gitlab/-/issues/320838)
> - [Do not render test cases with issues URL](https://gitlab.com/gitlab-org/gitlab/-/issues/300147)
> - [Geo: Package file sync fails to follow redirects for direct download object storage](https://gitlab.com/gitlab-org/gitlab/-/issues/323495)
> - [Geo Framework: Persistent failures block/slow-down retries of transient failures](https://gitlab.com/gitlab-org/gitlab/-/issues/293972)
> - [Geo set-replication-password doesn't work with Patroni](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6000)
> - [Orphaned pool object in DB causes backup restore error](https://gitlab.com/gitlab-org/gitlab/-/issues/221296)
> - [Zero-downtime upgrades step `gitlab-rake db:migrate` fails in 13.9.3 because of `allow_proxy_whitelist` rename](https://gitlab.com/gitlab-org/gitlab/-/issues/324160)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - Support for the GitLab Agent Server (KAS) is [now available](https://docs.gitlab.com/charts/charts/gitlab/kas/).
> - A webservice label can now be applied to [all objects created by the deployment](https://docs.gitlab.com/charts/charts/globals.html#common-labels).
> - It is now possible to set [per-deployment `blackoutSeconds`](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/1867) on the webservice, to customize shutdown on large instances
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - ARM64 packages are [now available](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5018) for Debian 10.
> - GitLab RPM Packages [are now signed with the SHA256 digest](https://gitlab.com/gitlab-org/omnibus/-/merge_requests/17), instead of MD5. This change improves signature strength and allows the packages to be installed on FIPS-enabled systems.
> - GitLab's [official AWS AMIs](https://aws.amazon.com/marketplace/seller-profile?id=9657c703-ca56-4b54-b029-9ded0fadd970) and [Omnibus Docker images](https://docs.gitlab.com/omnibus/docker/) are now based on Ubuntu 20.04.
> - The allowlist of host headers accepted by GitLab is [now configurable](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5057). By default, everything is allowed.
> - The SMTP configuration for the bundled Grafana service is [now configurable](https://docs.gitlab.com/omnibus/settings/grafana.html#grafana-smtp), enabling emails to be sent to users.
> - `registry` has been upgraded to v3.1.0, `openssl` to 1.1.1j.
> - GitLab 13.10 includes [Mattermost 5.32.1](https://docs.mattermost.com/administration/changelog.html#release-v5-32-feature-release), an open source Slack-alternative whose newest release includes custom collapsible channel categories, some breaking changes, and other improvements. This version also includes security updates and upgrade from earlier versions is recommended.
Omnibus Package[Admin Mode: Re-authenticate for GitLab administration](https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#admin-mode) (self-managed only):
> GitLab now includes Admin Mode, which helps admins work safely from one account. When Admin Mode is not active, admins have the same privileges as a regular user. Before running administrative commands, admin users must reverify their credentials. Admin mode increases instance security by protecting sensitive operations and data. This feature is available behind feature flag `:user_mode_in_session`.
Authentication and Authorization[Run GitLab on small instances with 2GB RAM](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs.html) (self-managed only):
> GitLab can be deployed using one of the [reference
> architectures](https://docs.gitlab.com/ee/administration/reference_architectures/)
> supporting from a few hundred, to tens of thousands of users. However, many community members choose to
> run GitLab only for personal use or for small teams. In those situations,
> it may be desirable to run GitLab on a small cloud instance to save costs
> or, for example, to use [a Raspberry PI 4 with 2GB
> RAM](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/).
>
> We've updated our documentation to include [detailed instructions on how
> to run GitLab in a memory constrained
> environment](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs.html)
> with a minimum of 2GB of RAM and 1GB of swap. This configuration makes a
> few opinionated choices to reduce memory consumption, such as running
> [Puma in single mode](https://docs.gitlab.com/omnibus/settings/puma.html#running-in-memory-constrained-environments)
> (saves ~300-400MB) and disabling the monitoring stack (saves another
> 200MB). We've also tweaked a few other settings for Gitaly and how GitLab
> handles memory allocation.
>
> This configuration allows GitLab to support up to 5 developers with
> individual Git projects no larger than 100MB. For larger team sizes or if
> these settings are not acceptable, we still recommend at least 4GB of RAM (for up to 500 users)
> for best performance. Please see [the reference
> architectures](https://docs.gitlab.com/ee/administration/reference_architectures/)
> for further guidance.
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.10, we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.10 are:
>
> - [Set up Shard Elasticsearch sorted set queues in Redis to reduce load on Redis](https://gitlab.com/gitlab-org/gitlab/-/issues/244865).
> - [Cache the Advanced Search counts request in browser](https://gitlab.com/gitlab-org/gitlab/-/issues/300150).
> - [Improve performance of the "Run pipeline" page for projects with many branches or tags](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55394)
> - [Load epic issue metadata info in batches](https://gitlab.com/gitlab-org/gitlab/-/issues/322013)
> - [Reduce Git reference iteration workload for repositories with many refs](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/400)
[Collapsible list of deployed environments in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/):
> Merge Requests (MRs) are the single source of truth for developers. MRs contain everything you need as a developer in order to commit code changes, collaborate, complete code reviews, and merge code to the target branch.
>
> To improve usability as a part of this release, if your MR is now deployed to more than four deployments, the list of deployments will be collapsed. This is especially useful in situations where you have numerous deployed environments that cause your MR page to be overly lengthy and require you to scroll up and down the page to see all of the content.
Continuous DeliveryUsability improvements
> In every release, we continue to make great strides in improving the overall effectiveness and usefulness of our product.
>
> We also started a [UI Polish gallery](https://papercuts.gitlab.com/?milestone=13.10) to track important updates to our interfaces. They are often small, but make your experience more enjoyable.
>
> In GitLab 13.10, we're shipping usability improvements for issues, projects, milestones, and much more! Some highlights in GitLab 13.10 are:
>
> - [Increase contrast of Solarized Light in the Web IDE](https://gitlab.com/gitlab-org/gitlab/-/issues/322782).
> - [Disable commit button in Web IDE for users who don't have permission to commit](https://gitlab.com/gitlab-org/gitlab/-/issues/213581).
> - [Improve messaging and visual design when a Markdown quick action fails](https://gitlab.com/gitlab-org/gitlab/-/issues/287686).
> - [Improve merge request's empty state text for better readability](https://gitlab.com/gitlab-org/gitlab/-/issues/291998).
> - [Hide “No milestone” option when filtering the milestone dropdown for quicker selection](https://gitlab.com/gitlab-org/gitlab/-/issues/300110).
> - [Improve consistency by updating License Compliance and Dependency List empty state pages](https://gitlab.com/gitlab-org/gitlab/-/issues/290948).
> - [Remove user email addresses from Service Desk issues](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54140).
> - [On boards, let any license hide backlog/closed list](https://gitlab.com/gitlab-org/gitlab/-/issues/270099).
> - [Allow users to edit iterations within the sidebar in boards](https://gitlab.com/gitlab-org/gitlab/-/issues/290232).
> - [Allow users to create iterations in the past](https://gitlab.com/gitlab-org/gitlab/-/issues/230894).
[Search and autocomplete by full name in comment mentions](https://docs.gitlab.com/ee/user/project/autocomplete_characters.html):
> It's not common for GitLab users to use their full name as their username. This makes it difficult to find the individuals you want to `@` mention because the autocomplete doesn't do a great job matching both full name or username. As a first step towards [making autocomplete smarter](https://gitlab.com/gitlab-org/gitlab/-/issues/207134), you can now more easily search for people based on their username or full name.
Issue Tracking[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[Automatically retarget merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#update-merge-requests-when-target-branch-merges):
> You've likely needed to create chained merge requests where the first merge request targets a feature branch, which in turn already has a merge request targetting `main`. This is a common workflow to help keep merge requests small for review and indicate merge order. However, if a merge request in the chain is merged and its branch is deleted, any subsequent merge request is no longer mergeable, as its target is missing.
>
> GitLab now automatically updates the target of merge requests where the original target branch has been deleted. This ensures merge requests can continue to be reviewed and merged, and manual action isn't required on the part of merge request authors or reviewers.
Code Review[Clone project inside Visual Studio Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#git-extension-integration):
> When using the Visual Studio Code IDE (VS Code) you may need to work on a code repository that you don't have on your local machine. Before, cloning a project required several steps away from your editor: find the project in GitLab, copy its clone link, clone it into your local machine, and finally open it in VS Code.
>
> With the [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) extension you can now use the `Git: Clone` command in VS Code to do all of that without leaving your editor. Use this command to search for projects in GitLab and clone them so you can quickly begin contributing.
>
> Thanks [Felix Haase](https://gitlab.com/haasef) for the contribution!
Editor Extension[Notify participants when merge request is marked ready](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html#mark-merge-requests-as-ready):
> When you have finished preparing your merge requests you can signal it is ready for review by marking it as ready and removing the draft status. However, marking a merge request as ready did not inform other participants that your merge request is ready for their review.
>
> Now, when marking a merge request as ready, a notification is sent to participants of the merge request. Alerting merge request participants that your merge request is ready for review helps to shorten cycle time and get your contribution merged faster.
Code Review[Open project in Visual Studio Code](https://docs.gitlab.com/ee/user/project/repository/#clone-and-open-in-visual-studio-code):
> When working on a project for the first time, you often clone that project locally to start contributing via your local editor. This process involves a few steps: initially getting the path for cloning, finding a place on your system to clone the project, and then opening that project inside your editor of choice.
>
> When clicking the **Clone** dropdown for a project, you can now choose to open the project in Visual Studio Code (VS Code). Cloning is now a one-click experience: clone the project and then immediately start work in VS Code.
>
> Thanks [@KevSlashNull](https://gitlab.com/KevSlashNull) for your contribution!
Editor Extension[Show number of files in a snippet in the list view](https://docs.gitlab.com/ee/user/snippets.html#add-or-remove-multiple-files):
> GitLab 13.5 introduced the ability to create snippets that contain multiple files. However, there was no way for you to identify these multi-file snippets in the list view. You needed to open each snippet to distinguish between similarly-named snippets or to infer the type of data included by how many associated files it contains.
>
> Now, the number of files contained in each snippet is displayed in the list view so you have access to this information before opening it.
Snippets[Use 'parallel: matrix' with trigger jobs](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-matrix-of-parallel-trigger-jobs):
> You can use the `parallel: matrix` keywords to run jobs multiple times in parallel, using different variable values for each instance of the job. Unfortunately, you could not use it with trigger jobs. In this release, we've expanded the parallel matrix feature to support trigger jobs as well, so you can now run multiple downstream pipelines (child or multi-project pipelines) in parallel using different variables value for each downstream pipeline. This lets you configure CI/CD pipelines that are faster and more flexible.
Pipeline Authoring[GitLab Runner for Red Hat OpenShift GA](https://docs.gitlab.com/runner/install/openshift.html):
> The GitLab Runner Operator is generally available in the [Red Hat OpenShift Container Platform](https://www.openshift.com/products/container-platform). To install GitLab Runner on OpenShift, you can use the [GitLab Runner Operator](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator), which is available from the stable channel in the OperatorHub. The Container Platform is a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. We are also developing an [Operator](https://gitlab.com/groups/gitlab-org/-/epics/3444) for GitLab, so stay tuned to future release posts for those announcements.
GitLab Runner[Merge Request test summary usability improvements](https://docs.gitlab.com/ee/ci/unit_test_reports.html):
> Increasing the number of tests or custom metrics in a pipeline gives you additional confidence and information. However, increasing these to a large number has also come with a degraded visual experience of the Merge Request page. The Merge Request test summary widget has been improved so you can better differentiate between the different test jobs in the widget, making it easier to identify which job contains failed tests.
>
> It has also been challenging to understand why a `junit.xml` file was not parsed without errors being presented. Now you can see parsing errors in the Test Summary widget, as well as the Unit Test report, to identify and resolve structural issues and see test results in GitLab.
>
> The [Metrics Reports](https://docs.gitlab.com/ee/ci/metrics_reports.html) widget [(Premium and Ultimate)](https://about.gitlab.com/pricing/) is now sorted so new, changed, and unchanged metrics are all together, making the experience of finding metrics that have changed as part of the Merge Request more intuitive.
Code Testing and Coverage[GitLab Runner 13.10](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.10 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:
>
> - [Support graceful process termination on Windows, enabled by using the `FF_USE_WINDOWS_LEGACY_PROCESS_STRATEGY` feature flag](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4917).
> - [Update job log output limit exceeded warning](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27601).
GitLab Runner[Predefined CI/CD variables for job start and pipeline created timestamps](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-reference):
> Previously, if you wanted to reference the exact date and time when a job started
> or a pipeline was created, you needed to retrieve these timestamps in your scripts.
> Now they are readily available as predefined CI/CD variables by using `CI_JOB_STARTED_AT` and
> `CI_PIPELINE_CREATED_AT`, provided in the ISO 8601 format and UTC time zone.
>
> Thanks to [@Winkies](https://gitlab.com/winkies) for this contribution!
Continuous Integration (CI)[Easily access Gradle setup and install commands](https://docs.gitlab.com/ee/user/packages/package_registry/#view-packages):
> You can use the GitLab Package Registry to publish your Java dependencies with Maven or Gradle. Once published, you can navigate to the Package Registry UI to view the package and its related metadata. When viewing a specific package, you have access to snippets for configuring and installing the package using Maven. But we did not provide the correlated commands for Gradle users.
>
> Moving forward, you can now copy both Maven and Gradle commands, making you more efficient. Simply navigate to your project or group's package registry, click a specific Java package, and copy the snippets. [Groovy](https://docs.gradle.org/current/userguide/groovy_plugin.html), right?
>
> Thank you to [@Cromefire_](https://gitlab.com/cromefire_) for helping us to iterate on the content and design for this feature!
Package Registry[Ease the npm package naming convention](https://docs.gitlab.com/ee/user/packages/npm_registry/#use-the-gitlab-endpoint-for-npm-packages):
> When publishing npm packages to your project's Package Registry, you previously had to name your package with `@scope/package-name` so that the scope was an exact match to the root workspace of your project, including the case. For example, if your project path was `/Acme/project_a`, when you published a package, it had to have `Acme` as the scope.
>
> For many of you, this meant using a capital letter. However, the [public npm registry](https://www.npmjs.com/) does not allow capital letters in the scope. So, you were forced to either change your group name, which might have had [unintended side effects](https://docs.gitlab.com/ee/user/project/repository/index.html#redirects-when-changing-repository-paths), or you might have chosen to not use the GitLab Package Registry.
>
> Moving forward, we will no longer enforce this naming convention for the project-level endpoint. Huzzah! Now you can name your packages and scope whatever you want.
>
> It's worth noting that using the instance-level endpoint will still require you to use the exact (case-sensitive) root of your namespace as the `@scope`.
Package Registry[Use the Dependency Proxy with 'containerd' and Docker 20+](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#store-a-docker-image-in-dependency-proxy-cache):
> The GitLab Dependency Proxy is a local proxy you can use for your frequently-accessed upstream images from Docker Hub. In the case of CI/CD, the Dependency Proxy receives a request and returns the upstream image from a registry, acting as a pull-through cache. This helps to reduce your CI minutes and increase reliability.
>
> However, you haven't been able to pull images by digest, which as an immutable identifier ensures you are using the exact version of a specific image and tag. Since both `containerd` and Docker 20+ depend on pull-by-digest, this meant that many of you were blocked from using the Dependency Proxy.
>
> We are happy to say that you can now pull your container images from Docker Hub by digest. You can use the Dependency Proxy by adding the URL to your `.gitlab-ci.yml` file, manually pulling the image from the command line, or using a Dockerfile. Check out the documentation and start saving time on your builds.
Dependency Proxy[Static Analysis Analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab Static Analysis is comprised of a [set of many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 13.10. These updates bring additional coverage, bugfixes, and improvements.
>
> - ESLint updated to version 7.21.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/merge_requests/73) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/blob/master/CHANGELOG.md)
> - MobSF updated to version 3.3.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/19) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md)
> - notable change: MobSF will skip files that are over 25MB, macOS BigSur support, and [additional improvements](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v260)
> - njsscan updated to version 0.2.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/merge_requests/94) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/blob/master/CHANGELOG.md)
> - notable change: njsscan will skip files that are over 25MB
> - GitLeaks updated to version 7.3.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/102) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md)
> - spotbugs updated to version 4.2.2: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/merge_requests/92) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md)
> - pmd updated to version 6.32.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/merge_requests/53) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md)
> - sobelow updated to version 0.11.1: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/merge_requests/50) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/blob/master/CHANGELOG.md)
> - gosec updated to version 2.7.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/merge_requests/91) - [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/master/CHANGELOG.md)
>
> If you are [including the GitLab managed vendored SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations.
SAST, Secret Detection