GitLab 12.10 Release

Compliance dashboard shows pipeline result for the most recent, merged MR

Compliance dashboard shows pipeline result for the most recent, merged MR

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 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.

Extend Access Token lifetime in GitLab.com

Extend Access Token lifetime in GitLab.com

Starting 12.10, GitLab.com customers can also limit the lifetime of personal access tokens in 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.

New HIPAA audit protocol project template

New HIPAA audit protocol project template

With GitLab, you can automate highly repeatable HIPAA Audit Protocol workflows. GitLab can help simplify these workflows natively by leveraging issues and 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.

View Issue and MR feed by newest activity first

View Issue and MR feed by newest activity first

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.

Design thumbnails

Design thumbnails

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 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!

Project template with built-in Static Site Editor

Project template with built-in 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.

Tracking Wiki activity

Tracking Wiki activity

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!

Automatically trigger your project when another is rebuilt

Automatically trigger your project when another 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.

Easier access to Container Registry commands

Easier access to Container Registry commands

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.

Use Deploy tokens to read and write to the GitLab Container Registry

Use Deploy tokens to read and write to the GitLab Container Registry

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.

View Docker images in the Container Registry at the group level

View Docker images in the Container Registry at the group level

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.

GitLab Pages Project Template for Gatsby

GitLab Pages Project Template for Gatsby

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.

Merge Trains support added to /merge quick action

Merge Trains support added to /merge quick action

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.

Alerting available in GitLab Core

Alerting available in GitLab Core

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 to be widely available to everyone that uses GitLab. As part of our 2020 gift, we’ve moved 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, and receive alerts in GitLab via the generic REST endpoint.

Collapse unfurled charts in issues

Collapse unfurled charts in issues

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.

Display your metrics with bar charts

Display your metrics with bar charts

We’ve added bar charts as a new visualization option on your monitoring dashboard to help you display your metrics the way you want.

Out-of-the-box NGINX alerts for Auto Monitoring in Auto DevOps

Out-of-the-box NGINX alerts for Auto Monitoring in Auto DevOps

Auto Monitoring is a feature of Auto DevOps, 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 to display system metrics such as CPU and memory usage directly from Kubernetes, and response metrics such as HTTP error rates, latency, and throughput from the NGINX Server. 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.

Time range in URL for metric charts

Time range in URL for metric charts

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.

Geo improvements to the administrator interface

Geo improvements to the administrator interface

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 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
• Updated the Geo health status to make it more visible
• Reworked the synchronization status for items we don’t replicate
• Improved Geo node form errors to provide more details of what went wrong

GitLab chart improvements

GitLab chart improvements

• 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.
• 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.
• 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.

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

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. In GitLab performance testing using the 10K user reference architecture, 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.

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. If you are using the Helm install, you will need to manually switch to PostgreSQL for 12.10.

Reduced memory consumption of GitLab with Puma

Reduced memory consumption of GitLab with Puma

GitLab is switching application servers from Unicorn to Puma, 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 in Omnibus, and experimental in the Helm chart. We plan to make Puma the default application server in GitLab 13.0.

Sidekiq Cluster available in Core

Sidekiq Cluster available in Core

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.

Users statistics improved

Users statistics improved

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.

Disable individual rules in DAST

Disable individual rules in DAST

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.

Provide severity levels for dependency scanning vulnerabilities

Provide severity levels for dependency scanning vulnerabilities

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.

Compliance framework labels for projects

Compliance framework labels for projects

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.

Group-level activity overview MVC

Group-level activity overview MVC

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.

Optional SSH key expiration date

Optional SSH key expiration date

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.

Caching of Git info/refs

Caching of Git info/refs

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.

High Availability for Gitaly (beta)

High Availability for Gitaly (beta)

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) configuration. The recommended approach currently uses Network File System (NFS), 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 to prevent such data loss scenarios.

Repository file icons based on file extension

Repository file icons based on file extension

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!

Use Copy & Paste to upload an image to the Design Tab

Use Copy & Paste to upload an image to the Design Tab

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.

GitLab Runner 12.10

GitLab Runner 12.10

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.
• Fix: Docker machine fails to create autoscaled Runner instances on AWS when the Runner hostname includes an underscore (_).
• Fix: On occasion, jobs fail on Google Kubernetes Engine (GKE), and the Runner generates an error dialing backend: EOF error.
• Fix: Job failing with container name already in use error for Docker executor.
• Fix: Job failing with “No such container” error for Docker executor.
• Fix: Build container hostnames that include an underscore (_) are not RFC1035 compliant.
• Fix: Runner hostnames that include an underscore (_) are not RFC1035 compliant.
• Fix: A spelling error in the Helm chart configuration prevented the Runner from using a previously defined Google secret.

The list of all changes is in the GitLab Runner CHANGELOG.

Filter the Package Registry by name

Filter the Package Registry by name

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.

Use the GitLab API to purge blobs from the Dependency Proxy

Use the GitLab API to purge blobs from the Dependency Proxy

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.

Compare Release Evidence over time

Compare Release Evidence over time

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.

Independent ECS task creation

Independent ECS task creation

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.

Use GitLab UI to delete an environment

Use GitLab UI to delete an environment

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.

Automatically embed metrics in GitLab issues for Prometheus alerts

Automatically embed metrics in GitLab issues for Prometheus alerts

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 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.

Custom metrics available in Core

Custom metrics available in Core

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, we’ve moved 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.

Filtered search for pod logs

Filtered search for pod logs

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.

Support custom intervals in metrics charts

Support custom intervals in metrics charts

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.

Easily clean up unused LFS files

Easily clean up unused LFS files

GitLab supports managing large binaries in projects via Git LFS, such as audio, video, or graphics files. These files can be removed from LFS by rewriting Git history; 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 redirects HTTP(S) requests for unsynchronized repositories to the primary node

Geo redirects HTTP(S) requests for unsynchronized repositories to the primary node

Geo supports 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.

Omnibus improvements

Omnibus improvements

• 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. Further details are also available in Balu’s blog post.
• GitLab 12.10 includes Mattermost 5.21, an open source Slack-alternative whose newest release includes ChatOps integration with AWS, GitLab, and CodeShip, and more. This version also includes 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 for more details.

Highlight code results in Global Search

Highlight code results in Global 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 for contributing this feature!

Reduction in Advanced Global Search index size by about 50%

Reduction in Advanced Global Search index size by about 50%

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.

Switch to plain SQL for GitLab schema

Switch to plain SQL for GitLab schema

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.

Bug fixes

Bug 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
• Elasticsearch Integration Menu now prevents non-URL patterns in URL field
• Update Elasticsearch index_options to fix complex search queries
• Improve the Elasticsearch settings autocomplete results
• Raise exception when encountering database connection errors
• Milestone pages with large numbers of issues no longer time-out
• Issue board search returns results for 1 and 2 letter searches
• Board Lists no longer lose their filter label when it becomes a group label
• Fix exception when filtering epics in list with 2 labels and search text
• Create Release API returns a 500 error for invalid tag
• Make release notes optional and do not delete release when they are removed
• Releases are not visible to users with Guest Account
• Maximum size for GitLab pages doesn’t accept a value of 0
• Releases page in not loading on pagination

Performance improvements

Performance improvements

We are continuing to make great strides improving the performance of GitLab in every release. We’re committed 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
• Merge Requests Discussions API no longer degrades with comments count
• Issue creation has a customizable rate limit
• Make Rails.cache and Gitlab::Redis::Cache use the same pool
• Add issues to GraphQL group endpoint
• Remove N+1 queries from GraphQL EpicType
• Export via streaming serializer, introduce Writer abstraction
• Cache Elasticsearch enabled check in Redis