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

Name: GitLab

Released: 2021-05-22

License: MIT

Release Assets:

![43 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=43&style=for-the-badge "New features added in this release") ![2073 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=2073&style=for-the-badge "Total features") #### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![6 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=6&style=flat-square "New features added to this tier in this release") ![267 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=267&style=flat-square "Total features in this tier")

[Group-level deployment frequency CI/CD chart](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts): Continuous Delivery

> As part of our efforts to natively support [DORA4 metrics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#devops-research-and-assessment-dora-key-metrics) in GitLab, the group-level deployment frequency chart is now available. This chart will show the aggregated deployment frequency metrics for all the projects that are part of the group, and allow you to get a full picture of the deployment frequency across multiple projects and teams, so that you can comprehend their efficiency more accurately. Monitoring deployment frequency helps you understand the efficiency of your deployments over time, find bottlenecks, and focus on improvement areas that span across your projects and teams.

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

[Code quality violation notices in MR diffs](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-in-diff-view): Code Quality

> During code reviews, you may have wanted to highlight Code Quality violations and how to resolve them. Previously, this involved having a browser window open to see the violations on the Merge Request summary and another window reviewing the changes in the MR or your IDE. You may have found switching between them too difficult and given up. > > Now, you can see if the file you are reviewing has new code quality violations that are part of the changes right in the Merge Request diff view. This gives you the necessary context to suggest a fix as part of your normal workflow within GitLab without having to keep additional windows open and context switch back and forth between them.

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

[On-demand DAST GA launch](https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans): DAST

> After months of work, we are pleased to announce that our on-demand DAST scanning has reached a General Availability (GA) maturity level. It is ready for usage by anyone who needs to scan an already-deployed application or API outside of a CI/CD pipeline job. With the 13.11 release, we added to on-demand DAST Site profiles the ability to specify authentication information, exclude URLs, add additional request headers, and switch between scanning web applications and APIs. This is in addition to the ability to save scans for quick reusability that was added in 13.9, and the ability to select the branch that a scan is associated with that was added in 13.10. We believe this feature set meets the needs of a majority of GitLab customers. > > As we continue to add features, such as scan scheduling, we expect on-demand DAST scanning to cover an ever-increasing range of use cases. As always, we would love as much feedback about these features as possible. Please let us know how things are working for you by leaving a comment in [issue 327396](https://gitlab.com/gitlab-org/gitlab/-/issues/327396).

[New browser-based crawler for DAST in open beta](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html): DAST

> Starting in 13.12, we are extremely excited to announce the beta release of our new browser-based crawler. Since we are in the beta phase, we are actively seeking DAST users who will enable the new crawler and give us feedback. This new crawler is specifically designed to provide better application testing coverage by finding more pages on a JavaScript-heavy app that might be hidden from a traditional proxy-based crawler. As websites and applications continue to be more and more JavaScript-heavy, we have seen the need for a new generation of tools that are purpose-built to address the needs of JavaScript-heavy and single-page applications. This is our first step in the journey to provide better crawl and test coverage for these modern applications. > > In our benchmark testing, our browser-based crawler has shown a significant improvement in crawl coverage from our current proxy-based crawler. We want feedback from usage on real-world applications to validate that the new crawler is able to crawl a majority of pages for a majority of apps. The process for enabling this new crawler is documented at [DAST browser-based crawler](https://docs.gitlab.com/ee/user/application_security/dast/browser_based.html#enable-browser-based-crawling). > > Any and all feedback is welcomed and encouraged, as are bug reports. Feel free to comment [in issue 327394](https://gitlab.com/gitlab-org/gitlab/-/issues/327394) or create a new issue and assign it to `@derekferguson`. We look forward to bringing this feature to GA in the next few months and providing better DAST coverage for modern applications.

[Configuration tool for Secret Detection](https://docs.gitlab.com/ee/user/application_security/configuration/): Secret Detection

> Following in the footsteps of the [GitLab SAST configuration tool](https://docs.gitlab.com/ee/user/application_security/sast/index.html#configure-sast-in-the-ui) we are adding support for Secret Detection on the Security Configuration page. 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 experts to get started with [GitLab Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/). The tool helps a user create a merge request to enable Secret Detection 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). The Configuration tool can create a new `.gitlab-ci.yml` file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI setup.

[Filter Project Vulnerability Report by vendor name](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#vulnerability-report): Vulnerability Management

> GitLab strives to play well with others and security is no exception. We provide many security scanners as part of our Secure offering. We also encourage 3rd party vendors to [integrate their scanning tools](https://docs.gitlab.com/ee/development/integrations/secure.html) using our open API and data interchange formats. A benefit of using GitLab is managing vulnerabilities from multiple scanners in a unified experience. While you were already able to filter by scanner type (SAST, DAST), it wasn't possible to drill down by the tool provider. > > You now have even more granularity when managing vulnerabilities with the new ability to filter by scanner and vendor. You can look at all results across a single vendor's scanners or gain confidence in findings from one scan type (e.g. SAST) that are confirmed by both GitLab and the 3rd party tool. The new filtering capability is available now in Project Vulnerability Reports.

#### [Premium](https://about.gitlab.com/pricing/premium/) ![11 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=11&style=flat-square "New features added to this tier in this release") ![423 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=423&style=flat-square "Total features in this tier")

[Improvements to the deployment metrics in Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/index.html#how-metrics-are-measured): Value Stream Management

> We improved the Deploys and Deployment Frequency metrics in group-level Value Stream Analytics. These metrics now consider only deployments to environments [classified as production tier](https://docs.gitlab.com/ee/ci/environments/#deployment-tier-of-environments) instead of all deployments. The metrics now provide more value, because often deployments to non-production environments are not relevant. > > Also, these metrics are now calculated based on the time the deployment finished, instead of the time it was created. This brings improved accuracy of the data in a given time frame.

[View and sort stage items in a value stream](https://docs.gitlab.com/ee/user/group/value_stream_analytics/index.html#stage-table): Value Stream Management

> Previously, Value Stream Analytics only displayed the 20 newest workflow items for each stage in a value stream. This update adds pagination and sorting for workflow items. > > You can now view all the items in each stage of your value stream and sort by time spent in a stage to more easily pinpoint bottlenecks in the software development lifecycle. For example, if code changes have been taking longer to merge, sort items in the Code stage to identify the slowest items and investigate possible causes.

[View average time to complete workflow items](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#days-to-completion-chart): Value Stream Management

> The Days to Completion chart in Value Stream Analytics previously showed the sum of days it took to complete all workflow items that were finished on a specific day. If an unusually high number of items was completed on the same day, the chart would show a high number for that day, which isn't particularly meaningful. > > The chart now shows the average time to completion instead, which highlights meaningful trends over time.

[Geo replicates LFS files with self-service framework](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#data-types) (self-managed only): Disaster Recovery, Geo-replication

> Although Geo already replicates LFS files, moving this functionality to use the [Geo self-service framework](https://docs.gitlab.com/ee/development/geo/framework.html) improves maintainability and performance of LFS file replication. This update will allow us to delete around 200 of lines of code and more easily [add support for verification](https://gitlab.com/gitlab-org/gitlab/-/issues/323286) in an upcoming release. LFS file replication and deletion events will also be triggered sooner (up to a minute in some cases). To learn more about the Geo self-service framework, read [this blog post about how we are closing the gap on replicating everything in Geo](https://about.gitlab.com/blog/2021/04/29/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo/).

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

> Geo secondary sites use a separate PostgreSQL database as a [tracking > database](https://docs.gitlab.com/ee/administration/geo/#geo-tracking-database) > to keep track of replication status and automatically recover from > potential replication issues. Without the tracking database, Geo cannot > replicate data to another site. Geo now supports setting up a > [separate, highly-available PostgreSQL cluster](https://docs.gitlab.com/ee/administration/geo/setup/database.html#configuring-patroni-cluster-for-the-tracking-postgresql-database) > for Geo's tracking database. This configuration is important when a > secondary site is used as part of a disaster recovery strategy because > it ensures that replication isn't impacted even when a single PostgreSQL > node running the tracking database fails.

[Geo support for PostgreSQL high availability in Beta](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 also allows the > configuration of a highly-available 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 > [beta-level](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta) > support for highly available PostgreSQL configurations using > [Patroni](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#patroni). > We've improved [upgrades to a Patroni standby > cluster](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5790), > implemented [automatic recovery from leader changes on the > primary](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5788), > addressed initial [setup issues](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5959), > and fixed a number of bugs.

[Geo verifies replicated Terraform state files](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#data-types) (self-managed only): Disaster Recovery, Geo-replication

> Geo automatically verifies the data integrity of replicated [Terraform state files](https://docs.gitlab.com/ee/administration/terraform_state.html). 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.

[Enforce delayed project removal for all subgroups](https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal): Subgroups

> Group owners can now enable and enforce [delayed project removal](https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal) for all subgroups and projects in their group. Delayed project removal protects your data by placing deleted projects in a read-only state after deletion and can be restored, if required. We plan to expand our settings model and allow more settings to be inherited and enforced in subgroups and projects in future milestones. Our new settings management model gives group owners a way to ensure that their subgroups and projects settings adhere to their organization's security and compliance needs.

[Obfuscate Elasticsearch password in Admin UI](https://docs.gitlab.com/ee/integration/elasticsearch.html#advanced-search-configuration) (self-managed only): Global Search

> With the Elasticsearch integration, GitLab administrators could only configure a password-protected Elasticsearch server by using the URL with the format `http(s)://:@:/`. However, the password was displayed in plain text in the GitLab admin UI. Feedback given by our users showed us that this can be a potential liability as not all GitLab instance admins should be able to see that password. > > With this release, we provide separate input fields for the Elasticsearch username and password, and the password is obfuscated so that users can't see the characters in plain text.

[View the number of workflow items in a value stream stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics): Value Stream Management

> Value stream analytics shows the median time that workflow items took to complete a stage in a value stream, as well as a list of the items that completed the stage. This release adds an item count so you can easily see how many workflow items completed the stage and were used to calculate the median value.

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

[Warn administrator when removing an on-call user](https://docs.gitlab.com/ee/operations/incident_management/oncall_schedules.html#removal-or-deletion-of-on-call-user): Incident Management

> Being on-call is a critical function. It affects the on-call schedule when an administrator > removes an on-call user from a project, a group, or the GitLab instance. Administrators are > now warned before executing such a removal.

#### Core ![26 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=26&style=flat-square "New features added to this tier in this release") ![1383 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=1383&style=flat-square "Total features in this tier")

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

> - Users were restricted to using the standard 80/443 port to expose NGINX to the LoadBalancer. However, the new nginx-ingress chart now gives users the ability to set their LoadBalancer service ports to a custom port. You can view the [NGINX site configuration docs](https://docs.gitlab.com/ee/install/installation.html#site-configuration) to learn more. > - We have [upgraded to PostgreSQL 13 client libraries](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/655). This allows us to support backup/restore to PostgreSQL 13, while still retaining support for PostgreSQL 12 and PostgreSQL 11. This has no impact on the version of PostgreSQL we are running in the chart.

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

> - GitLab 13.12 includes [Mattermost 5.34](https://mattermost.com/blog/mattermost-release-v5-34/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes new CircleCI and Dice Roller plugins, and more. > - The `etc-backup` job, which backs up local GitLab configuration, was [not respecting the rotation rules](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4689) set by `gitlab_rails['backup_keep_time']`. Due to this, old backups were never pruned. For 13.12, the default will be to leave files in place if no setting has been made. For 14.0, the [`etc-backup` job will respect current settings](https://docs.gitlab.com/omnibus/settings/backups.html). Only administrators who modified this setting will see a change, because the default is to keep all backups.

[Instance-level Federated Learning of Cohorts (FLoC) opt-in](https://docs.gitlab.com/ee/administration/settings/floc.html) (self-managed only): Omnibus Package

> [Federated Learning of Cohorts (FLoC)](https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts) is a new type of web tracking, intended to replace the use of third-party cookies. It does this by grouping users into cohorts based on their browsing history, for the primary purpose of interest-based advertising. FLoC is being activated in the Chrome browser in some regions. > > With GitLab 13.12, FLoC will not incorporate GitLab browsing activity by default. If an instance administrator would like their users' GitLab instance usage to contribute to FLoC, they can re-enable in instance settings.

[Users' group counts now displayed in Admin Area](https://docs.gitlab.com/ee/administration/admin_area.html#administering-users) (self-managed only): Compliance Management

> The user list in the Admin Area now shows the total number of groups > a given user has access to. The group count is a sum of both group and subgroup membership. > > This is incredibly valuable, > because you can easily see how much access users have and quickly > identify when action is needed. For example, you might use this information > to ensure that deactivated accounts no longer have access to any projects or > groups in GitLab.

[Migrate GitLab Pages in the background](https://docs.gitlab.com/ee/administration/pages/#zip-storage) (self-managed only): Pages

> In preparation for moving GitLab Pages to the new [ZIP-storage architecture](https://docs.gitlab.com/ee/administration/pages/#zip-storage) in 14.0, > we introduced an automatic background migration in 13.11. This background migration converted existing sites to the new storage format and run at a very slow speed to avoid having a significantly negative impact on the performance of your instance. > In GitLab 13.12, we will add the option to run the same migration with greater speed. > You can also [run the migration manually](https://docs.gitlab.com/ee/administration/pages/#migrate-legacy-storage-to-zip-storage). > This will allow you to verify the migration result, identify any migration errors, and fix them.

[Deleting deploy keys will inform the user if in use](https://docs.gitlab.com/ee/user/project/deploy_keys/#project-deploy-keys): Continuous Delivery

> In this release, we have added an additional safety measure to warn users that a deploy key is in use before deleting the key. This will help prevent accidentally breaking workflows.

[Filter active deploy tokens](https://docs.gitlab.com/ee/api/deploy_tokens.html): API, Continuous Delivery

> Before this milestone, the [Deploy Tokens API](https://docs.gitlab.com/ee/api/deploy_tokens.html) endpoints for listing tokens would return all database stored entries, including revoked and expired tokens, without a way to filter the list. Now we have added the ability to filter only active tokens from the REST API. A huge thanks to [Devin Christensen](https://gitlab.com/quixoten) for a great community contribution!

[New Gatsby CI Pages template](https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_ci_cd_template.html): Pages

> The previous Pages template for Gatsby would not work out of the box. You needed to manually fix your pipelines after using the predefined template. In this milestone, we have provided a new template for you to use that results in a green pipeline upon first run. Thank you [Takuya Noguchi](https://gitlab.com/tnir) for this great contribution that will help additional members of the GitLab wider community to get started with Pages.

[release: keyword supports asset links](https://docs.gitlab.com/ee/ci/yaml/#releaseassetslinks): Release Orchestration

> Since GitLab 13.2, you've been able to use the `release:` keyword, in conjunction with the [release-cli](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs), to create a release. > The `release:` keyword has now been extended to include support for asset links so that you can create releases and attach files to them in a single `.gitlab-ci.yml` release job.

[Elastic Stack cluster integration](https://docs.gitlab.com/ee/user/clusters/integrations.html#elastic-stack-cluster-integration): Kubernetes Management

> Previously, to take full advantage of Gitlab [Log Explorer](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html), you had to install the Elastic stack via GitLab Managed Apps. This was problematic because managing and operating the Elastic Stack is important and not something you wished to outsource to GitLab. > > With this release, you can integrate your existing Elastic Stack with GitLab. Whilst maintaining control, you can still take advantage of the features offered by GitLab Log Explorer.

[Take ownership of existing GitLab Managed Applications](https://docs.gitlab.com/ee/user/clusters/applications.html#take-ownership-of-your-gitlab-managed-apps): Kubernetes Management

> As previously announced, one-click GitLab Managed Applications were deprecated in GitLab 13.9 and will be definitively removed from GitLab in version 14.0, scheduled for June 22nd. Follow the documentation to learn how to take ownership of your applications and continue using them normally.

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

[Time tracking reports for issues and merge requests](https://docs.gitlab.com/ee/user/project/time_tracking.html#view-a-time-tracking-report): Time Tracking

> Project members can record time spent on an issue or merge request via the `/spend` quick action, but it hasn't been easy to understand how much time each person contributed. > As a step toward better visibility of time reports in projects and groups, you can now view a time report in an individual issue or merge request. After time is spent against an issue, select the **Time tracking report** on the sidebar to view a list of all time spent entries for that issue or merge request. > Thanks [@leetickett](https://gitlab.com/leetickett) for the contribution!

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

[Useful GitLab CI/CD information in the pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/): Pipeline Authoring

> Creating your first GitLab CI/CD pipeline can be difficult, especially for those new to CI/CD. You might spend time switching back and forth between documentation and GitLab to get your first pipeline configured. In this release we've added a drawer with useful information to the pipeline editor to help guide you through the steps of writing your first pipeline.

[Support wildcards when including YAML CI/CD configuration files](https://docs.gitlab.com/ee/ci/yaml/#includelocal-with-wildcard-file-paths): Pipeline Authoring

> The `includes:` keyword for CI/CD pipelines lets you break one long `.gitlab-ci.yml` file into multiple smaller files to increase readability. It also makes it easier to reuse configuration in multiple places. Frequently there are multiple files included into a single pipeline, and they all might be stored in the same place. In this release, we add support to use the `*` wildcard with the local `includes:` keyword. You can now make your `includes:` sections more dynamic, less verbose, and easier to read, check out how we are [dogfooding](https://gitlab.com/gitlab-org/gitlab/-/commit/f0629cc5eaa70a29cb2d98e5e1e0915d4968840e) it in GitLab.

[Show job dependencies in the pipeline graph](https://docs.gitlab.com/ee/ci/pipelines/#view-job-dependencies-in-the-pipeline-graph): Pipeline Authoring

> The full pipeline graph provides a visual representation of all the jobs in your CI/CD pipeline, grouped by stage. This visualization helps you track the progress of your jobs and sets expectations for the order in which jobs will execute. > > The introduction of the [`needs` keyword](https://docs.gitlab.com/ee/ci/yaml/#needs) let you create a directed acyclic graph that lets jobs start running earlier than they would if they were configured solely by stage. However, this creates ambiguity when looking at the pipeline graph, as its harder to tell in what order you could expect jobs to run. > > In this release, you now have the ability to view pipelines by job dependencies when the job order reflects the `needs:` relationships between jobs. We've also added links between jobs to see exactly which jobs need to complete before a particular job can start. It will be much easier for you to track and understand job dependencies and expected run order when using the `needs:` keyword.

[Failed test screenshots in test report](https://docs.gitlab.com/ee/ci/unit_test_reports.html#viewing-junit-screenshots-on-gitlab): Code Testing and Coverage

> GitLab makes it easy for teams to set up end-to-end testing with automation tools like Selenium that capture screenshots of failed tests as artifacts. This is great until you have to sort through a huge archive of screenshots looking for the specific one you need to debug a failing test. Eventually, you may give up due to frustration and just re-run the test locally to try and figure out the source of the issue instead of wasting more time. > > Now, you can link directly to the captured screenshot from the details screen in the Unit Test report on the pipeline page. This lets you quickly review the captured screenshot alongside the stack trace to identify what failed as fast as possible.

[Support variables in CI/CD pipeline 'workflow:rules'](https://docs.gitlab.com/ee/ci/yaml/#workflowrulesvariables): Pipeline Authoring

> Previously, the `rules` keyword was limited in scope and only determined if a job should be included or excluded from pipelines. [In 13.8](https://about.gitlab.com/releases/2021/01/22/gitlab-13-8-released/#support-variables-for-pipeline-rules), we added the ability to use the `variables` keyword with `rules` to set variable values in a job based on which rule matched. In this release we've extended this ability to `workflow: rules`, so you can set variable values for the whole pipeline if certain conditions match. This helps you make your pipelines even more flexible.

[Lock latest pipeline artifact to prevent deletion](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in): Continuous Integration (CI)

> GitLab now automatically locks the latest artifact produced from a successful pipeline on any active branch, merge request, or tag to prevent it from being deleted based on expiration if it is still the most recent artifact. > > This makes it easier to set a more aggressive expiration policy to clean up older artifacts, helps reduce disk space consumption, and ensures you have always got a copy of the latest artifact from your pipeline. > > Pipeline artifacts, such as those used by the [test coverage visualization feature](https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html), are not explicitly managed by the `.gitlab-ci.yml` definitions.

[Pipeline status widget in the pipeline editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html): Pipeline Authoring

> Previously, after committing changes using the pipeline editor, you had to navigate to a different page to know the real time status of your pipeline. In this release, we added a pipeline status widget to the pipeline editor so that you can monitor the status of your pipeline without leaving the comfort of the editor.

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

> We’re also releasing GitLab Runner 13.12 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 Git strategy with the GitLab Runner Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847) > - [Pass variable name in Vault secrets path](https://gitlab.com/gitlab-org/gitlab/-/issues/301063) > > > #### Bug Fixes: > > - [PowerShell core failures not being detected](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27830) > - [Exit code improperly reported using the Bash script with `set -e`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27668) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-12-stable/CHANGELOG.md).

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

[Allow or prevent duplicate generic package uploads](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagesettings): Package Registry

> You can use the GitLab Package Registry to publish and download your project's generic packages. By default, you can publish the same package name and version multiple times. > > However, many of you have expressed that you want to prevent duplicate uploads, especially for releases. GitLab 13.12 expands the group setting for the Package Registry to allow or prevent duplicate uploads. > > You can adjust this setting by using the [GitLab API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagesettings), or from **Settings > Packages & Registries** in the application. The coming milestones will continue to expand this setting for each package manager format. Please follow along in the [epic](https://gitlab.com/groups/gitlab-org/-/epics/5070) or consider contributing a change!

[Delete associated package files via API](https://docs.gitlab.com/ee/api/packages.html#delete-a-package-file): Package Registry

> You use the GitLab Package Registry to publish, install, and share your dependencies. You may do this using a variety of package manager formats, such as Maven or npm. If you do this as part of your CI workflow, you may publish many packages to your registry. When you publish a dependency, it generates several files including the package archive. > > Prior to GitLab 13.12, GitLab didn't provide a way to delete the files from a package. You could only delete the package itself. These extra files can clutter the user interface or result in someone installing an incorrect or outdated dependency. > > In GitLab 13.12, you can now use the Packages API to delete files related to a given package, as well as the package itself. You can easily integrate this new endpoint into your CI workflow and start removing old, unused files. To give you another option for managing your registry, future releases will add the ability to [delete such files through the user interface](https://gitlab.com/gitlab-org/gitlab/-/issues/13537).

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

[Semgrep SAST Analyzer for JavaScript, TypeScript, and Python](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> In GitLab 13.11 we [announced an experimental release](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#experimental-semgrep-analyzer-for-python-javascript-and-typescript) of [Semgrep](https://semgrep.dev/), a new SAST analyzer for JavaScript, TypeScript, and Python. This transition has been [developed in partnership](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#gitlab--semgrep-upgrading-sast-for-the-future) with [r2c](https://r2c.dev/), the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our [experimental analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features), we're ready to start the transition to Semgrep. > > With 13.12, we're updating our managed `SAST.gitlab-ci.yml` CI template to automatically run this new analyzer alongside our existing JavaScript and TypeScript analyzer, ESlint. In a future release we will fully disable ESLint, but for now it will work in unison with Semgrep. We've done work to deduplicate findings, so you should not notice any difference in findings. If you include our `SAST.gitlab-ci.yml`, you don't need to do anything to start benefiting from the Semgrep analyzer, however if you override or manage your own SAST CI configuration, [you should update your CI configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L275). > > Both GitLab and r2c are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We'll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We've created a [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/330578) where you can share your experience with this transition or ask questions.

[Mobile application binary scanning support](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST

> Since GitLab 13.6, we've offered [SAST for Android and iOS mobile projects](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#sast-support-for-ios-and-android-mobile-apps). Initially our Mobile App SAST supported the automatic detection of Xcode projects and Android manifest files. With this release and contribution from community contributor [@proletarius101](https://gitlab.com/proletarius101), GitLab SAST now also supports the automatic detection of .ipa (iOS) and .apk (Android) binary files enabling the security scanning of fully built mobile application artifacts. This offers mobile teams more flexibility with how they build and scan their mobile projects with GitLab SAST for security vulnerabilities. > Please note that mobile application scanning is still an experimental feature and [requires enabling the experimental flag](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features) in your CI template. We will make the mobile application scanner generally available without this flag [in the near future](https://gitlab.com/groups/gitlab-org/-/epics/5977).

[Static Analysis Analyzer Updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST, Secret Detection

> 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.12. These updates bring additional coverage, bug fixes, and improvements. > > - MobSF updated to version 3.4.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/24/diffs), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v2100) > - nodejs-scan updated to version 0.2.6: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/24/diffs), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v2100) > - GitLeaks updated to version 7.5.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/112), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v3200) > - pmd-apex updated to version 6.34.0: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v2122) > - Spotbugs updated to version 4.2.3: [MR](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/merge_requests/97), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v2282) > > 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.

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

[Create incidents via API](https://docs.gitlab.com/ee/api/issues.html#new-issue): API, Incident Management

> The most effective incident management tools enable you to create incidents automatically from different sources. To create incidents automatically, you can integrate your proprietary systems with GitLab via API. GitLab 13.12 introduces the `issue_type` attribute to the GitLab [REST API](https://docs.gitlab.com/ee/api/issues.html#new-issue) and the `type` field to the GitLab [GraphQL API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationcreateissue). When creating issues with these APIs, you can create incidents by setting `issue_type` to `incident` (REST API), or by setting `type` to `INCIDENT` (GraphQL API).