GitLab.org/GitLab: Release v12.10.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.10
Released: 2020-04-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Compliance framework labels for projects](https://docs.gitlab.com/ee/user/project/settings/#compliance-framework-ultimate):
> Organizations using GitLab have company policies and industry regulations that dictate how they operate. A top-of-mind goal for many of our customers is ensuring their GitLab projects are adhering to internal company policies, which are influenced by industry regulations. Previously, there was no easy way to identify a project as one that has certain compliance requirements or additional oversight, which is a fundamental need to tracking compliance status.
>
> Now you can label projects with specific compliance frameworks by navigating to a project's `Settings` area and, in the `General` section, choosing from the `Compliance framework` dropdown menu. This feature lays a foundation to ease project compliance management in the future.
Compliance Management[New HIPAA audit protocol project template](https://docs.gitlab.com/ee/user/project/working_with_projects.html#enterprise-templates):
> With GitLab, you can automate highly repeatable HIPAA Audit Protocol workflows. GitLab can help simplify these workflows natively by leveraging [issues](https://docs.gitlab.com/ee/user/project/issues/) and [project templates](https://docs.gitlab.com/ee/user/project/working_with_projects.html#project-templates). This process can help map new issues to each requirement in the HIPAA audit protocol. It can also help your organization manage audit evidence collection and overall status within your GitLab workflow.
>
> GitLab now supports the HIPAA audit protocol, through the new enterprise compliance template. To aid in HIPAA compliance, GitLab can help you create new projects, each with the 180 issues that map to the HIPAA audit protocol. Each issue serves as an audit trail for each HIPAA protocol and can help teams stay connected as they manage their HIPAA compliance programs within GitLab.
Compliance Management[Compliance dashboard shows pipeline result for the most recent, merged MR](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/):
> When an administrator or group owner assesses compliance of their GitLab projects, they need to know the status of pipelines for the code being deployed. Pipelines can contain stages or jobs that determine compliance with organizational policy. Until now, administrators or group owners had to investigate every project to validate each pipeline.
>
> The [Compliance Dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/) now includes the most recent pipeline status for all projects in a group. Administrators and group owners can now identify potential compliance issues with approved and merged MRs at a glance.
Compliance Management[Extend Access Token lifetime in GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/#limiting-lifetime-of-personal-access-tokens-of-users-in-group-managed-accounts-ultimate):
> Starting 12.10, GitLab.com customers can also [limit the lifetime of personal access tokens](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limiting-lifetime-of-personal-access-tokens) in [group-managed accounts](https://docs.gitlab.com/ee/user/group/saml_sso/#group-managed-accounts), similar to self-managed instances of GitLab.
>
> In the **General** section of your group's settings, you can specify a lifetime duration for personal access tokens created by members of a group-managed account. This policy will only apply to users of that group.
Compliance Management[Create and view requirements in GitLab](https://docs.gitlab.com/ee/user/project/requirements/index.html):
> The first step towards managing requirements from within GitLab is
> here! This initial release allows users to create and view
> requirements at a project level.
>
> We often hear about the struggles associated with external requirement
> management tools - difficult integrations, multiple toolchains, and
> challenging workflows. We believe in the power of a single application, by
> offering an opportunity to keep all requirements, designs, code, and
> tests in a single environment. As Requirements Management evolves in GitLab, stay tuned for support for
> traceability between all
> artifacts, creating a seamless workflow to visually demonstrate completeness and compliance.
>
> For more information and to collaborate with us on the amazing
> Requirements Management system, see [Requirements Management
> Category Direction](/direction/plan/).
Requirements Management[Disable individual rules in DAST](https://docs.gitlab.com/ee/user/application_security/dast/#customizing-the-dast-settings):
> As a black-box tool, a DAST scan doesn't know anything about the underlying site or application architecture. This can lead to false positives that the user immediately knows aren't exploitable vulnerabilities. An example of this is the DAST scan reporting a possible SQL injection vulnerability when there's no SQL database in the application architecture.
> Because of this problem, GitLab 12.10 supports toggling specific rules on and off using the `DAST_EXCLUDE_RULES` variable. This allows using a comma-separated list of Vulnerability Rule IDs to be excluded from scans. When using this variable to exclude specific rules, it's possible to better tailor a scan to the targeted app to get fewer false positives.
DAST[Provide severity levels for dependency scanning vulnerabilities](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/):
> All Dependency Scanning analyzers now support reporting severity levels, making findings more easily assessed for risk and priority. Previously, not all languages were supported by findings with severities leaving some severities set to `Unknown`, making it difficult to prioritize their remediation.
Dependency Scanning[Enhanced Secure workflows for use in offline environments](https://docs.gitlab.com/ee/user/application_security/offline_deployments/):
> GitLab Secure scanners need internet connectivity to download updates
> and the latest signatures. GitLab 12.10 makes it substantially easier
> to use these scanners when running self-managed GitLab instances offline
> or with limited connectivity. Several adjustments to the underlying
> scanner job definitions support this workflow.
>
> New documentation for [offline environments](https://docs.gitlab.com/ee/user/application_security/offline_deployments/)
> describes the high-level workflow needed for Secure scanning in an
> offline environment. We have also added scanner-specific instructions
> on each scanner's documentation page.
>
> We will continue to add support for offline Secure scans in future
> releases, by offering support for additional languages, tools, and use
> cases.
SAST, DAST, Container Scanning, License Compliance[Container Network Policies Statistics Reporting](https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#container-network-policy):
> We're pleased to announce Container Network Policy 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 your Network Policies.
>
> Container Network Policy statistics will appear on a new **Threat Monitoring** page under the
> **Security & Compliance** menu item. By default, this data covers a 30-day period.
Container Network Security[Status Page](https://docs.gitlab.com/ee/operations/incident_management/status_page.html):
> When your service is down or degraded, your top priority is to fix it. At the same time, you must update customers and business stakeholders about the progress of your fixes. Keeping them in the dark can lead to a flood of emails from unhappy people. Users rely on status pages to confirm if providers know about problems and to learn what to do. When there's an active incident, knowing what steps are being taken inspires confidence. It helps people to make choices about what they will do in response to the incident.
>
> Today, the new **GitLab Status Page** is available. Keep users, customers, and stakeholders informed during incidents. Push information from private incidents, like issue descriptions and select comments, from a private incident issue to a public web page. Work directly from the incident issue you are already using for triage and firefighting, instead of bouncing between a lot of different tools.
>
> To begin with, we are targeting one narrow use case. We designed Status Page to publish information from issues in a dedicated incident management project on a private GitLab instance out to public status detail pages. Visit the [Status Page Direction](/direction/service_management/status_page/) to see our plans to add capabilities and support more use cases.
Status Page[Compare Release Evidence over time](https://docs.gitlab.com/ee/user/project/releases/#release-evidence):
> In 12.6, GitLab introduced a streamlined approach to collect all the necessary information to support compliance and audit efforts within the Release object. With this new feature, an evidence collection timestamp will appear alongside a link to download the evidence hash. This enables auditors to easily compare Release Evidence over time, rather than requiring a script to collect and compare each piece of evidence.
Release Evidence[Group-level activity overview MVC](https://docs.gitlab.com/ee/user/group/#group-activity-analytics-overview):
> Development leaders and GitLab administrators often wish to understand how their teams are using GitLab. In this MVC you'll see three counts on the group landing page: Merge Requests, Issues, and Users added to the group, all over the past 90 days. This feature is being released in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
DevOps Reports[Merge Trains support added to /merge quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html):
> When merge trains are enabled, the `/merge` quick action now automatically adds the merge request to the merge train. In previous releases, using this quick action skipped the merge train altogether and merged requests immediately; this behavior was both unexpected and confusing.
Merge Trains[Geo improvements to the administrator interface](https://docs.gitlab.com/ee/administration/geo/replication) (self-managed only):
> Systems administrators need to know the overall status of their Geo
> installation. This is especially important if replication errors are
> detected. In GitLab 12.10 we've added several iterative improvements to the Geo administrator interface to make it easier for systems administrators to diagnose issues with Geo and to help them understand what corrective actions they need to take, for example by identifying
> repositories that failed to replicate.
>
> One of the biggest changes is the [addition of a popover](https://gitlab.com/gitlab-org/gitlab/-/issues/36129) that displays a detailed
> breakdown of all synchronized, queued and failed items. Where available,
> there is a link to a details page, which allows systems administrators
> to investigate individual items.
>
> Additionally, we've made a few other user experience improvements to the administrator interface:
>
> - [Enabled live validations in all Geo forms](https://gitlab.com/gitlab-org/gitlab/-/issues/118841)
> - [Updated the Geo health status](https://gitlab.com/gitlab-org/gitlab/-/issues/213214) to make it more visible
> - [Reworked the synchronization status](https://gitlab.com/gitlab-org/gitlab/-/issues/13309) for items we don't replicate
> - [Improved Geo node form errors](https://gitlab.com/gitlab-org/gitlab/-/issues/213363) to provide more details of what went wrong
Geo-replication, Disaster Recovery[Geo redirects HTTP(S) requests for unsynchronized repositories to the primary node](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#git-operations-on-unreplicated-respositories) (self-managed only):
> Geo supports [selective
> synchronization](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization)
> of projects, which allows systems administrators to choose a subset of
> data that is replicated to a secondary Geo node. Until now, users trying
> to access repositories on a secondary node that were not synchronized
> would receive an error that the project was not available. This could be
> because of selective synchronization or because of replication lag. This was
> confusing for users and disturbed their Git workflow.
>
> In GitLab 12.10, any Git requests made via HTTP(S) to an unsynchronized secondary Geo node will be forwarded to the primary node so that users can still access the
> repository. This means that users won't need to know what is or isn't
> replicated - Geo will try to fulfill the request. Support for proxying SSH Git operations will be available in GitLab 13.0.
Geo-replication[Reduction in Advanced Global Search index size by about 50%](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> Previously, scaling Advanced Global Search in GitLab to very large instances has been challenging due to the size of the Elasticsearch index required. This index was made up of search data and configurations, which were only partly utilized.
>
> We've re-evaluated our usage of which content needs to be indexed, and updated the `index_options` for our Advanced Global Search configuration. On GitLab.com we've seen an almost 50% reduction for our production Elasticsearch Index. This change should make it easier to get started with Advanced Global Search and help you save on operational overhead when running Advanced Global Search in GitLab.
Global Search[Design thumbnails](https://docs.gitlab.com/ee/user/project/issues/design_management.html#adding-designs):
> Designs uploaded to Issues can be quite large in file size. Loading these files can take a long time, especially if you have more than one Design in an Issue. With this release, we now automatically generate Design thumbnails and use them to speed up the load time of the Design tab. This will also enable us to improve loading times of Designs in other parts of GitLab as we continue to build out the Design Management feature.
>
> We tested the GitLab homepage [mockup](https://gitlab.com/gitlab-com/www-gitlab-com/uploads/8e5d9f965c05c6963f4fd3bb487458ec/test.png) which is 1222px by 5113px and was 2.6MB. With thumbnail generation, this image comes down to 0.018MB, which is a *~99.9% reduction in size!*
Design Management[High Availability for Gitaly (beta)](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) (self-managed only):
> Access to Git repositories is critical to developers and businesses. If an outage occurs, developers can't push code, and deployments will be blocked. To prevent outages, GitLab can be run in a [highly available (HA)](https://docs.gitlab.com/ee/administration/reference_architectures/index.html) configuration. The recommended approach currently uses [Network File System (NFS)](https://en.wikipedia.org/wiki/Network_File_System), but this adds significant latency to every read and write operation, severely impacting the performance of GitLab.
>
> In GitLab 12.10, Gitaly now offers beta support for high availability without using NFS. While data loss is not likely, **it is not recommended for use in production environments yet.** In this release, the replication queue and leader state have been moved to a PostgreSQL database. Previously, the replication queue and leader state was stored in memory in the Praefect proxy/router. This prevented configurations using multiple Praefect nodes, and could result in data loss if Praefect was restarted before the replication queue was drained.
>
> The first version of High Availability for Gitaly is eventually consistent. It is implemented as an asynchronous replication queue, and favors availability over consistency. If an outage occurs on a primary Gitaly node before the replication queue has been drained, data loss is an expected side effect of automatic failover. Work is already underway on [strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) to prevent such data loss scenarios.
Gitaly[Automatically trigger your project when another is rebuilt](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#trigger-a-pipeline-when-an-upstream-project-is-rebuilt):
> It is now possible to set up a dependency relationship on a project you depend on, such that when the default branch on that project builds successfully, a pipeline on your default branch also triggers. This relationship is set up as a subscription from the project with the dependency, making it easy to set these up even in situations where the project you depend on is managed by another group.
Continuous Integration (CI)[Filter the Package Registry by name](https://docs.gitlab.com/ee/user/packages/#view-packages):
> GitLab's Package Registry enables you to store a myriad of package types in a single, universal, registry. Until recently, the only way to explore your list of packages was to change the sort order. This made it difficult to find a specific package efficiently, especially if you stored many packages within your registry.
>
> We are excited to announce that as of GitLab 12.10, you can now filter by `name` to find your packages quickly.
Package Registry[Use the GitLab API to purge blobs from the Dependency Proxy](https://docs.gitlab.com/ee/api/dependency_proxy.html):
> The GitLab Dependency Proxy allows you to proxy and cache images hosted on DockerHub so they are readily available for use within GitLab CI/CD. However, up until this release, there wasn't a way for you to purge the cache and that resulted in additional storage costs.
>
> This is no longer the case. Now, you can use the GitLab API for purging the cache of your group's Dependency Proxy and lower your total cost of storage.
Dependency Proxy[Build, publish, and share Python packages to the GitLab PyPI Repository](https://docs.gitlab.com/ee/user/packages/pypi_repository/):
> Python developers need a mechanism to create, share, and consume packages that contain compiled code and other content in projects that use these packages. PyPI, an open source project maintained by the Python Packaging Authority, is the standard for how to define, create, host, and consume Python packages.
>
> In GitLab 12.10, we are proud to offer PyPI repositories built directly into GitLab! Developers now have an easier way to publish their projects’ Python packages. By integrating with PyPI, GitLab will provide a centralized location to store and view those packages in the same place as their source code and pipelines.
>
> In March, we announced that the GitLab PyPI Repository and support for other package manager formats will be [moved to open source](https://about.gitlab.com/blog/2020/03/30/new-features-to-core/). You can follow along as we work to make these features more broadly available [in the epic](https://gitlab.com/groups/gitlab-org/-/epics/2867).
Package Registry[Optional SSH key expiration date](https://docs.gitlab.com/ee/ssh/#adding-an-ssh-key-to-your-gitlab-account):
> Compliance-minded organizations need a way to control SSH credential access to their GitLab environment. SSH keys are normally configured without expiration dates. This is problematic for organizations with access management and/or credential management policies, which require an expiration date on all access credentials. With this release, GitLab supports expiration dates for SSH keys that users can set within the GitLab UI.
Compliance Management[Users statistics improved](https://docs.gitlab.com/ee/subscriptions/#users-statistics) (self-managed only):
> The Users statistics page provides administrators with an overview of user accounts by role, also totals of all users, active users, and blocked users. GitLab billing is based on the number of active users. The information on this page helps you manage seat allocation and subscription costs.
Users[Independent ECS task creation](https://docs.gitlab.com/ee/ci/cloud_deployment/#deploy-your-application-to-aws-elastic-container-service-ecs):
> As part of our AWS Cloud Deploy Docker image, we've bundled a script you can leverage in your pipeline to streamline task creation for ECS deployments. This helps you move boilerplate code in deployment jobs and simplifies your CI/CD configuration.
Continuous Delivery[Use GitLab UI to delete an environment](https://docs.gitlab.com/ee/ci/environments/index.html#delete-environments-through-the-ui):
> This feature enables users to easily administer their environments from the GitLab UI rather than API. Expanding the management of environments to the UI saves time and supports users spending their day in the GitLab frontend.
Release Orchestration[GitLab Pages Project Template for Gatsby](https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_new_project_template.html):
> GitLab Pages natively supports the most common Static Site Generators. With GitLab 12.10, you can now make use of the latest technologies for static sites including ReactJS, Webpack, GraphQL, modern ES6+ JavaScript, as well as CSS, with our new Gatsby Project Template.
Pages[Easily clean up unused LFS files](https://docs.gitlab.com/ee/raketasks/cleanup.html#remove-unreferenced-lfs-files-from-filesystem) (self-managed only):
> GitLab supports [managing large binaries in projects via Git
> LFS](https://docs.gitlab.com/ee/topics/git/lfs/index.html),
> such as audio, video, or graphics files. These files can be removed
> from LFS by [rewriting Git history](https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html); however, unreferenced files
> will still use up storage. Until now, the only way to remove these
> unreferenced LFS objects was to delete the entire project, which is not
> an option in many situations. Consequently, users may run up against
> storage limits, and realize that they are using a lot of storage on LFS
> objects they no longer want or need, without a clear path forward.
>
> Fitting for the Spring season, we added two Rake tasks,
> `gitlab:cleanup:orphan_lfs_file_references` and `gitlab:cleanup:orphan_lfs_files`,
> that allow removing LFS files from individual projects.
> The Rake tasks can be run on a project-by-project basis and scheduled
> as needed. Happy Spring cleaning!
Geo-replication[Sidekiq Cluster available in Core](https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html#using-sidekiq-cluster-by-default-experimental) (self-managed only):
> Sidekiq Cluster allows starting additional Sidekiq processes to
> run background jobs, as well as offering convenient options for
> selecting a particular set of job queues to be processed. These options allow for improved management of Sidekiq queues, and continued scaling for large instances.
>
> Previously this feature was only available in the Starter tier and higher. As of GitLab 12.10, it is now available in Core. It will be enabled by default starting in GitLab 13.0.
Omnibus Package, Cloud Native Installation[Highlight code results in Global Search](https://docs.gitlab.com/ee/user/search/):
> Global Search in GitLab has long been able to return code results for searches performed. However, it wasn't clear to users where in the returned results their search query was actually matched. This meant that users had to hunt for this in the results and may have missed important results where the string may have been returned multiple times.
>
> Now, each line that matched the search will be highlighted to provide a better indication of where in the results the search term was matched. This also matches multiple occurrences in the same file to better highlight each line that may be valuable.
>
> Huge thanks to [@terales](https://gitlab.com/terales) for contributing this feature!
Global Search[PostgreSQL 11 is now the default version of PostgreSQL for GitLab Self-Managed](https://docs.gitlab.com/omnibus/settings/database.html) (self-managed only):
> The default version of GitLab-provided PostgreSQL is now PostgreSQL 11. For new installs, and upgrades of existing installations that do not use HA or Geo, PostgreSQL 11 will automatically be used by default. For Geo and HA installs, please see [the 12.10 upgrade notes](#upgrade). In GitLab performance testing using [the 10K user reference architecture](https://docs.gitlab.com/ee/administration/reference_architectures/10k_users.html), we found that PostgreSQL 11 was able to handle 7% more Requests Per Second compared to PostgreSQL 10, and showed 20% less CPU usage for the merge request discussions endpoint. We did not observe performance regressions when moving from PostgreSQL 10 to 11. For a more detailed performance analysis, see [the performance testing issue](https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/389).
>
> Note that PostgreSQL 9.6 and PostgreSQL 10 will no longer be supported as of GitLab 13.0. You will need to upgrade your PostgreSQL version prior to upgrading to 13.0.
>
> If you are using Geo, please keep in mind that major PostgreSQL updates cannot be performed without downtime on the Geo secondary due to the need to resynchronize the database on the secondary cluster. Specific steps for Geo are available in the [Geo upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance). If you are using the Helm install, you will need to manually switch to PostgreSQL for 12.10.
Omnibus Package[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[Switch to plain SQL for GitLab schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/schema.rb) (self-managed only):
> GitLab 12.10 has switched from utilizing `schema.rb` to `structure.sql` for managing the database schema. Switching to plain SQL in `structure.sql` allows GitLab to make use of PostgreSQL-specific commands, like partitioning.
>
> Contributors and administrators may want to be aware of the change, in the event they need to work with migrations. The change to `structure.sql` will be automatically performed, and no action is required.
Database[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - The GPG signing keys for the GitLab PackageCloud repository have expired and have been replaced with new ones. This means existing users who had already configured GitLab package repositories on their machines to be used via apt, yum or zypper, will have to fetch and add the new keys to continue installing or updating packages from the GitLab package repository. For detailed instructions, see [the Package Signatures documentation](https://docs.gitlab.com/omnibus/update/package_signatures). Further details are also available in [Balu's blog post](https://about.gitlab.com/blog/2020/03/30/gpg-key-for-gitlab-package-repositories-metadata-changing/).
> - GitLab 12.10 includes [Mattermost 5.21](https://mattermost.com/blog/mattermost-5-21-chatops-integration-aws-gitlab-codeship/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes ChatOps integration with AWS, GitLab, and CodeShip, and more. This version also includes [security updates](https://mattermost.com/security-updates/) and an upgrade from earlier versions is recommended.
> - Omnibus GitLab now defaults to PostgreSQL 11 for new installs. For upgrades, it defaults to PostgreSQL 11 if HA and Geo are not configured. See [PostgreSQL 11 is now the default version of PostgreSQL for GitLab Self-Managed](#postgresql-11-is-now-the-default-version-of-postgresql-for-gitlab-self-managed) for more details.
Omnibus Package[Performance improvements](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.10)
> 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.10 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.10 are:
>
> - [Milestone pages with large numbers of issues no longer time out](https://gitlab.com/gitlab-org/gitlab/-/issues/39453)
> - [Merge Requests Discussions API no longer degrades with comments count](https://gitlab.com/gitlab-org/gitlab/-/issues/32455)
> - [Issue creation has a customizable rate limit](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28129)
> - [Make Rails.cache and Gitlab::Redis::Cache use the same pool](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28074)
> - [Add issues to GraphQL group endpoint](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27789)
> - [Remove N+1 queries from GraphQL EpicType](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27551)
> - [Export via streaming serializer, introduce Writer abstraction](https://gitlab.com/gitlab-org/gitlab/-/issues/208803)
> - [Cache Elasticsearch enabled check in Redis](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27348)
[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - The Helm Chart documentation has been updated to include command line options and documentation links specific to Helm 3, and to highlight some of the differences between Helm 2 and Helm 3. The specific changes can be viewed in the [issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1818).
> - In GitLab 13.0, the next release of GitLab, we will be removing the `ConfigMap` entries for `puma.rb` and `unicorn.rb` files in favor of environment variables. Please note that if you have modified the `unicorn.rb` from the ConfigMap (via Helm + Kustomize) in the past, you will be impacted by this change. We are doing this to eliminate maintaining two copies of these files. Until now, the `puma.rb` and `unicorn.rb` files were static within the `gitlab-webservice` container and overwritten by ConfigMap items from the `gitlab/unicorn` chart. For details on the new environment variables, refer to [the associated merge request](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/430).
> - Now that you can choose between Unicorn or Puma for your web application server, the name of the Unicorn chart will be changing from `unicorn` to `webservice`. This change will take place in GitLab 13.0. As a reminder, Puma will become the default application server in GitLab 13.0 due to the performance improvements we have seen with its multi-threading capabilities. To try out Puma in your Helm install, see the instructions in the [Charts documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html#webserver-options).
Cloud Native InstallationBug fixes
> Some of the notable bug fixes in GitLab 12.10 are:
>
> - [Merge Requests no longer return an empty array when using the GraphQL API](https://gitlab.com/gitlab-org/gitlab/-/issues/34527)
> - [Elasticsearch Integration Menu now prevents non-URL patterns in URL field](https://gitlab.com/gitlab-org/gitlab/-/issues/199076)
> - [Update Elasticsearch index_options to fix complex search queries](https://gitlab.com/gitlab-org/gitlab/-/issues/213265)
> - [Improve the Elasticsearch settings autocomplete results](https://gitlab.com/gitlab-org/gitlab/-/issues/199089)
> - [Raise exception when encountering database connection errors](https://gitlab.com/gitlab-org/gitlab/-/issues/205640)
> - [Milestone pages with large numbers of issues no longer time-out](https://gitlab.com/gitlab-org/gitlab/-/issues/39453)
> - [Issue board search returns results for 1 and 2 letter searches](https://gitlab.com/gitlab-org/gitlab/-/issues/35947)
> - [Board Lists no longer lose their filter label when it becomes a group label](https://gitlab.com/gitlab-org/gitlab/-/issues/23206)
> - [Fix exception when filtering epics in list with 2 labels and search text](https://gitlab.com/gitlab-org/gitlab/-/issues/198156)
> - [Create Release API returns a 500 error for invalid tag](https://gitlab.com/gitlab-org/gitlab/-/issues/204718)
> - [Make release notes optional and do not delete release when they are removed](https://gitlab.com/gitlab-org/gitlab/-/issues/27880)
> - [Releases are not visible to users with Guest Account](https://gitlab.com/gitlab-org/gitlab/-/issues/34862)
> - [Maximum size for GitLab pages doesn't accept a value of 0](https://gitlab.com/gitlab-org/gitlab/-/issues/199422)
> - [Releases page in not loading on pagination](https://gitlab.com/gitlab-org/gitlab/-/issues/211394)
[Retrieve CI/CD secrets from HashiCorp Vault](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/index.html):
> In this release, GitLab adds support for lightweight JSON Web Token (JWT) authentication to integrate with your existing HashiCorp Vault. Now, you can seamlessly provide secrets to CI/CD jobs by taking advantage of [HashiCorp's JWT authentication method](https://www.vaultproject.io/docs/auth/jwt/) rather than manually having to provide secrets as a variable in GitLab.
Secrets Management[Easy to configure AWS deployment variables](https://docs.gitlab.com/ee/ci/variables/#custom-variables-validated-by-gitlab) (self-managed only):
> When deploying to AWS, applying the necessary environment variables should be as convenient as possible. You can now select the predefined variables for 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY' and 'AWS_DEFAULT_REGION' from the environment variable key list. You'll also see the variables you enter validated to ensure they are entered in a valid format.
Continuous Delivery[Link runbooks and assets to a Release](https://docs.gitlab.com/ee/user/project/releases/#release-assets):
> Release and build managers are often in charge of wrangling several activities outside of GitLab in order to effectively deliver a release. GitLab is working to make the Release page a single source of truth for everything regarding your releases. We've added the ability to link runbooks to the assets of a Release so you can now track all of these related activities easily and see how far along they are.
Release Orchestration[View Issue and MR feed by newest activity first](https://docs.gitlab.com/ee/user/discussions/index.html#change-activity-sort-order):
> Issues are one of the primary tools for collaboration within GitLab. The
> default order of oldest-to-newest discussions and systems notes is
> incredibly helpful for some use cases, such as understanding the history
> of a given issue. However, it is much less helpful when teams are in
> triage and firefighting mode, as they have to scroll all of the way to the
> end of the issue to see the latest updates.
>
> Now you can reverse the default order and interact with the activity
> feed with the most recent items at the top. Your preferences for Issues and MRs are saved separately via local storage and are automatically applied to every Issue and MR that you view.
Issue Tracking[Import Issues from Jira to GitLab](https://docs.gitlab.com/ee/user/project/import/jira.html):
> Until now, the only way to get Jira issues into GitLab was manually,
> with our CSV importer, or by hand-rolling your own migration utility.
> GitLab 12.10 includes an
> [MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc)
> to automatically import your Jira issues into GitLab. This is the first
> of [many planned
> enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to
> make transitioning from Jira to GitLab as frictionless as possible.
>
> To get started, set up the Jira integration on your GitLab project, click
> the import icon at the top of your project's Issue List, and select
> **Import From Jira**.
Jira Importer, Issue Tracking[Use Copy & Paste to upload an image to the Design Tab](https://docs.gitlab.com/ee/user/project/issues/design_management.html#adding-designs):
> With the new Copy & Paste functionality, you can now paste one image from the top of your clipboard history directly into the Designs tab as a `.png` file. This functionality is particularly useful to quickly share screenshots from the clipboard in any issue.
Design Management[Tracking Wiki activity](https://docs.gitlab.com/ee/user/project/wiki/#wiki-activity-records):
> Up to GitLab 12.9, when you contribute to the wiki content, it does not influence your activity in GitLab. With this release, you'll see all wiki contributions on the project, group, and user activity pages. Now you can track wiki changes and wiki editors will get credit for their contributions!
Wiki[Repository file icons based on file extension](https://docs.gitlab.com/ee/user/project/repository/#files):
> When viewing files in your repository, GitLab now displays an icon based
> on the file extension.
> Different file types use icons of different colors and shapes to help people
> quickly recognize files in the editor, and when browsing their computer.
>
> This change also makes icon styling consistent between the repository view,
> the Web IDE, and the merge request file tree. Enjoy!
Source Code Management[Caching of Git info/refs](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/design_diskcache.md):
> When fetching changes from a Git repository, the server advertises a list of all the branches and tags in the repository, known as refs. In some instances, we have observed up to 75% of all requests to the GitLab web server are requests for the refs. In the best case, when all the refs are packed, this is an inexpensive operation. However, when there are unpacked refs, Git must iterate over the unpacked refs. This causes additional disk I/O, which is slow when using high latency storage like NFS.
>
> In GitLab 12.10, `info/refs` are cached to improve the performance of ref advertisement and decrease the pressure on Gitaly in situations where refs are fetched very frequently. In testing this feature on GitLab.com, we observed read operations outnumber write operations 10 to 1, and saw median latency decrease by 70%. For GitLab instances using NFS for Git storage, we expect even greater improvements.
Gitaly[Project template with built-in Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/):
> Hosting static websites with GitLab Pages is an easy and quick way to get your site up and running. Editing the content that populates your static site, however, often requires setting up complex local development environments, an understanding of the underlying project architecture, and familiarity with Markdown syntax. For some, this is a barrier to collaboration.
>
> We're taking our first step toward delivering a first-class editing experience for static site content that facilitates collaboration on content without requiring any prior knowledge of programming languages or even Git. GitLab now includes a new project template that creates a static website, initially supporting Middleman, pre-configured to be hosted on GitLab Pages and with content that can be edited in a new, streamlined Static Site Editor. **After deploying** the site, just click the *"Edit this page"* link visible on every page and this will launch our new editor which removes the extraneous interface and focuses entirely on the content of the page. When you're done, one click generates a new branch and a merge request for your changes.
Static Site Editor[GitLab Runner 12.10](https://docs.gitlab.com/runner):
> We're also releasing GitLab Runner 12.10 today! GitLab Runner is the lightweight, highly scalable, cross-platform software
> 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.
>
> #### Fixed bugs:
>
> - Fix: [On occasion, a job fails, and the Runner generates a `no such file or directory` error](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1379).
> - Fix: [Docker machine fails to create autoscaled Runner instances on AWS when the Runner hostname includes an underscore (`_`)](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3021).
> - Fix: [On occasion, jobs fail on Google Kubernetes Engine (GKE), and the Runner generates an `error dialing backend: EOF` error](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3247).
> - Fix: [Job failing with container name already in use error for Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4327).
> - Fix: [Job failing with "No such container" error for Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450).
> - Fix: [Build container hostnames that include an underscore (`_`) are not RFC1035 compliant](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4779).
> - Fix: [Runner hostnames that include an underscore (`_`) are not RFC1035 compliant](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6325).
> - Fix: [A spelling error in the Helm chart configuration prevented the Runner from using a previously defined Google secret](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/99).
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v12.10.0/CHANGELOG.md).
Continuous Integration (CI)[Autoscaling GitLab CI jobs on AWS Fargate](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate/-/blob/master/docs/README.md) (self-managed only):
> GitLab Runner [autoscaling](https://docs.gitlab.com/runner/configuration/autoscale.html) responds to CI job demand by provisioning new cloud-hosted virtual machines. However, while this model of automatically spinning virtual machine instances up and down continues to be sufficient for specific use cases, customers also want to take advantage of the capabilities of cloud container orchestration solutions for executing GitLab CI/CD jobs.
> You can now auto-scale GitLab CI on AWS Fargate with the MVC release of [GitLab's AWS Fargate Driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/fargate). With this new autoscaling pattern, GitLab's AWS Fargate driver automatically runs each build in a separate and isolated container on Amazon's Elastic Container Service (ECS) using a user-defined container image.
GitLab Runner[Easier access to Container Registry commands](https://docs.gitlab.com/ee/user/packages/container_registry/#control-container-registry-from-within-gitlab):
> The GitLab Container Registry used to show an illustration that contained easy to copy build and push commands with the correct registry URL for your project. However, once an image was added to the registry, the commands would disappear.
>
> In 12.10, we now show these Docker commands even when the registry is not empty. This will make the onboarding process of a new user easier and will boost their familiarity with Docker commands.
Container Registry[Use Deploy tokens to read and write to the GitLab Container Registry](https://docs.gitlab.com/ee/user/project/deploy_tokens/#limiting-scopes-of-a-deploy-token):
> Deploy Tokens allow you to access your group and project's repositories and container registries. However, the defined scopes of `read_repository` and `read_registry` have not allowed you to grant push access to the GitLab Container Registry. As a result, DevOps teams have used insecure or expensive user based workarounds.
>
> In GitLab 12.10, we are excited to announce more granular permissions for GitLab Deploy Tokens. You can now set read or write access for the Container Registry. You can create and manage Deploy Tokens from within the GitLab application or by using the [API](https://docs.gitlab.com/ee/api/deploy_tokens.html).
Container Registry[View Docker images in the Container Registry at the group level](https://docs.gitlab.com/ee/user/packages/container_registry/#control-container-registry-for-your-group):
> When using the GitLab Container Registry, it is important to have a cross-project view of all your Docker images. Until recently, the user interface has only been available at the project level. This inefficient workflow has resulted in a lack of collaboration and sharing of Docker images amongst teams.
>
> In 12.10, we are excited to announce that you can now view all of your group's images within the GitLab application. Now you can share, discover and manage all of your images in one place.
Container Registry[Web Application Firewall (WAF) Controls for Logging and Blocking Modes](https://docs.gitlab.com/ee/user/clusters/applications.html#logging-and-blocking-modes):
> To help
> tune rules for false positives or false negatives, you can globally set your WAF to either
> **Logging** or **Blocking** mode on the **Operations -> Kubernetes** page.
WAF[Custom metrics available in Core](https://docs.gitlab.com/ee/operations/metrics/index.html#adding-custom-metrics):
> Understanding system performance often starts with monitoring the metrics that convey the health and performance of the components in question. These capabilities are needed by every development team and we want our metrics solution to be widely available to everyone that uses GitLab.
> As part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we've moved [custom metrics](https://docs.gitlab.com/ee/operations/metrics/index.html#adding-custom-metrics) in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 12.10, all users can add and display any metric they collect using Prometheus in the GitLab UI.
Metrics[Alerting available in GitLab Core](https://docs.gitlab.com/ee/operations/incident_management/index.html#alerting):
> A critical part of monitoring and observing system and application performance is the alert you receive that tells you when something has gone wrong. Without alerting, there is no way to close the DevOps loop and efficiently respond to services where critical thresholds have been breached. These capabilities are needed by every development team and we want our [Alert Management solution](https://about.gitlab.com/direction/service_management/alert_management/) to be widely available to everyone that uses GitLab.
> As part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we've moved [alerting](https://docs.gitlab.com/ee/operations/incident_management/index.html#alerting) in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 12.10, all users can [create IT alerts from charts on the metrics dashboard](https://docs.gitlab.com/ee/operations/metrics/index.html#setting-up-alerts-for-prometheus-metrics), and receive alerts in GitLab via the [generic REST endpoint](https://docs.gitlab.com/ee/operations/incident_management/integrations.html).
Alert Management[Collapse unfurled charts in issues](https://docs.gitlab.com/ee/operations/metrics/embed.html#embedding-metrics-in-issue-templates):
> When resolving incidents, charts embedded directly into an issue can save you time by displaying all of your information in one place instead of forcing you to bounce around between multiple locations. However, charts can become frustrating if you only want to read the text and quickly consume the information. You can now collapse and expand charts, and choose between seeing the charts or removing them from the view.
Incident Management[Automatically embed metrics in GitLab issues for Prometheus alerts](https://docs.gitlab.com/ee/operations/metrics/embed.html#embedding-metrics-based-on-alerts-in-incident-issues):
> While triaging an incident, charts help you visualize what went wrong, which can speed up investigation and resolution. In 12.9, GitLab started [automatically embedding relevant charts](https://gitlab.com/gitlab-org/gitlab/issues/119016) in all incident issues that were created from GitLab-configured Prometheus alerts. We have now extended this feature to work in issues generated from all Prometheus alerts GitLab receives, whether the alerts were configured in GitLab or configured externally.
Alert Management[Display your metrics with bar charts](https://docs.gitlab.com/ee/operations/metrics/dashboards/panel_types.html#bar-chart):
> We've added bar charts as a new visualization option on your monitoring dashboard to help you display your metrics the way you want.
Metrics[Filtered search for pod logs](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html):
> Logs, while ubiquitous, are only useful if the relevant logs can be found easily. In GitLab 12.10, we introduced filtered search for pod logs, enabling you to search and define filters for pod logs with a single, scalable search bar. This replaces the cumbersome combination of terminal view, filters, and a search bar, ultimately enabling you to find the relevant logs more easily.
Metrics[Out-of-the-box NGINX alerts for Auto Monitoring in Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-monitoring):
> [Auto Monitoring](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-monitoring) is a feature of [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), a predefined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications.
>
> Auto Monitoring enables you to monitor your application’s server and response metrics right out of the box after deploying your application. Auto Monitoring uses [Prometheus](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) to display system metrics such as CPU and memory usage directly from [Kubernetes](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html), and response metrics such as HTTP error rates, latency, and throughput from the [NGINX Server](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html). While this sounds like a lot to configure, we've reduced the configuration required for you to see the metrics and alerting in action by adding out-of-the-box alerts for NGINX Throughput and HTTP error rate metrics that work right away after you set up Auto Monitoring for Auto DevOps.
Alert Management[Support custom intervals in metrics charts](https://docs.gitlab.com/ee/operations/metrics/dashboards/yaml.html):
> Sometimes using predefined time intervals makes pinpointing a specific time period difficult. GitLab monitoring dashboards now support custom intervals, which enable you to visualize your aggregated metric data in an interval of your choosing, on top of being able to visualize with the default intervals.
Metrics[Time range in URL for metric charts](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#timeline-zoom-and-url-sharing):
> When viewing metric charts, updating the time range now updates the URL to the chart, allowing you to share or bookmark links to specific time frames easily.
Metrics