Gitlab 13.7 was released – InformTFB

Gitlab 13.7 was released

Gitlab 13.7 was released

Well, the year was 2020! We are happy to present release 13.7 with more than 45 features and SOFTWARE delivery improvements, released just in time for the holidays.

On behalf of all GitLab employees, we would like to thank the members of Our community for your contributions and for the positive impact you have on our work. Without you, GitLab wouldn’t be what It is now.

Thank you and all the members of the GitLab team who helped make 2020 an incredible year despite adversity and unpredictable circumstances. Please stay safe, happy and healthy during this festive period.

Here’s what’s waiting for you in the 13.7 release:

Improved project management for the development of joint work

Merge requests (in the Russian localization of GitLab, “merge requests”) are crucial for the development of collaboration and can be directly linked to the corresponding tickets, providing a Central place for communication through comments, suggestions for changes in the code, and code reviews. In this release, we added verifiers for merge requests — a way to improve the code review process, making it easier and more organized. Now you can quickly find out who participated in the merge request, or request a review from someone by sending a corresponding notification.

Context switching and manual execution of tasks in the workflow make it difficult to effectively interact between groups and projects. This means that you spend less time developing valuable features and spend more time working on projects, so the ability to clone tickets with quick actions will probably be useful to you, as it will help you optimize project management and agile planning with agile.

Working together on projects and iterating frequently when developing your applications means that you should be able to quickly determine the importance of your tickets, identify any blocking tasks, and use this information to prioritize your decisions. Now you can sort by the number of blocked ticketsto quickly find those tickets that block progress on other tickets.

Improved release automation and deployment flexibility

You need flexibility to manage your organization, automate, and deploy applications on a regular basis. Reliable and frequent application deployment allows faster delivery of the product to customers.

To improve release automation in GitLab, we’ve added automatic rollback in case of a crash. This feature cancels a failed deployment, restores the last successful deployment, and sends an automatic notification about it. You don’t have to make changes manually, and you can be sure that potential problems won’t lead to downtime and the situation won’t get worse while you work on Troubleshooting.

Another improvement that goes well with automatic rollback in the event of a failure is the ability to view the deployment status on the environments page. Viewing deployment statuses has become much more convenient, as well as determining what actions you need to take, such as stopping or rolling back a deployment.

We also released the first officially supported beta version Of the gitlab task handler container for Red Hat OpenShift, as well as our certified task handler operator, to give you more freedom in how you release releases with GitLab. We are working on making this feature publicly available, so stay tuned for future releases.

More reliable and efficient package and dependency management

Your workflow depends on a variety of programming languages, binaries, integrations, and artifacts that are important inputs or outputs to your development process. The more efficiently you manage your packages and dependencies, the less work time is wasted. To improve the efficiency of working with the package registry, we have added a quick search and view of shared packages.

We also made improvements to the gitlab dependency proxy; by the way, this feature was moved to Core in GitLab 13.6.

Now you can fit in with Docker’s query constraints and speed up pipelines (in the Russian localization of GitLab, “Assembly lines”) by caching container images hosted on DockerHub, and be confident in the reliability and efficiency of working with images.

Another improvement that many of our community expected — the dependency proxy now works with private projectsas well, so now this feature can also be used by those users who prefer to work with private projects.

Finally, you can use predefined variables with a dependency proxy instead of relying on your own defined variables or embedded values in your file This gives you a more scalable and efficient way to start proxying and caching images.

And that’s not all!

Take a look at some more cool new features in release 13.7:

These are just a few of the many new features and performance improvements of this release. If you want to know in advance what’s waiting for you in the next month, take a look at the upcoming releases pageand watch our video for release 13.8.

On January 6th-7th, we hosted a virtual hackathon, learn more about this and future events from GitLab here.

GitLab MVP badge

This month’s MVP is Rachel Gottesman

Rachel actively helped our team of technical writers implement a consistent style in documentation to correct the use of the future tense in our documents. In release 13.7, Rachel opened 33 merge requests, which helped our team to cope with this important and painstaking task. Thank You, Rachel!

Key features of the GitLab 13.7 release

Verifiers for merge requests


Asking a coworker to review your code should be a normal part of the workflow, but sometimes it can be unnecessarily difficult. A simple task like requesting a review can lead to confusion. For example, how exactly should the request be made: via email, comment, or chat message? Without a formal review mechanism, merge requests can be inconsistent and difficult to keep track of. Previously, it was already possible to assign a reviewer to a merge request, but both the author and reviewer were displayed in the same “Assignee” field, which did not allow other team members to find out who was responsible for what in this merge request.

GitLab 13.7 introduces a new feature — now merge request authors can request a review from specific users. In the new “Reviewers” field, users can be assigned as reviewers for a merge request in the same way that assignees are assigned. Users assigned to the review will receive a notification prompting them to view the merge request. Thus, there is now a formal process for requesting a review for a merge request and specifying the roles of each user in working on it.

Future iterations will include displaying the most appropriate verifiers for the merge request, as well as an improved merge request confirmation process that will focus specifically on verifiers. You can find out more about this in epic on assigning reviewers to merge requests.

Reviewers for Merge Requests

Documentation on assigning verifiers for the merge request and the original ticket.

Automatic rollback in case of failure

(ULTIMATE, GOLD) Stage of the DevOps cycle: Release

If you have a critical deployment issue, manual actions to fix it can take quite a long time and lead to disruptions in production, which negatively affects users. You can now use an automatic rollback mechanism that reverts your deployment back to the last successful deployment. In addition, when GitLab finds problems in production, it automatically notifies you. This way you will always be informed about problems in a timely manner, and you will get precious time to debug, research, and fix problems without unnecessary downtime.

Documentation on automatic rollback in case of failure and the original ticket.

Cloning a ticket via a quick action


To make creating similar tickets more efficient, tickets now support a quick action /clonethat creates a new ticket in the same project with the same name, description, and metadata. Quick action /clonereplaces a more time-consuming process that included several steps to create a ticket, copy the ID or path to the original ticket, and use quick action copy_meta.

By default, tickets are cloned to the same project and do not include system notes and comments, but you can change the default behavior when cloning.

Clone an issue with a quick action

Documentation for quick actions and the original ticket.

Gitlab task handler for Red Hat OpenShift


The gitlab task handler container image (GitLab runner) for the Red Hat OpenShift container platform is finally available! To install a task handler on OpenShift, use the new gitlab task handler operator. It is available on the beta channel in Red Hat’s Operator Hub, a web-based console for OpenShift cluster administrators already deployed by default on the platform, where they can find and select operators to install on their cluster. On the openshift container platform, the Operator Hub is already deployed by default. We plan to move the gitlab task handler operator to the stable channel, and in early 2021 — to the General access. Finally, we are also developing an operator for GitLab, so stay tuned for future posts.

GitLab Runner for Red Hat OpenShift

Documentation for installing on OpenShift and the original ticket.

Viewing the status of deployments on the environments page


Previously, there was no way to find out from the environments page that a deployment was currently being performed. This page now displays deployment statuses and warnings, so you can decide what actions to take based on the deployment status (successful, failed, or current). For example, you can stop the current deployment or roll back a completed one.

Show deployment status on the Environments page

Documentation on working with environments and the original ticket.

Use the user interface to set the percentage of traffic for a Canary deployment

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: Release

In GitLab 13.7, you can change the percentage of traffic for a Canary deployment (the canary-weight value) directly from the deployment boards in the user interface. You can also change this value from gitlab-ci.ymland through the API, but by doing this in the user interface, you can monitor the deployment and, if necessary, scale the pods directly from the deployment boards. This way you’ll have more control over manual or incremental timer deployments, and you’ll be able to better control and even reduce risks.

Set deployment traffic weight via the UI

Documentation for setting the percentage of traffic for a Canary deployment and the original ticket.

View the frequency of deployments via the API

(ULTIMATE, GOLD) Stage of the DevOps cycle: Release

In this release, as part of the first iteration of gitlab’s built-in support for DORA4 metrics, the ability to find out the frequency of project-level deployments via the API was added. This allows you to track the effectiveness of the deployment over time, it is easy to find bottlenecks and, if necessary, quickly take corrective measures.

API support for deployment frequency

Project analysis documentation and original ticket.

Support for multiple manifest files in a project

(PREMIUM, ULTIMATE) Stage of the cycle DevOps: Configure

In previous releases, to use our kubernetes agent (GitLab Kubernetes Agent), users were required to collect all Kubernetes resources in a single manifest file. Now the agent can collect Kubernetes manifests recursively from the specified directories in your project. Your platform specialists will now be able to use a single repository to manage different clusters from a single location, as well as describe large deployments using a single agent.

Support multiple manifest files in a project

Documentation on configuring a repository with the Kubernetes agent and the original ticket.

Import requirements from external tools

(ULTIMATE, GOLD) Stage of the DevOps cycle: Plan

For effective collaboration, it is very important that all your requirements are stored in one place, so we are happy to announce that now you can import requirements from CSV files!

Thanks to this feature, you can work as a team on requirements in GitLab, and at the same time easily interact with customers, suppliers, and external organizations. Stay tuned for future improvements to requirements export.

Import requirements from external tools

Documentation for importing requirements from a CSV file and the original ticket.

Multiple HTTP endpoints for alerts

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: Monitor

Alert integrations are a critical part of your incident management workflows, so it’s important to have precise control over endpoints and authentication tokens. The last thing you need is for all your alerts to stop working due to a single authentication token change. Setting up an HTTP endpoint for each monitoring tool will allow your team to manage each tool individually, without affecting alerts from other tools.

Integrate alerting tools with multiple HTTP endpoints

Documentation on endpoints for alerts and the original epic.

Syncing groups on using SAML

(SILVER, GOLD) Stage of the DevOps cycle: Manage

In GitLab 13.7, you can bind a group in your account provider to a group on using SAML. The group membership will be updated when the user logs in to their GitLab account via their SAML provider. This feature reduces the need for manual group assignment, which reduces group loading for GitLab administrators. Syncing groups also makes it easier for new group members to adapt, eliminating the need for them to request access from gitlab group administrators.

SAML Group Sync for

Documentation on syncing groups using SAML and the original epic.

Other improvements in GitLab 13.7

DevOps Adoption

(ULTIMATE) Stage of the DevOps cycle: Manage

DevOps Adoption shows you which teams in your organization use tickets, merge requests, confirmations, task handlers, pipelines, deployments, and scans in GitLab. Also use the new feature “segments” to organize your GitLab groups into logical units within your organization, so that you can compare how GitLab is used among several different groups.

  • Make sure that you are getting the expected return from using GitLab.
  • Find out which groups are lagging behind in implementing GitLab, and help them set up DevOps.
  • Find out which groups use certain features, such as pipelines, and can share their experience with other groups that want to start using them.
DevOps Adoption

Documentation on DevOps Adoption and the original ticket.

Improved user interface for creating projects


With an improved user interface for adding a project, it will be easier for you to choose between creating an empty project, a project from a template, importing a project, and creating a CI/CD project for external repositories.

Documentation for creating projects and the original ticket.

Restricting the creation of projects and groups for external accounts

(PREMIUM, ULTIMATE, SILVER, GOLD) Stage of the DevOps cycle: Manage

To reduce the risk of accidental disclosure of intellectual property, GitLab administrators now have more control over accounts provided through group integration using SAML or SCIM. In the first iteration of this feature, administrators can prohibit their users from creating groups or projects outside the groups they belong to.

Documentation on user settings via SAML and the original ticket.

Sorting by the number of blocked tickets


When sorting a list of tickets in GitLab, it is often important to determine which ones need to be executed most urgently, and whether they block other tickets.

Previously, it was impossible to see which tickets were blocked by others in the ticket list. The only way to do this is to open each of them and view the list of blocked tickets under the ticket description, which takes a very long time.

In version 13.7, you can use the “Blocks other tickets” filter for the ticket list to sort it by the number of blocked tickets.

Sort issues by the number of issues they are blocking

Sorting documentation and the original ticket.

View files in merge requests one at a time


Reviewing merge requests is the most important task for ensuring the quality of the code of all participants, since this is where most of the discussions between the author and the reviewer take place. However, as merge requests get larger and the number of files in them increases, the navigation and performance of diffs may degrade.

In GitLab 13.7, we added the ability to view files one at a time when viewing a merge request. When you go to the merge request tabChanges click on the gear icon and check the boxShow files oneat a time . After selecting this option, you can view the files one at a time, switching between them using the buttonsPrevious andNextone .

In this mode, your workspace looks less congested, and it’s easier to focus on a single file. In addition, it increases performance and improves navigation through the merge request diff.

Choose to show one file at a time directly from merge requests

Documentation for reviewing and managing merge requests and the original ticket.

View merge request changes in VS Code


When reviewing merge requests in VS Code, to address changes, you often have to make a branch checkout and then try to understand the diff between this branch and the target branch of merge.

With the release of the GitLab Workflow extension 3.7.0, merge request changes are now available directly in VS Code. This allows you to quickly view changes in your projects ‘ merge requests.

As part of the work on adding a full-fledged review code to VS Code, the next step is to add comments to diffs.

View Merge Request changes in VS Code

The documentation of the extension for VS Code and the original ticket.

Improved the downloading of artifacts for the sub-conveyors


Previously, when downloading artifacts from the parent pipeline to the nested pipeline, it was not always possible to get the necessary artifacts. If two upstream pipelines were started at approximately the same time, then the nested pipeline could also download artifacts from the newer pipeline.

Now you can use the new syntax needs:pipelineto tell a nested pipeline which pipeline it needs to download artifacts from. You can use it to download artifacts from the parent pipeline or from another nested pipeline within the same hierarchy.

Improved artifact downloads with child pipelines

Documentation for downloading artifacts for nested pipelines and the original ticket.

Bypassing Docker restrictions and speeding up pipelines

For faster and more reliable builds, you can use our feature, dependency proxy, to cache container images from Docker Hub. However, when Docker started applying ограничения по количеству запросов docker pull, you may have noticed that even when your image was downloaded from the cache, Docker still counted it in the limit. This was because the dependency proxy cached only the layers (or BLOB objects) of the image, but not the manifest, which contains information about how to build this image. Since the manifest was required for the build, you still had to perform a pull. And if Docker Hub was unavailable, you couldn’t download the required image.
Starting with this release, the dependency proxy will cache both layers and the image manifest. So when you first download using alpine:latest the image will be added to the dependency proxy cache, and this will count as a single pull. The next time you downloadalpine:latest, everything will be downloaded from the cache, even if Docker Hub is unavailable, and this download will not be counted in the Docker limit.

We remind you that starting from 13.6, the dependency proxy is now available in the Core plan. So try this feature now and tell us what you think about it. Or even better, help us with open tickets.

The documentation of the proxy dependency and the original ticket.

Quickly search and view shared packages


You can easily publish shared files, such as release binaries, through the GitLab package registry. However, if you use the package user interface or another package Manager format, you may have noticed that you can’t select a tab to quickly view only your shared packages.

We recently added a tab to the packages user interfaceShared packages, so that you can filter the list of packages to view only shared packages. We hope this will help you find and check your packages more quickly and efficiently.

Documentation for viewing packages and the original ticket.

Proxy dependencies for private projects


You can use the GitLab dependency proxy to proxy and cache container images from Docker Hub. Until recently, this feature was only available for public groups, which prevented many users from using it.

Now you can use a dependency proxy for private projects as well. You can reduce your downloads from Docker Hub by caching your container images for future use. Since the dependency proxy stores Docker images in a space associated with your group, you must log in with your GitLab username and password, or with a personal access token that has at least read permission (read_registry).

The documentation of the proxy dependency and the original ticket.

Improved support for SAST analyzers for multiple projects


In GitLab, security scans automatically detect the code language and run appropriate analyzers. For monorepositories, microservices, and repositories for multiple projects, there may be more than one project in a single GitLab repository. Previously, our security tools could only detect the code language in single projects in repositories. Starting with this release, our SAST analyzers can detect code languages in repositories with multiple projects, run appropriate scans for each project, and generate vulnerability reports. It makes
managing security tools is easier and more convenient for users with a single repository for multiple projects. In future releases, we will continue to improve the security dashboard and reports for these types of projects.

Documentation on repository support for multiple projects and the original epic.

Release description in an external file


If youсоздаёте релизы в конвейерах через файл .gitlab-ci.yml‘re on your own project, you may have had a hard time keeping the description of each release up to date. In the GitLab 13.7 release, you can specify a description of your release in a version control file or in an automatically generated file and call it from .gitlab-ci.yml. The contents of the file are uploaded to the release description in Markdown format. This makes it easier to create, maintain, and use version control for releases, and will be especially useful when auto-generating a change log. Many thanks to Nejc Habjan and Siemens for this incredible contribution!

Documentation for release descriptions and the original ticket.

Support for Kubernetes versions 1.17, 1.18, and 1.19


Gitlab support for the latest versions of Kubernetes allows you to take advantage of GitLab integrations with Kubernetes, such as GitLab Kubernetes Agent, Auto DevOps, and — on later clusters-GitLab Managed Apps. In this release, GitLab added official support for Kubernetes versions 1.17, 1.18, and 1.19.

Cluster documentation and the original ticket.

Geo supports snippet replication

(PREMIUM, ULTIMATE) Availability

Geo now supports replication of version-controlled snippets to secondary nodes, which will allow distributed teams to access them from the nearest Geo node, which reduces latency and makes the entire process more convenient. In addition, this data can be restored from the secondary node when switching to it in the event of a failure.

We don’t currently support verification for this data type, but we plan to add it in the future.

Documentation on geo replication and the original epic.

Support for encrypted LDAP credentials


GitLab uses a single configuration file, such gitlab.rbas in Omnibus GitLab, which makes it easier to configure all related services. This configuration file includes some secret keys, such as credentials for authentication to the LDAP server. Although special permissions are required to access this file, it is considered good practice to separate the secret keys from the configuration.

Omnibus gitlab and Source installations now support encrypted credentials, with LDAP being the first supported credentials. This reduces the vulnerability of the GitLab configuration file, and also helps to achieve compliance with customer requirements.

Documentation for configuring encrypted LDAP credentials and the original ticket.

Web hooks when adding new group members

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Stage of the DevOps cycle: Manage

Now it’s easier to automate user management in GitLab: you can do this by using a web hook that runs when a new member is added to the group. Previously, you had to perform REST queries to identify new group members, which degraded the performance of your GitLab instance.

Documentation on web hooks and the original ticket.

Improved filtering and sorting of lists of members of the group


We continued to improve our list of group members and added new filtering and sorting capabilities. This will help group administrators quickly find the information they need. For example, sorting by “Last sign-in” can be used to find users who haven’t recently logged in to GitLab, and to help manage licenses.

Improved group members list filtering and sorting

Documentation for filtering and sorting group members and the original ticket.

Automatic user profile preparation with SAML

(SILVER, GOLD) Stage of the DevOps cycle: Manage

Previously, as part of being included in a SAML group, users had to fill out a registration form. In GitLab 13.7, we introduce user synchronization for groups using SAML. When a user logs in to a SAML group for the first time, a user account is created for them automatically, if there is no existing user with the same email address. Automatic provisioning with SAML improves the process of adapting new users and ensures that newly created accounts contain the correct information.

Documentation on setting up groups with SAML and the original ticket.

Custom email address for customer support


Previously, it was difficult for your users to remember (and therefore use) the email address of the GitLab support service. With the introduction of a custom email address, you can now choose an address suffix that makes sense for your company and is easier for your users to remember. This is another step that you need to take to ensure that you can provide high-quality support to your users.

Documentation for setting up an email address for the support service and the original ticket.

Distinguish between formatting changes and edits made from the static site editor


The static site editor offers an intuitive and familiar WYSIWYG editing mode for Markdown content. To ensure a consistent Markdown output format, the WYSIWYG editor automatically reformats the page content according to the style conventions defined in the Markdown parser. This happens completely in the background before you even start editing. However, these formatting changes are committed along with your content changes. If the page you are editing did not follow the same style conventions, it may be difficult for the final merge request reviewers to distinguish your changes from automatic formatting.

Starting with GitLab 13.7, the static site editor automatically fixes inconsistencies in the Markdown syntax and commits all necessary formatting changes to the new branch. When editing is complete, the Publish button creates a separate commit containing only your changes. This can save time for change reviewers, who can focus on your content instead of going through syntax changes.

In the future, we plan to make the formatting parameters configurable, so stay tuned in the corresponding ticket.

Documentation for the static site editor and the original ticket.

Prefilled variables when manually starting pipelines


Previously, when you wanted to start the pipeline manually, you had to find out the necessary variables, and then enter them on the “Run Pipeline” page. This can be tedious and error-prone if you need to enter multiple key-value pairs. Now, a pipeline startup form will be generated for your pipeline with variables pre-populated based on the variable definitions in your file.gitlab-ci.yml, making this process more efficient.

Pre-filled variables when running pipelines manually

Documentation for manually starting the pipeline and the original ticket.

Packages built with CI / CD always display information about the build.


If you published packages in the package registry, you might have noticed that packages created with GitLab CI / CD did not always display the commit and pipeline responsible for creating or updating your package. This could happen for several reasons.

First, we may not have supported this feature yet, as is the case with Composer and Conan. Secondly, the problem occurred for those of you who updated the same version of the package from different branches or commits. However, until recently, the user interface only displayed the first deployment without any updates. Also, the details page shows the branch where the package was created, not the most recent commit. As a result, you had to search for this information by looking at the commit history, which was not very efficient.

In the future, any package built or updated using GitLab CI / CD will display commit and pipeline information in the packages user interface. To avoid performance or user interface issues, only five package updates will be displayed. In milestone 13.8, we will create a design that will help you easily view all data, including history. In the meantime, you can use the packages APIto view the entire build history of a given package.

Packages built with CI/CD always display build info

Documentation on the package registry and building packages using GitLab CI / CD and the original ticket.

Use predefined variables with a dependency proxy


By proxying and caching container images from Docker Hub, dependency proxies help you improve the performance of your pipelines. Despite the fact that the proxy server is designed for intensive use with CI / CD, to use this feature, you had to define your own variables or write values in your file This made it difficult for those who worked alone to get started and prevented them from using it as a scalable solution, especially for organizations with many different groups and projects.

In the future, you can use predefined environment variables as an intuitive way to proxy dependencies. The following variables are supported:

  • CI_DEPENDENCY_PROXY_USER: CI user to log in to the dependency proxy,
  • CI_DEPENDENCY_PROXY_PASSWORD: password to log in to the dependency proxy,
  • CI_DEPENDENCY_PROXY_SERVER: server for logging in to the dependency proxy,
  • CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX: an image prefix for extracting images via a dependency proxy.

Give it a try and let us know what you think!

Documentation on authentication in the dependency proxy using CI / CD and the original ticket.

Security scan results in the merge request widget are now more convenient

(CORE, STARTER, PREMIUM, FREE, BRONZE, SILVER) Stage of the DevOps cycle: Secure

With SAST and secret key search now available to all users, we have made life easier for all GitLab users who interact with the security scan results in the merge request, by making it easier to access the security scan results. Previously, the results of a security scan were only available on the pageBrowse the pipelineand you should have known where to look to find them there. Now all merge requests will show whether security checks have been started for them, and will help you find task artifacts. This is a change it does not affect the work with merge requests for users of the Ultimate plan.

Improved MR experience for security scans

Documentation for viewing security scan results in merge request and the original epic.

Special links to vulnerabilities

(ULTIMATE, GOLD) Stage of the DevOps cycle: Secure

We introduced vulnerabilities as full-fledged objects in 12.10. As an object, each of them has a unique URL that allows you to go directly to the details of any vulnerability. Despite the significant improvement in visibility and consistency, links to vulnerabilities in tickets and epics (in the Russian localization of GitLab “goals”) still need to be copied manually as Markdown links. This makes sharing inefficient, and references to vulnerabilities in other areas of GitLab are more cumbersome than for other objects, such as tickets.

Vulnerabilities can now be referenced using special links. The new syntax [object_type:ID] will be tested on them for the first time and will eventually be extended to other existing references. Now you can quickly insert a link to the vulnerability from any place where a special link is usually used, for example, from the description of a ticket or a merge request. Just enter [vulnerability:123] in the ticket description to insert a link to the vulnerability with ID 123 in the same project. You can also add a namespace or project prefix to the ID to refer to vulnerabilities outside the context of the current project.

See which commits and pipelines run in the fork project vs. the parent project

Documentation on launching pipelines in the parent project for merge requests from the fork project and the original ticket.

Database queries run faster when using a load balancer


Many database queries are repeated multiple times, so they can be cached to improve overall performance. For GitLab, you can cache approximately 10% of all requests. In GitLab 13.7, we enabled caching of database queries when using database load balancing. On this results in caching ~700,000 requests every minute and reduces the average query execution time by up to 10%.

For queries that run more than 100 times, we reduced the query duration by 11-31% and cached ~30% of all SELECT statementsthat would otherwise be executed on the database replica.

Documentation on database load balancing and the original ticket.

For new installations, PostgreSQL 12 is used by default


Since GitLab 13.3, PostgreSQL 12 has been available as an option for both Omnibus packages and our Helm chart. PostgreSQL 12 improves performance and also offers significant indexing and partitioning benefits.

Starting with GitLab 13.7, new installations of GitLab will use PostgreSQL 12 by default. To perform the update manually, run gitlab-ctl pg-upgrade.

Multi-node database instances will need to switch from repmgr to Patroni before upgrading with Patroni. You can then update and re-sync the secondary Geo nodes.

Valery Radokhleb
Valery Radokhleb
Web developer, designer

Leave a Reply

Your email address will not be published. Required fields are marked *