GitLab.org/GitLab: Release v12.9.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.9
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)
[Suggested solution for Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/#solutions-for-vulnerabilities-auto-remediation):
> When Container Scanning finds a known vulnerability for your base image,
> GitLab offers a suggested solution (upgrading to the next version of
> the vulnerable package) where applicable. Users must select **Resolve with merge request** and submit the
> merge request that is generated with the proposed solution. This helps you
> swiftly and efficiently respond to and resolve container-based security
> findings while reducing your security risk and compliance risk. Please provide
> feedback for desired improvements [in this epic](https://gitlab.com/groups/gitlab-org/-/epics/2455).
Container Scanning[Flag outdated security reports in the Merge Request](https://docs.gitlab.com/ee/user/application_security/#outdated-security-reports):
> Previously, it was impossible to tell from the merge request view whether the security report for the branch was out of date. This was only solvable by manually comparing the security report in the merge request to the security report on the master branch. The merge request will now show that the security report for the selected branch is outdated if the source branch is behind the target branch in commits. Guidance is offered to bring it up to date.
DAST, SAST, Dependency Scanning, Container Scanning[Support SAST in networks with a custom Certificate Authority](https://docs.gitlab.com/ee/user/application_security/sast/#custom-certificate-authority):
> GitLab instances can now leverage SAST scans on environments with custom Certificate Authorities. This allows advanced network configurations such as leveraging self-signed certificates or custom Certification Authorities to enable use cases like HTTPS traffic observation and monitoring.
SAST[Updated documentation to include steps to run offline SAST for self-managed instances](https://docs.gitlab.com/ee/user/application_security/sast/#running-sast-in-an-offline-air-gapped-installation) (self-managed only):
> We have enhanced our documentation to better describe how to run SAST
> scans in a self-managed, offline GitLab environment.
>
> This will allow you to improve your project's security, while still
> being in compliance when running GitLab in an offline environment.
SAST[Select and dismiss multiple vulnerabilities](https://docs.gitlab.com/ee/user/application_security/#dismissing-multiple-vulnerabilities):
> Our security dashboards provide quick insight and visibility of
> potential vulnerabilities detected by our various [Secure scanners](/direction/secure/#categories).
> Engineering and security team members can quickly review, triage, and
> create issues for remediating vulnerabilities. Sometimes, vulnerabilities
> do not need to have further action taken and can be dismissed. For
> projects with multiple such findings, dismissing each individually
> can be time consuming.
>
> We're excited to announce new functionality on the security dashboards
> that improves the efficiency of vulnerability management. You can now
> quickly select multiple vulnerability findings and dismiss them all at once.
>
> From a pipeline, project, group, or instance security dashboard, select
> all vulnerabilities on the screen with a single click or choose
> specific ones to then dismiss with a pre-set reason. For even faster
> triaging, use the existing dashboard filters to look at only specific
> vulnerability types where dismissable findings are likely to appear.
Vulnerability Management[Web Application Firewall (WAF) Statistics Reporting](https://docs.gitlab.com/ee/user/clusters/applications.html#viewing-web-application-firewall-traffic):
> We're pleased to announce WAF Statistics Reporting! You can now see
> data on both total and blocked traffic, allowing
> you to more easily determine how to configure, tune, and evaluate the
> Web Application Firewall.
>
> WAF statistics will appear on a new **Threat Monitoring** page under the
> **Security & Compliance** menu item. By default, this data covers a 30
> day period.
WAF[Customizable Value Stream analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics)
> Value Stream Analytics allows teams to understand the behavior of their development process by providing key metrics related to the planning, development, review, testing and production release of their software process. Now in 12.9, GitLab users have more control over the measures used to reflect their process. For each lifecycle stage, team leads may define trigger events which define when an issue or MR is considered to have entered or exited the stage. With this new flexibility, teams will be able to reflect their own processes in GitLab with higher fidelity and make decisions about where to focus improvement activities on the basis of their team's historical data.
[Additional audit events](https://docs.gitlab.com/ee/administration/audit_events.html):
> Compliance-minded organizations need visibility into the actions of their users. This can help identify anomalous activity, mitigate risks, take action on certain behaviors, and document activity for regulatory compliance. We're continuing our work on the [Audit Events](https://about.gitlab.com/direction/govern/compliance/audit-events/) category, striving to capture 100% of user-driven events, to support the organizations relying on GitLab for auditability and traceability of their GitLab user activity.
>
> GitLab 12.9 now provides audit events for the following changes made to merge request approval settings: prevent approval of merge requests by merge request author, prevent approval of merge requests by merge request committers, and number of required approvals. These events are visible under the project-level and instance-level audit events tables.
Audit Events[Seat Link](https://docs.gitlab.com/ee/subscriptions/#seat-link) (self-managed only):
> Customers with self-managed instances should have a simple and stress-free process for adding and paying for users as they grow. Seat Link is our first step towards providing self-managed customers with more transparent, prorated charges for user growth throughout the year. Seat Link will enable GitLab to automatically charge a prorated amount each quarter for added users.
>
> So how does it work? Seat Link sends to GitLab daily a count of all users in connected, self-managed instances, so we can automate prorated reconciliations and you never have to deal with true-ups again. Data will be sent securely through an encrypted connection.
>
> Seat Link will send only the following information needed to automate prorated charges:
>
> * Date
> * Historical maximum user count
> * Active user count
> * License key
>
> For air-gapped or closed network customers, we’ll continue with the existing true-up model. Seat Link is available in 12.9, but we will not start processing prorated charges until a future date, with a tentative target of 12.10.
>
> For more details, see [the recent blog post](https://about.gitlab.com/blog/2020/03/16/how-were-improving-self-managed-billing/).
Collection[Fixes for Geo database timeouts when finding unsynced Git LFS objects](https://docs.gitlab.com/ee/administration/geo/index.html) (self-managed only):
> Geo compares the tracking database to the read-only secondary database to determine what needs to be synced. The existing design has been iterated on and optimized, and we [keep improving it further](https://gitlab.com/gitlab-org/gitlab/issues/10286). If Geo's database queries time out, data can't be replicated successfully.
> In GitLab 12.9, we use a new approach to sync [Git LFS](https://docs.gitlab.com/ee/topics/git/lfs/index.html) files which eliminates the possibility of database statement timeouts. This design will be rolled out to other data types after we have validated the solution.
>
> In addition, this sets the stage to allow Geo to remove its dependency on [Foreign Data Wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers), which was added for improved performance, but makes Geo more complex and harder to maintain.
Geo-replication, Disaster Recovery[View epic progress by weight completed on your roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/):
> Knowing the status of work in flight is critical. Our Roadmap now helps you visualize progress by displaying the percentage of weight completed via a progress bar on displayed epics. Keep up to date with your critical projects and efforts with ease!
Roadmaps, Epics[View history of changes to issue, merge request and epic descriptions](https://docs.gitlab.com/ee/user/discussions/index.html#view-description-change-history):
> The descriptions of issues, merge requests, and epics can be freely
> edited as they naturally evolve. In the past, changes were not recorded
> and the history of these descriptions was lost. Not any more! GitLab now
> stores these updates, and allows you to view what changes were made,
> who made them, and when!
Issue Tracking, Epics[High Availability for Gitaly (alpha)](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) (self-managed only):
> For many customers, GitLab is a business critical application because an
> outage would prevent developers from being productive, and obstruct the
> deployment of new features and fixes. To prevent outages, GitLab can be
> run in a [highly available
> (HA)](https://docs.gitlab.com/ee/administration/reference_architectures/index.html)
> configuration. The currently documented HA configuration recommends using
> NFS. However, NFS significantly increases the latency of read and write
> operations, which severely impacts the performance of Git operations,
> particularly as the size of the repository grows.
>
> Gitaly now offers experimental alpha support for high availability without
> using NFS. **This feature should not be used in production!** There are
> single points of failure, and unexpected data loss may occur. However, you
> may wish to start evaluating high availability for Gitaly in a test
> environment. Since January, we have successfully been testing on
> GitLab.com with a small number of projects.
>
> High Availability for Gitaly is eventually consistent, implemented as an
> asynchronous replication queue, favoring availability over consistency. If
> an outage occurs on a primary Gitaly node before the replication queue has
> been drained, data loss will occur. In parallel we have begun
> investigating [strong
> consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) to prevent
> such data loss scenarios.
Gitaly[Reduce email notifications for eligible approvers](https://docs.gitlab.com/ee/user/profile/notifications.html#notifications-on-issues-merge-requests-and-epics):
> Email notifications allow you to keep up with issues and merge requests you're interested in from your inbox. GitLab provides various levels of notifications, including **Participate**, which notifies you of activity after you've participated in the merge request or issue. However, people who have been configured as eligible Merge Request Approvers, would receive notifications for all activity on every merge request for which they are an eligible approver. This made the number of email notifications overwhelming for all but the smallest projects.
>
> From GitLab 12.9, eligible approvers are no longer treated as participants until they leave comments, or approve the merge request. This will reduce the volume of emails being sent to eligible approvers, so they can focus on the notifications that matter. If you want to receive more emails, the **Watch** setting will notify you of any activity on the project.
Code Review[Special markdown rendering for Design URLs](https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references):
> Sharing a link to the Design tab is an important part of collaboration and how users can surface Designs in comments or descriptions. Currently, when sharing a link to the Design tab in markdown, the link is long and unruly: `https://gitlab.com/gitlab-org/gitlab/-/issues/12345/designs`.
>
> With this release, GitLab renders these links in a readable way so it's easy to distinguish Designs in issue descriptions or comments: `#12345 (designs)`. Now it's easier for collaborators to spot when a user is referring to Designs rather than just linking out to an issue.
Design Management[Drag-and-drop support for uploading Designs](https://docs.gitlab.com/ee/user/project/issues/design_management.html#adding-designs):
> Up until this release, the only way to upload Designs to GitLab was to click and use the file uploader. This worked but is not as efficient as using drag-and-drop. With this release you can now do the following in the Designs tab:
>
> - Upload a new Design by dragging a new file and dropping into the dropzone.
> - Upload a new version of an existing Design by dragging a new file with the same name and dropping into the existing Design.
Design Management[Zooming Designs now supports full width for long images](https://docs.gitlab.com/ee/user/project/issues/design_management.html#exploring-designs-by-zooming):
> When a website layout is uploaded as a Design on an issue, they are often quite tall in size. This aspect ratio is frequently used for website layouts where there is a lot of content and the user has to scroll down. With this release, you will now be able to zoom in on longer designs so you can more easily see and comment on the Design at 100% width.
Design Management[Full Code Quality Report](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-reports):
> Users are already making great use of the [code quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html) feature in Merge Requests to prevent code quality from slipping after making a single change, but this may not give enough insight into other issues within the project. Contributors now gain visibility into other code quality issues in order to resolve them in the current Merge Request or in a future change.
>
> To better enable users to write high quality code, the full Code Quality report output is now available in the CI/CD pipelines and as a downloadable artifact. This change allows developers even more visibility into any code quality issues in their project within the GitLab UI.
Code Quality[List Changed Pages in the Visual Review widget](https://docs.gitlab.com/ee/ci/review_apps/#configuring-visual-reviews):
> It can be difficult to navigate to a changed page in a Review App, especially in a statically generated site. [Review Apps](https://about.gitlab.com/stages-devops-lifecycle/review-apps/) and [Visual Reviews](https://docs.gitlab.com/ee/ci/review_apps/index.html#visual-reviews) make it easy to leave comments directly in a Merge Request while looking at the modified page. That is, once you find it.
>
> Starting in GitLab 12.9, users of Visual Review tools will be able to use a drop down list to navigate directly to the page(s) modified in a Merge Request, making it easier to find the changed page(s) and provide feedback on a Merge Request.
Usability Testing[Use npmjs.org as a default remote repository when the package is not found in the GitLab NPM Registry](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#package-registry-configuration):
> The GitLab NPM Registry allows users to host a private NPM registry alongside their source code and pipelines. This works best if the GitLab NPM Registry is the only source of packages with the GitLab `group_name` scope. However, it's common that users also publish open source packages to the global NPM registry using the same scope, often when their private packages depend on those public packages.
>
> In GitLab 12.9, we are excited to announce that you can now use Package Registry[HashiCorp Vault GitLab CI/CD Managed Application](https://docs.gitlab.com/ee/user/clusters/applications.html#install-vault-using-gitlab-cicd):
> GitLab wants to make it easy for users to have modern secrets management. We are now offering users the ability to install Vault within a Kubernetes cluster as part of the GitLab CI managed application process. This will support the secure management of keys, tokens, and other secrets at the project level in a Helm chart installation.
Secrets Management[Group Deploy Tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/#group-deploy-token):
> GitLab already supports project-level deploy tokens. Now, we've added support for deploy tokens at the group level to make it easier to configure groups of projects.
> This will make sharing secrets between projects much more convenient and help in use cases such as: users deploying many projects to one Kubernetes cluster where different secrets need to be created per project.
> Creating a group level token allows users to set **one** shared secret for the entire cluster.
Continuous Delivery[Release Progress View](https://docs.gitlab.com/ee/user/project/releases/):
> GitLab Releases are a one stop place for all the contents of a release. With the new Release Progress View introduced in GitLab 12.9, you will be able to easily answer the questions many release and build managers are spending time manually collecting. In a single look on the Release page, you can see the number of open, closed, and in-progress public issues that are associated with the milestones of the Release. A convenient percentage progress bar will also give you a quick update on how your release is progressing.
Release Orchestration, Release Evidence[GitLab CI/CD template for deploying to ECS](https://docs.gitlab.com/ee/ci/cloud_deployment/#deploy-your-application-to-aws-elastic-container-service-ecs):
> Many users want to deploy to AWS using GitLab CI/CD. In order to help deploy to Elastic Container Service (ECS), we have created a template that shows you how to get started.
>
> 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.
Continuous Delivery[Skip outdated deployment jobs](https://docs.gitlab.com/ee/ci/pipelines/settings.html#skip-outdated-deployment-jobs):
> Before GitLab 12.9, users trying to roll out a pipeline could encounter a situation where an older and delayed pipeline would deploy after a newer deployment and override it. Now, forward deployments provide the option to ensure that when a pipeline runs, it is verified to be the most recent deployment and makes sure that an older pipeline doesn't override a newer one.
Continuous Delivery, Incremental Rollout[Dynamic environments support for Review Apps](https://docs.gitlab.com/ee/ci/environments/index.html#set-dynamic-environment-urls-after-a-job-finishes):
> Review apps currently require a static URL to be used as the CI/CD variable `CI_ENVIRONMENT_SLUG`. In many use cases, though, this environment variable is dynamic instead of static. For example, when using AWS, a user may want to use the environment name based on the stage, which may not be known before the deployment.
>
> In 12.9, we've introduced a new report artifact, `dotenv`. The artifact can be passed between jobs, providing truly dynamic URL support for Review Apps. This unlocks the ability to use Review Apps in dynamic environments, such as native cloud deployments.
Review Apps[Install Crossplane application using GitLab CI/CD](https://docs.gitlab.com/ee/user/clusters/applications.html#install-crossplane-using-gitlab-cicd):
> Installing Kubernetes applications [using GitLab
> CI/CD](https://docs.gitlab.com/ee/user/clusters/applications.html#install-using-gitlab-ci-alpha)
> provides a great way to customize GitLab Managed Applications prior to installation.
> As part of this release, we have added a template for installing
> [Crossplane](https://docs.gitlab.com/ee/user/clusters/applications.html#install-crossplane-using-gitlab-ci)
> using GitLab CI/CD. Installing the Crossplane chart via GitLab CI/CD allows users to specify any and all [Crossplane chart configuration](https://crossplane.io/docs/v0.1/install-crossplane.html#configuration) options.
Kubernetes Management[Create a Release from the UI](https://docs.gitlab.com/ee/user/project/releases/#create-a-release):
> GitLab now offers users the ability to create Releases from the UI. Users are a click away from creating a tag that contains all the contents of your Release version, including Release notes, milestone associations, and links added from the API stored as assets. This addition will make things easier for release managers who are planning releases for teams straight from the Releases page, rather than going to the **Tags** view.
Release Orchestration[Deploy keys and Deploy tokens move to CI/CD settings](https://docs.gitlab.com/ee/user/project/deploy_tokens/):
> Deploy keys and Deploy tokens have found a new home under **Settings > CI/CD**. They were previously found under **Settings > Repository** and were more difficult for users to find.
> Since both are used for CI/CD purposes, we consolidated all settings into this location.
Continuous Delivery[Track cherry-picked commits from Merge Request](https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html#cherry-pick-tracking):
> It is important to track everything that gets delivered to production. We now record when a merge commit is cherry-picked into a branch that gets deployed (when done either through the UI or through the API). The original merge request thread is updated with a system note indicating that the merge commit was cherry-picked into the deployed branch, and it is also included in the list of deployed merge requests.
Continuous Delivery[Project-level code search now reliably responsive](https://docs.gitlab.com/ee/api/search.html#scope-blobs):
> Searching within a project for code is now reliably responsive, with most queries completing in under 250ms. In previous versions of GitLab, when [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html) was disabled, queries which generated a high number of results could see latencies of 10 seconds or more. This represents approximately a ten-fold improvement, improving the search experience for users.
>
> This improvement affects both the GitLab UI as well as [project blob search API](https://docs.gitlab.com/ee/api/search.html#scope-blobs).
Global Search[Reduced memory consumption of GitLab with Puma](https://docs.gitlab.com/omnibus/settings/puma.html) (self-managed only):
> GitLab is switching application servers from [Unicorn](https://en.wikipedia.org/wiki/Unicorn_(web_server)) to [Puma](https://puma.io), reducing the memory footprint of GitLab by 40%. This improved efficiency can allow GitLab administrators to leverage smaller memory instances, reducing the operational costs of the service. These savings are achieved due to leveraging the multi-threading support in Puma, compared to the single-threaded model of Unicorn.
>
> Puma support is [generally available](https://docs.gitlab.com/omnibus/settings/puma.html) in Omnibus, and [experimental](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html#webserver-options) in the Helm chart. We plan to make Puma the [default application server](#puma-will-become-the-default-application-server) in GitLab 13.0.
Omnibus Package[GitLab chart improvements](https://docs.gitlab.com/charts/charts/globals.html#bootsnap-cache) (self-managed only):
> - Bootsnap is now enabled in the Rails containers (Task Runner, Unicorn, and Sidekiq). Bootsnap optimizes and caches computations to speed up the boot time of Rails applications. We're [seeing boot times reduced by approximately 14%](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/1157#note_283766138) in this iteration, and expect another significant gain in the future. You can read more about Bootsnap in [its GitHub repository](https://github.com/Shopify/bootsnap).
> - Puma is now available in the GitLab Helm chart (Unicorn sub chart) [as an alternative application server to Unicorn](https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/#reduced-memory-consumption-of-gitlab-with-puma). Puma offers approximately [40% reduced memory consumption](https://gitlab.com/gitlab-com/gl-infra/production/issues/1684#note_291225063) compared to Unicorn, for similar performance. Support for Puma in the Helm install is experimental in 12.9, but it is planned to be the default application server by GitLab 13.0. For more information, see the [Helm chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html). A huge thanks to [Dmitry Chepurovskiy](https://gitlab.com/dm3ch) for playing a key role in making this happen.
Cloud Native Installation[Group Export and Import is available using the API](https://docs.gitlab.com/ee/api/group_import_export.html):
> Migrations between GitLab instances can be challenging, especially from self-managed GitLab to GitLab.com, because organizations can have their work organized in many Projects and Groups. Until now, these migrations had to be done by exporting and importing one Project at a time.
>
> With the release of the Group Export/Import [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc), users can export an entire Group and easily import it into the desired instance of GitLab, whether their destination is GitLab.com or another self-managed GitLab instance.
Importers[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - Upgrading PostgreSQL on Geo secondaries just got easier. `pg-upgrade` [now supports upgrading PostgreSQL on Geo tracking database nodes](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance). Previously, upgrading the Geo tracking database required the `postgresql['enable']` setting to be temporarily set to `true` in the`gitlab.rb` file. Now, simply run the `pg-upgrade` command on the tracking database node.
> - It is now possible to provide a default statement timeout when using an external PostgreSQL database. Previously this could only be set when using the bundled PostgreSQL database. The statement timeout is used to automatically kill queries that run for longer than the specified time. For details on configuring the timeout, see [the database settings page](https://docs.gitlab.com/omnibus/settings/database.html#application-settings-for-the-database)
> - GitLab 12.9 includes [Mattermost 5.20](https://mattermost.com/blog/mattermost-5-20-new-mobile-editor-desktop-dark-theme/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes a new mobile editor, desktop dark theme, and much more. This version also includes [security updates](https://mattermost.com/security-updates/). Upgrading from earlier versions is recommended.
>
> We detected an issue where some additional changes need to be made to the configuration of the Geo tracking database after running `pg-upgrade`. [A fix is planned for 12.10](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5242). For 12.9, we recommend using the old method of changing the `gitlab.rb` file.
> {: .alert .alert-info}
Omnibus Package[Performance improvements](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.9)
> We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/gitlab-the-product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
>
> In GitLab 12.9 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.9 are:
>
> - [Ensure RepositoryLinkFilter handles Gitaly failures gracefully](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26531)
> - [Search issues in GraphQl by milestone and assignees](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25794)
> - [Bulk lazy loader for epic aggregates](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23406)
> - [Fix N+1 in Group milestone view](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26051)
> - [Set upper limit on bulk API request size for Elasticsearch indexing](https://gitlab.com/gitlab-org/gitlab/-/issues/201805)
> - [Project-level code search now 10x faster when there is a large number of results](https://gitlab.com/gitlab-org/gitlab/-/issues/33562)
> - [Buffer Writes to ElasticSearch and use the Bulk API](https://gitlab.com/gitlab-org/gitlab/issues/34086)
> - [Batch load records from the database for Elasticsearch incremental bulk updates](https://gitlab.com/gitlab-org/gitlab/-/issues/207280)
> - [Request Inline or Parallel diffs instead of fetching all data from the backend in one request](https://gitlab.com/gitlab-org/gitlab/issues/33183)
> - [Introduce `BulkInsertSafe` mixin for safe bulk-inserts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24168)
> - [Bulk insert for Import with 14-19% reduction in time](https://gitlab.com/gitlab-org/gitlab/issues/196844#note_305381280)
> - [Streaming serializer on Export with constant memory consumption](https://gitlab.com/gitlab-org/gitlab/-/issues/208803)
[Enable Git protocol v2 for SSH](https://docs.gitlab.com/ee/administration/git_protocol.html):
> We've re-enabled support for Git protocol v2 over SSH. In the previous release, GitLab 12.8, we re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.
>
> Developers fetch refs many times a day to check if the current branch is behind the remote branch. Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. `git fetch origin master`) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data. Now, only the needed refs are transferred.
>
> Git protocol v2 is a major update to Git's [wire protocol](https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html) which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.
>
> Git protocol v2 is enabled by default from Git 2.26, and available from Git 2.18 by running `git config --global protocol.version 2`.
Gitaly[HTTP push mirroring API](https://docs.gitlab.com/ee/api/remote_mirrors.html):
> Push mirroring allows you to automatically push updates from your Git repository to copies stored elsewhere. Mirroring is easily configured from the project settings, but if it needs to be configured for hundreds of projects this is impractical. The new Remote Mirrors API solves this by allowing push mirroring over HTTP to be configured using the API.
>
> Thank you [Rajendra Kadam](https://gitlab.com/raju249) for your [contribution](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25825)!
Source Code Management[Commit all changes in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#commit-changes):
> In GitLab 12.7 we began [automatically staging all changes](/releases/2020/01/22/gitlab-12-7-released/#automatically-stage-all-changes-in-web-ide) in the Web IDE as a step towards better accessibility by more personas. This measure also helped to prevent accidental loss if all changes weren't properly staged prior to leaving the Web IDE.
>
> This was an important change in Web IDE workflows and now, we've made this even easier by removing the staging workflow completely from the Web IDE. Now when a user makes a change in the Web IDE they won't need to decide to stage or unstage their changes for their commit. They'll see a new **Changes** tab that has a list of all changed files. This is a valuable step in making git and GitLab more accessible to users in the Web IDE.
Web IDE[GitLab hosted CodeSandbox for Client-Side Live Preview](https://docs.gitlab.com/ee/user/project/web_ide/#live-preview):
> In [GitLab 11.2 we released](/releases/2018/08/22/gitlab-11-2-released/#client-side-evaluation-in-web-ide) live preview powered by [CodeSandbox](https://codesandbox.io/) to allow you to preview simple Javascript apps and static sites in the Web IDE. This feature depends on scripts hosted by CodeSandbox, but due to security concerns around sending private code to a third party, some customers were not comfortable using this feature.
>
> GitLab.com is now hosting the required package to enable live preview in the Web IDE. This is the first step in enabling this feature across self-managed instances of GitLab. In a future release, we'll provide a [configuration option](https://gitlab.com/gitlab-org/gitlab/-/issues/208161) for self-managed instances to host the required libraries themselves, and we'll also look into enabling it by default for all GitLab instances.
Web IDE[White syntax highlighting theme for Web IDE](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme):
> Users have strong preferences for consistency in the tools they use which is why GitLab has long supported alternative syntax highlighting themes. The white theme is the most popular across GitLab, however, our code editor areas have been inconsistent in applying a matching theme.
>
> The Web IDE is now consistent with the **White** syntax highlighting preference in the repository and diff areas of GitLab. We'll continue to [expand our support](https://gitlab.com/groups/gitlab-org/-/epics/2389) for syntax highlighting preferences in the Web IDE. We're also continuing to extend the [dark theme, introduced in GitLab 12.8,](/releases/2020/02/22/gitlab-12-8-released/#dark-syntax-highlighting-theme-for-web-ide) to the [rest of the Web IDE](https://gitlab.com/gitlab-org/gitlab/issues/199664), including the file tree and sidebars.
Web IDE[Dynamic child pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html#dynamic-child-pipelines):
> Beginning with this release, child pipelines can now be started using a dynamically
> generated `.gitlab-ci.yml`. Using this approach, you can generate child
> pipelines that reflect runtime analysis of what's changed or other criteria (for example, to
> build a matrix of targets and architectures).
>
> This addition will open up a whole new set of use cases for this feature,
> while helping keep configuration simple. We can't wait to see what
> you build with it!
Continuous Integration (CI)[Disable inheritance of defaults and variables](https://docs.gitlab.com/ee/ci/yaml/#inherit):
> Previously, users had the ability to set certain parameters as global defaults for all of their jobs by using the `default:` keyword. However, disabling these defaults for a particular job required manually overwriting each setting and was inefficient. Additionally, it wasn't possible to prevent the inheritance of variables once they were defined as global defaults.
>
> In GitLab 12.9, we've now added the ability to disable the inheritance of globally defined defaults and variables. Using the `inherit:` parameter, users can explicitly define what is inherited from the global defaults and more easily define a job's behavior.
Continuous Integration (CI)[GitLab Runner 12.9](https://docs.gitlab.com/runner):
> We're releasing GitLab Runner 12.9 today! GitLab Runner is the lightweight cross-platform agent that runs your build jobs and sends the results back to a GitLab instance. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab.
>
> #### Changes include:
>
> - [Create network per build to link containers together](https://gitlab.com/gitlab-org/gitlab-runner/issues/1042)
> - [Fix Job marked as success when job terminates midway in Kubernetes](https://gitlab.com/gitlab-org/gitlab-runner/issues/4119)
> - [Fix Error dialing backend:EOF Google Kubernetes Engine](https://gitlab.com/gitlab-org/gitlab-runner/issues/3247)
> - [Allow service alias from config in Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/issues/4829)
> - [Add support for Windows services with network per build](https://gitlab.com/gitlab-org/gitlab-runner/issues/4186)
> - [Provide rpm/deb package for arm64](https://gitlab.com/gitlab-org/gitlab-runner/issues/4872)
> - [Add CI_JOB_IMAGE to predefined environment variables](https://gitlab.com/gitlab-org/gitlab-runner/issues/4888)
> - [Support EKS IAM Service Accounts (Web identity Providers](https://gitlab.com/gitlab-org/gitlab-runner/issues/4874)
> - [Support ECS Task IAM Role for S3 based cache](https://gitlab.com/gitlab-org/gitlab-runner/issues/3603)
> - [Introduced Windows Lifecycle Policy](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6623)
> - [Add Fedora 30 to supported operating systems](https://gitlab.com/gitlab-org/gitlab-runner/issues/4401)
> - [Add execution stage name in job trace](https://gitlab.com/gitlab-org/gitlab-runner/issues/4816)
> - [Overwrite kubernetes resource limits and requests for build container on job level](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/874)
>
> The list of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/12-9-stable/CHANGELOG.md).
Continuous Integration (CI)[Use the GitLab API for creating and revoking project and group deploy tokens](https://docs.gitlab.com/ee/api/deploy_tokens.html):
> Deploy tokens allow users to fetch a project repository (through SSH with `git clone`) or to fetch the Container Registry images of a project without providing a username and a password. This enables users to create a single token for their project and avoid using personal access tokens. However, for organizations with many groups, sub-groups, and projects, it is inefficient and difficult to create deploy tokens for each project. Maintainers or administrators need a way to easily create and revoke deploy tokens for many groups and projects.
>
> In GitLab 12.9, we are excited to announce that we have extended the Gitlab API to allow users to create, list, and revoke GitLab Deploy Tokens at the group/sub-group/project level. This will make the process of creating and managing deploy tokens much easier and safer.
Package Registry[Specify Docker images that should not be deleted as part of the Container Registry bulk delete API](https://docs.gitlab.com/ee/api/container_registry.html#delete-registry-repository-tags-in-bulk):
> For organizations with many groups and projects, it is more efficient to remove old, unused, Docker images by utilizing the bulk tag deletion API. However, there's currently no easy way to express something such as "no matter what, don't delete this tag." This introduces risk into the deletion process since it's possible to delete `release` or `master` images.
>
> In 12.9, we are excited to announce that you can add the `name_regex_keep` attribute to the bulk delete API in order to prevent any tags that match the provided regex from being deleted. Now, you have an easier way to prevent your important images from ever being deleted!
Container Registry[Improved performance for the GitLab Container Registry garbage collection algorithm for Google Cloud Storage (GCS)](https://docs.gitlab.com/ee/administration/packages/container_registry.html#container-registry-garbage-collection):
> Our users have expressed frustration about the long downtime that is needed to run garbage collection on old, unused images, and we've heard you. The improvements we've made to the efficiency of the cleanup code means you don't have to make a tradeoff between two bad options: taking a long outage, or keeping around lots of unneeded files.
>
> In GitLab 12.9, we are excited to announce a significant improvement in the performance of garbage collection for instances using the GitLab Container Registry and leveraging GCS for storage. While testing with a 1.4GiB repository, which is a rough approximation of the 10 TiB registry used on dev.gitlab.org, we [observed a performance improvement of 95%](https://gitlab.com/gitlab-org/gitlab/-/issues/201956#note_304641053).
Container Registry[Web Application Firewall (WAF) Controls](https://docs.gitlab.com/ee/user/clusters/applications.html#web-application-firewall-modsecurity):
> We're pleased to announce new controls to manage your Web Application Firewall (WAF)! You can now
> easily turn your WAF on or off globally on your project's **Operations -> Kubernetes** page.
WAF[Support pagination in log explorer](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html#full-text-search):
> Previously, the Log explorer would show only 500 lines on the console - limiting a user's ability to view logs when triaging an incident. With the support for pagination, users can select any time frame they like and scroll infinitely to view an unlimited amount of log lines.
Logging[View all pod logs from a single page](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html#logs-view):
> In a cloud-native world, logs are distributed across multiple pods. Previously, users would have to select each pod separately to view its logs, which can be challenging as pods can scale up significantly. In 12.9, we have added the ability to select "all pods" to help users troubleshoot incidents or verify the status of their services in a single view, instead of choosing each pod separately.
Logging[Drill down from incident to log explorer](https://docs.gitlab.com/ee/operations/incident_management/index.html#view-logs-ultimate):
> Previously, users struggled to find relevant logs when troubleshooting incidents. Starting with 12.9, users can drill directly down from the incident to the log explorer while preserving the same timeframe, simplifying investigation of the incident and finding the root cause.
Metrics[Log aggregation in Core](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html):
> As a part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we've decided to move the log aggregation capabilities in the monitor stage from GitLab Ultimate to GitLab Core. This means that starting with GitLab 12.9, all users will be able to view their Kubernetes based application logs within the GitLab UI.
Logging[Support additional query variables in custom dashboards](https://docs.gitlab.com/ee/operations/metrics/dashboards/variables.html#query-variables):
> Custom dashboards can be created and configured using Prometheus queries. To allow users to create dashboard definitions that can be used across different projects, we have extended support to include additional [CI variables](https://docs.gitlab.com/ee/ci/variables/) in Prometheus queries.
Metrics[Automatically embed metrics in issue for all gitlab-configured alerts](https://docs.gitlab.com/ee/operations/incident_management/index.html#auto-creation):
> GitLab Incident Management can create issues automatically when the Prometheus alert is triggered. Metrics charts help to visualize what anomaly caused the alert. Previously, charts could be embedded into the issue description, but this required manually grabbing the chart URL and pasting it into the issue.
>
> Now, as of 12.9, a chart visualization for the metric that exceeded the threshold is automatically embedded in the issue description. This visualization saves you time in a firefight. You get critical information right away, without needing to go to an external source and perform a manual setup.
>
> Note: This new capability will only work for alerts configured from the Metrics Dashboard within GitLab. In a future iteration, we plan to [enable automatic charts for all Prometheus alerts](https://gitlab.com/gitlab-org/gitlab/issues/195739) regardless of how they are set up.
Error Tracking[Edit custom metrics from charts](https://docs.gitlab.com/ee/operations/metrics/index.html#editing-additional-metrics-from-the-dashboard):
> With the 12.9 release, we are improving the user experience to edit a custom metric directly in the metric chart rather than navigating to the Prometheus settings to edit the metric.
Metrics[Filter error list by status](https://docs.gitlab.com/ee/operations/error_tracking.html#error-tracking-list):
> Digging through a large list of errors to find the important ones that are impacting users can be a challenge when there is a low signal to noise ratio. You can now filter the list view of Sentry errors in GitLab by error status (ignored, resolved, or unresolved) to remove the cruft and focus on the problems you actually need to fix.
Error Tracking[Formatting of y axis in metric charts](https://docs.gitlab.com/ee/operations/metrics/dashboards/yaml_number_format.html):
> To improve visualization of the units on the y-axis and surface accurate data, we have introduced support for formatting the y-axis on the metrics chart.
Metrics