gitlab 14

What’s new in Gitlab 14?

by | 25.07.2021 | Changelog

GitLab 14 is out and fans must be thrilled to know about all the new features along with all the fixes and removals. In this post, we will go through the many changes and improvements, bug fixes, and some remarkable deprecations. We will see all of that here.

So, let’s start.


Epic Boards

We see that Epic Boards aligns the teams and organizations by communicating the status of epics continuously. In the previous versions of GitLab, we can see the requirement to view and sort epics in a list to view the overall quality. Keeping epics up to date means making most of the changes through an epic’s detail page. Epic Boards enables us to visualize and refine all of our epics in one place, using a customizable, drag-and-drop interface that will be easy for any teammate to understand and collaborate.

Epic Boards are also a game-changer when it comes to managing and visualizing ideal epic workflows. It includes authoring workflow states (Draft, Writing, Done), DevOps workflow states (such as Planned, In Development, and Production), or any other mutually exclusive states we might model with scoped labels. Visualizing workflows with an Epic Board empowers us to increase predictability and efficiency.

Terraform module registry built into GitLab

We know that terraform modules play a vital role in building standard infrastructure components throughout an organization. Also, up to GitLab 13.12, GitLab users had to use either a third-party Terraform module registry, local modules, or Git-based modules. These options may work well, but they do not help with the distribution of the modules, and they lack proper versioning support, which in return introduces risks for module users.

The new update now extends our Infrastructure-as-Code offerings with a Terraform module registry. Now, we can use the Terraform module registry built into GitLab to discover Terraform modules with semantic versioning support for upgrades and maintenance. Moreover, we can also publish modules easily using GitLab CI/CD.

While following Terraform’s best practices, the new version now recommends developing each Terraform module in a dedicated GitLab project. For simplifying the transition to the registry, users can now host and publish multiple modules from a single GitLab repository. You can now learn more about publishing and consuming a new module by clicking here.

What's new in Gitlab 14?

Streamlined top navigation menu

GitLab 14.0 introduces a new streamlined top navigation menu to help us get where we are going with fewer clicks and are going faster. This unique, consolidated menu offers the combined functionality of the previous Projects, Groups, and More menus. It now gives us access to our projects, groups, and instance-level features with a single click. Also, we can see all-new responsive views improve the navigation experience on smaller screens.

Streamlined top navigation menu gitlab 14

Merge request reviews in VS Code

As a developer, we often spend the majority of your time working in your local development environment. When we’re assigned a merge request for review, this requires us to leave our editor and perform that review inside of GitLab. While conducting your review inside GitLab, we might also need to use our local editor to understand the changes.

GitLab’s new Workflow version 3.21.0 for Visual Studio Code now supports the complete merge request review process, including threads. To use it, we have to select the GitLab icon in VS Code to open the sidebar to display the Merge requests we are reviewing. Then we have to choose a merge request overview to view the complete details and discussions of that merge request.

The sidebar now also contains a list of all the changed files in the merge request. Selecting files opens a diff comparison for us to review the changes in VS Code. While viewing the difference, we can read feedback left on the files and create new comments by selecting a line number and creating our statement. All comments and feedback we provide in VS Code are available in the GitLab web interface, making it simple for us to perform our reviews in VS Code and other users to participate in GitLab.

The new update brings the complete merge request review process to us inside of VS Code.

Sidebar Navigation Redesign

GitLab is extensive, and it’s getting bigger. As we can see the introduction of new features and categories, navigating the densely packed left sidebar has become less intuitive.

In GitLab 14.0, we now can observe redesigned and restructured left sidebar for improved usability, consistency, and discoverability. The devs have moved some links to features around, split up elements in the operations menu into three distinct menus with improved visual contrast, and optimized spacing so all the menu items can fit comfortably on a smaller screen. The update intends better to match your mental model of the DevOps lifecycle and provide a more predictable and consistent experience while navigating your projects and groups.

gitlab 14

Editing of Wiki pages with the WYSIWYG Markdown Editor

Editing wiki content should be so much easier and more fun! Many GitLab wikis still use Markdown formatting, and for some users, Markdown is a barrier to efficient collaboration. In this release, we now have access to a rich, modern Markdown editing experience in your Wiki so that we can edit with confidence.

Instant feedback and visual editing tools help us make wiki editing more intuitive and remove barriers to collaboration. GitLab saves the changes as Markdown when we have completed editing, so users who want to edit the Markdown directly can do so. We can even type Markdown into the new editor, and it will automatically format the text as we type.

GitLab 14.0 now comes with the Content Editor into the Wiki with support for most of the basic Markdown content types such as headers, bold and italic text, along with lists, code blocks, and links. We will see full support for the entire GitLab Flavored Markdown specification will arrive in the upcoming releases.

Aggregation of identical DAST vulnerabilities into a single vulnerability

In GitLab 13.12 and earlier, we can see that each vulnerability found in a scan was listed individually for each URL to discover exposure for all DAST (dynamic application security testing) vulnerabilities. It could create many vulnerabilities when the fix was a single file or configuration change. For example, a server header now sent with every HTTP response would be reported on every page rather than reported as a single issue with multiple occurrences.

GitLab, with its new release, combines similar vulnerabilities found on multiple pages into a single reported vulnerability in the DAST report to reduce the overhead of managing exposures. The vulnerability details will now include a list of all the URLs to find the vulnerability, rather than individual vulnerabilities, creating a vulnerability list and dashboard for each page.

The new reporting functionality will not retroactively combine vulnerabilities found in previous scans. It will only apply to scans performed in GitLab 14.0 and later.

Cluster Management Project Template

We can see moving away from the CI/CD template-based approach for cluster management in this release. We can define cluster management as managing Kubernetes clusters to improve the availability of an application running on a cluster. Also, the old method hides too much of the logic with restrictions of customizations and extensions of our apps. With the new approach, we can easily create a cluster management project from a project template and fully control our applications. A project created by using the new template contains the code needed for cluster management jobs, including built-in support for several applications. We can easily extend the project to other applications and own them completely. Additionally, we can now install new applications using Helm v3.

In GitLab 14.0, we observe that the cluster management project supports only certificate-based cluster integrations. The devs are planning to add support for the GitLab Kubernetes Agent in the next release.

Prepopulating the CI/CD Pipeline Editor with an Initial Template

The pipeline editor in GitLab is now our one-stop-shop when interacting with CI/CD pipelines. Previously, when writing our first pipeline with the editor, we can see a presentation with a blank configuration. While it was beneficial for experienced pipeline authors, it will be a bit of a leap for those just starting.

In this release, we can experience if a project does not have a pipeline configured, the editor preloads a template and will show an example 3-stage pipeline. We can save and run this pipeline right away to see it in action in our project. Moreover, it also has comments that will help us understand the syntax and tips and hints to help us customize the template to match our needs. It is now much easier to get our first green pipeline!

Container Scanning Integration with Trivy

Gitlab container scanning now uses the Trivy engine by default. This change again provides customers with more timely updates of vulnerability intelligence, more accurate results, and support for a more significant number of operating systems. In the new update, users who run container scanning with default settings are switched seamlessly and automatically to the new engine. Users customizing the variables in their container scanning job should review the migration guide and make any necessary updates.

Leading time for Merge Requests at the Group Level

As part of the efforts to natively support DORA4 metrics in GitLab, the lead time for the merge requests chart is now available at the Group level with this update. This release is the extension of the work completed in GitLab 13.11. We can now use a chart that shows how long it takes to deploy merge requests to a production environment (not only in individual projects but aggregated across a group). The whole thing allows us to get a complete picture of throughput across multiple projects.


Horizontal navigation for project-level Value Stream Analytics

We can now see the stages in project-level value stream analytics in a horizontal layout. It helps in visualizing the flow of work through the steps of a value stream. It also gets a match with the navigation experience in group-level value stream analytics.

Identify provisioned users at the group level

In this release, we can see the addition of the ability to identify provisioned users and contributors. We see the display of a new Enterprise label against provided users. It helps users to identify accounts created via SCIM automation instead of accounts created manually by a user.

Improved Interface for Addition of Groups to the DevOps Adoption Table

The DevOps Adoption table with this new update provides insight into how many organization has adopted Gitlab with a comparison by group and subgroup. Previously, we could add no more than 200 groups to the table. Understandably, larger organizations can have thousands of GitLab groups. Again, we can now use a dropdown that is searchable for the addition of any subgroup to the table.

In addition, we can see that subgroups removed from the DevOps Adoption table in one group now no longer automatically get removed from the tables of other groups. As a result of the data migration done for this fix, we might need to re-add some subgroups manually to our tables the first time we revisit them.

Instance-level DevOps Adoption report enabled by default

In the new update, we can see the default allowing of the instance-level DevOps Adoption report. The DevOps Adoption report can also show which teams in any organization use GitLab for issues, merge requests, approvals, runners, pipelines, deploys and scanning. We can also compare GitLab adoption across our entire organization by adding groups to the adoption table. We can look at some of the ways by which someone can use the DevOps Adoption report:

Firstly, we have to verify whether we are getting the return on investment that we have expected from GitLab. Next, we can identify specific groups that are lagging in their adoption of GitLab to help them along in their DevOps journey. Again, we can identify groups that have adopted particular features, such as pipelines, and provide information to other groups interested in beginning with the elements.

The DevOps Adoption report is now also available at the group level. We can get adoption insights for our entire organization for SaaS users by viewing the DevOps Adoption report in your top-level group.

Enforcement of SSH key expiration by default

Now, expired SSH keys added to GitLab gets disabled by default. It helps to make our GitLab instance more secure. Previously, expired SSH keys added to GitLab get enablement by default, and we can use them unless explicitly disabled by an administrator.

This change affects the expired SSH keys used on GitLab. If our keys are expired or will expire soon, we need to update the key and any services using them.

Self-managed administrators can still allow expired keys, similar to how they can enable expired personal access tokens.

Track usage of Code Owners

Code Owners are an essential element of the code review process in GitLab. When we identify code owners clearly, contributors can determine who should review contributions to a file or repository. We can also use the Code Owners’ feature to initiate the process of approving a merger request. Now, you can track which teams in your organization are using the Code Owners feature in their development workflow.

If you would like to call the code owners ‘approval, set up the DevOps Adoption table with the code owners’ column to find the groups that have not yet found the feature so you can easily see which groups need help to get started. Alternatively, find influential coding groups for code owners and get tips and feedback. The DevOps Adoption table is available in the group and instance levels.

Set pronouns on GitLab user profiles

The new update added pronouns in GitLab user profiles. Pronouns appear next to usernames on the profile tab. You can decide if you can add pronouns to your profile or identify and add any pronouns you like without choosing a predefined list.

Without much involvement, GitLab seeks to help people use appropriate pronouns when responding to comments to respect human identity.

Slack Notifications for Wiki Edits including links to diffs

The Slack notification service can notify us when a user edits a wiki page. The Black Message gives us a helpful context for conversions, including a project, a page name, and a commit message. Sometimes, however, the commit message does not provide enough context, and you need more details on how the content has changed.

We can now click Compare changes to Slack message to quickly view diff, save time, and reduce confusion from vague or incomplete statements.

Editing Default Path and Project Name when Forking

Project download enables you to have an exact original copy to try, apply changes, and send donations to the parent project. Your forks should have meaningful words that explain their purpose, and if your project is different, you may need multiple forks for one project.

GitLab now supports editing a project name and a project slug directly when making a fork in this release. Now you can create multiple forks for the same project, each with a different name, all in one group!

Addition of ‘~‘ to supported characters for CI/CD variable masking

Secure handling of confidential CI / CD dynamics is appropriate. You can hide variable values in task logs with variable encryption, but GitLab only supports certain characters. We now support the flexibility of encryption with ‘~‘ value, which narrows the feature to help multiple secrets generated on other platforms of private providers.

Predefined CI/CD variable for environment action

Suppose you want to reuse text and configuration between feed functions using environment: keyword. In that case, it can be challenging to extract a specific character depending on the type of work performed by the delivery function. For example, environment: stop action can be a function that stops update_app, and you do not want your posting to work.

Now, the default value: action: available as CI_ENVIRONMENT_ACTION pre-defined CI / CD, making it easier than ever to configure a single script that can work for all deployment tasks.

Identify which jobs triggered downstream pipelines

Previously, when looking at the pipe view, it was difficult to determine which function created the underground pipe. Starting at 14.0, all pipes at the bottom of the river show the name of the work it has created. This process makes it easy to track the flow of heavy pipes that form the bottom pipes.

Installation of PyPI packages from your group or subgroup

You can use the Package Registry for your project to publish and install PyPI packages. When installing a PyPI package, you must specify in which the package resides. This thing works best if you have a few projects. If you have many projects included within the group, you may find yourself adding lots or even hundreds of different sources.

In large multilingual organizations, it is common for a group to publish packages in the Registry Package of their project alongside source code and pipelines. However, they should also be able to incorporate dependence from other projects within their organization easily. You can now import packages from your group, so you don’t have to remember which package resides in a particular project. To do this, use a simple API to specify a package:GET groups/:id/package/pypi/files/:sha256/:file_identifier.

You can also write the output to the file or restore the package description as an HTML file.

Delete associated package files via UI

We use the GitLab Package Registry to publish, install, and share your dependencies. When we publish dependency, it generates multiple files, including package archive. Before GitLab 14.0, to delete those files, you had to use an API. In GitLab 14.0, we can now use the UI to delete files related to a given package and the package itself.

Since maintaining a legal registration can be a challenge, Gitlab’s goal is to make the process easier and more efficient for us by adding some options to delete unused files.

Security report generalized details structure

Automatic security scanning is an essential part of any secure development process. Various tools and technologies integrate the entire SDLC from source code scanning to post-post deployment and scanning infrastructure. While the ultimate goal of these tools is to detect known and potentially dangerous risks, the data from any given scanner can vary greatly. Attempts to quantify scanning data exist but tend to focus on one phase of scanning technology or a specific set of tools. It also poses a significant challenge for security teams who need to compile a comprehensive list of scanner findings. Aside from the consistent approach to standardization, looking at the unique details of each scan can be a matter of great apples and oranges. And when we do not include the toolkit, the results are often updated in the source tool, leaving the actual risk image compromised and sitting outside the entire DevOps toolbar.

A new set of standard data in our security reporting systems could close this gap. You can now integrate multiple security scanners into GitLab with minimal effort. You can now proceed with the rich formatting options for data acquisition. Our new layout makes it easy to draw the results of many of the tools available in our JSON reporting formats while adding a consistent presentation concept automatically. Flexibility without eliminating the ability to provide rich risk information is the main goal behind the new building. Information is provided in an open format using predefined data types. The models mentioned above handle both data validation and default UI presentation within GitLab. For example, we provide genres such as Integer, URL, Table, and GFM (GitLab Flavored Markdown). This genre allows the presentation of seamless control over how to access information while maintaining a complete experience within GitLab consistently.

Pin to Specific SAST Analyzer Versions

With the maturity of GitLab’s secure scanning tools, we needed to add more granularity to our extraction process. Earlier, GitLab shared several major versions of all our analysts and tools. It requires all direct sharing tools and prevents the use of semantic type numbers. Starting at 14.0, GitLab SAST removed the global variable for SAST_ANALYZER_IMAGE_TAG in our [SAST.gitlab-ci.yml](<>) CI template that favours analyzer function variability by setting a ‘big’ tag. Each analytics function now has a SAST_ANALYZER_IMAGE_TAG variety that GitLab will actively manage and set to the ‘big’ label of the appropriate analyst. Attaching to a particular version changes the variable value of a specific tag of the performance. If we override or maintain custom versions of SAST.gitlab-ci.yml, we have to update our CI templates to stop targeting the SAST_ANALYZER_IMAGE_TAG of the world and move it to the analysis activity tab. We strongly encourage you to acquire our managed CI templates further to verify your future CI templates further. This change will allow you to control more the granularity of future analyst updates with a larger pinned version.

Static Analysis Analyzer Updates

The GitLab Static Analysis contains multiple security analysts that the GitLab Static Analysis team manages, maintains, and updates. Below we can see the analyzer updates released during 14.0. These updates can bring additional coverage, bug fixes, and improvements.

Semgrep got updated to version 2.8.0 – MR, Changelog

  • Unstructured queue numbers for most common normal mode
  • SAST_EXCLUDED_PATHS transferred to semgrep to uninstall when starting semgrep
  • Performance adjustment

Enter the URL in the primary legal identifier in the report to link to the default rule

GoSec got updated to version 3.1.0 – MR, Changelog

  • Unsubscribe SAST_GOSEC_CONFIG, withdrawal notification
  • Install COMPILE variables to support skip download dependencies when you wish
  • Add GOSEC_GO_PKG_PATH variables to give you the option to set your destination to build an app
  • Update download depending on download packages only and not build/install automatically

We can see that Flawfinder got updated to version 2.0.17 – MR, Changelog

Again, SpotBugs got updated to version 2.28.3 – MR, Changelog

  • This update brought updated dependence.

Also, PMD-Apex got updated to version 2.12.3 – MR, Changelog

  • Through this, we can see Improved legal accuracy and bug fixes.

Lastly, ESLint got updated to version 7.27.0 – MR, Changelog

If you install a SAST managed GitLab template ([SAST.gitlab-ci.yml](<>)), you do not need to do anything to get these updates. However, if you are over typing or customizing your CI template, you will need to update your CI configuration. If you want to stay in a particular version of any analyzer, you can now go to the smaller version of the analyst. Pinning the previous version will prevent you from getting automatic analyzer updates and type your analytics version into your CI template manually.

The Feature flag user list is now on its page

Previously, you had to navigate a separate tab at the bottom of the feature flags page to access the user list. This design hides the relationship between feature flags and user lists because user lists are featureless than feature flags. In this release, the list of users is now at the bottom of the Feature Flags page, which improves workflow and makes their relationships more transparent.

Change the type of problem

In some cases, you can wish to change the nature of the problem. For example, you may want to refer the matter to an event to ensure that your team handles the issue correctly. To change the type of problem, edit the problem and select the type of problem in the problem selection menu.

Update the event service contract timer name

The Incident Service Level Agreement (SLA) Timer, which got introduced in GitLab 13.5, indicates the time remaining until SLA violation occurs in the event. However, we had seen that the user had to refresh the page for updating the timer. Starting with GitLab 14.0, the timer updates vigorously every 15 minutes without the need for page refresh.

Container Scanner Integration with Grype

GitLab scanning tool can now use the Grype scanning option instead of the Trivy default engine. This tool gives users flexibility and choice in choosing their container scanning engine. We made a comparison of two open source scanners. However, since each scanner is different, you may want to make your comparisons to determine what is best for you. Users can try the Grype scanner with the CI CS_ANALYZER_IMAGE variable:

Database load rating submitted Free

GitLab’s database load balancer now enables the distribution of read-only queries to multiple data servers. For GitLab events with thousands of users, using an upload balancer can reduce the load on the primary database and increase responsiveness, resulting in faster page loading within GitLab.

Gitlab have removed the download balancer from Premium to Free to allow more users to benefit from this feature in this release.

PostgreSQL high availability in GA gets Geo Support

Patroni is a high-resolution solution for PostgreSQL, allowing the most accessible PostgreSQL cluster configuration in Geo secondary. This type of adjustment is essential when we use the second as part of a disaster recovery plan. It will enable system administrators to display the number of databases in the primary and secondary sites. The above means that there should be no other database nodes for maximum availability after the failover.

Geo now provides us with the most widely available PostgreSQL configuration support that is widely available using Patroni.

The new release improved the documentation, improved Patroni version 2.0.2, added support for measuring database data in the waiting clusters, and ensured that the pause command and re-start replica work with the Patroni representation.

Verification of Geo before re-syncing all projects

Geo Admin UI provides a Sync button for all projects. For clients with many projects trying to synchronize failed bins only, unintentionally initiating this option can cause significant delays in resolving the problem. We now display the verification mode whenever Resync All is re-selected. This small but adequate development of UX reduces the chances that managers will accidentally create synchronization of all their projects.

GitLab upgraded to Ruby on railway 6.1

In this release, we can see the upgradation of Ruby on Rails to version 6.1 to take better advantage of the latest software developments.

GitLab chart development

With GitLab 14.0, we can expect the minimum version of Kubernetes to be 1.16.

Previously, Kubernetes Agent Server (KAS) deployment had no way to specify imagePullSecret. This deployment will cause the K8 to fail unauthorized. Now, with pullSecrets available to download, the image is successful, and the Pods are starting.

The new update of GitLab 14.0 upgrades Cert Manager to 1.2.0.

GitLab 14.0 also upgrades Grafana to chart version to 6.9.1. Chart-deployed features of Grafana are now on par with Omnibus (on 7.5.5) and can also resolve a deprecation issue.

Performance bar shows usage of memory

The performance bar allows program managers and software developers to understand the functionality of the GitLab page.

Increasing the visibility of used memory is vital for software developers to improve the performance and user experience of GitLab. In this release, we added a memory field showing the amount of memory used and the items provided for the current application. If selected, we will see displaying of views with additional information. With this available information, software developers can detect memory issues earlier and improve features that work better for memory and performance.

Omnibus improvements

GitLab 14.0 includes the Mattermost 5.35.3, another alternative open source for Slack. Due to the introduction of the backend data structures required for the upcoming new features, the performance of the v5.35 release migration process is affected. Depending on the size, type and type of database, you should expect longer than regular development times. This change can vary from a few minutes (usual case) to hours (worst case, MySQL 5.x only). You should also expect a balanced and vital spike in CPU usage during this process. The post also provides more details on the impact of migration performance and mitigation strategies. V5.35.3 introduces a new file search feature and changes to the logic of generating passwords used during mass user login. Administrators must quickly reset all users’ passwords during the bulk import process, and they did not change their password has not even once. v5.35.3 contains high-quality improvements and more recommendations for improvements.

Previously, the new GitLab scenarios would upgrade users to the original root password automatically after installation, which meant that an anonymous user could get there first to set the root password and control it. Now, we can randomly see the original root password creation if the user does not provide one. This creation enhances the automatic security of newly installed GitLab environments.

The Omnibus GitLab docker image now features BusyBox but removes vim and nano as pre-installed editors. BusyBox includes various other tools, and by making our BusyBox default editor, we find many other valuable tools when fixing an error inside a container.

Redesign for Geo sites dashboard

Geo duplicates and validates many types of data. Program managers need to monitor the health of their Geo locations to determine if any issues need attention, such as failed syncing projects or checksum mismatch. Gitlab’s UX study found that managers who use the Geo admin page sometimes have difficulty finding the information they need and that the information displayed can be confusing. Our redesigned Geo Sites dashboard addresses these painful points. We have added some beneficial indicators such as synchronization and summary data types verification and verification rate bars for data type items. We’ve also improved the page’s layout, reducing the number of clicks needed to generate meaningful information.

Location of Project Storage available in REST and GraphQL APIs

With the introduction of Hash Storage, it was challenging to find a place to store the projects. Program managers could figure out a path in the project UI, but it would not be possible to do this for most projects. Gitlab has added the final API archives where we can see display project storage information in this release. In the REST API, we can see that the new endpoint is GET / projects /: id / storage. In GraphQL, we can now find the availability of the diskPath field in the Repository object.

Bug Fixes

We see many bugs fixing in the new release. We will have a look at those.

In an ongoing situation, we can now catch cleaning policies. Also, the job filter in the Vulnerability Report throws an error in the team-level dashboard, and it got a fixing. Also, the scanner filter on the pipe safety tab now filters the results. The new update brings the fixing of Dockerfile Misleading finding no error in scanning the container. The bug that broke daily updates to check containers got a fixing along with the cilium 1.8.1 chart, which now performs well in the latest versions of GKE. The shared search bar now allows you to select multiple labels. For VSA, we can now add new label filters after removing label labels and also, we can now remove or edit a persistent category.

DevOps Adoption tooltip now does not display incorrect data. For Production Statistics, we can see that the Trendline chart now can load because of defined answers. Again, the filter label will now work for Slack notification integration, and also, diffs_metadata does not return 500 errors. We can now edit MR in untested integration mode and are also able to view the old versions of the merge request. With this update, “Blocking MR authorization by author” is ignored unless checked, saved, and not checked. With the new update, SSH expiration key notification emails now send SSH expired keys. We can now permanently index projects and use a lot of resources. The merger request reference is now valid for global search results. The “Cancel Pipe” button will not be visible to users without permission. In Gitlab 14.0, external_conference_only applications and invalid changes got the fixing they need, and optional requirements will not give any error in the pipeline view. We can now use the correct Gitpod URL in user preferences for the conditions under our control. We can also see the adjusting of GitLab with incoming_email check rake activity after changes to 13.12. The new update removed the extra character from the description field in the value field. It will also prevent Desk Service emails from being rejected when using a unique project annex. We can again see the fixing of some filters that do not work with the GraphQL board list. We can enable notification changes for projects where they may have previously been. GraphQL EpicsResolver will now handle time disputes. Gitlab will now provide mermaid stateDragram-v2 with state description. We can also see a delay in updating the open application for integration and removal of mathematical badges in Geo secondary

Performance improvements

Throughout the release, the devs have continued to build highways to improve GitLab performance. In GitLab 14.0, we see post-performance improvements for obstacles, projects, large stones, and much more! Other enhancements to GitLab 14.0 includes the progress of the performance of the Merge Request List API under upload. Also, UpdateMergeRequestsWork can cost, and N + 1 release in the specified epic. We also see enabling of captions for using filter cache and enabling of labels to apply filter cache.

Usability enhancement

Throughout the release, Gitlab has worked to improve the overall performance and usability of our product. Now, we have a gallery of UI Polish to track essential updates in our frameworks. These updates, while usually slight, improve your user experience. In GitLab 14.0, we see the posting of usability problems, projects, large stones, and much more! We highlight the following changes to GitLab 14.0.

The changes include group overview statistics where we can insert a metric card in one form. We can now see package-related hashes and make the “Start / Add Merge Train” button red when the latest pipeline in the merge request failed.


NFS required for Git repository Storage deprecated

With the regular acquisition of Gitaly Cluster (introduced in GitLab 13.0), we have slowed down the development (bugfixes, performance improvements, etc.) of the NFS GitLab storage GitLab 14.0. We will continuously provide NFS technical support to Git archives throughout 14.x but remove all NFS support from GitLab 15.0. Gitaly Cluster offers excellent benefits to the customers, such as variable recurrence factors, firm consistency with the distribution of the power of learning.


Breaking changes to Terraform CI template

GitLab 14.0 did update the Terraform CI template to its latest version. The new template is designed for GitLab Managed Terraform status, based on GitLab terraform-images, to provide a better user experience about GitLab’s Infrastructure-as-Code features.

Stable and current templates are not compatible, and the latest template becomes a standard template starting with GitLab 14.0. Our Terraform pipeline may experience unexpected failures when performing custom init work.

Code Quality RuboCop support changed

By default, the quality code feature did not provide Ruby 2.6+ support when using the code quality template. To better support the latest Ruby models, the devs have updated the default version of RuboCop to add Ruby 2.4 to the 3.0 license. As a result, the removal of support for Ruby 2.1, 2.2, and 2.3. You can re-enable older versions by customizing your configuration.

One of the problems with the default codeclimate-rubocop engine does not support Ruby 2.6+

Container Scanning Engine Clair

Clair, an automated dishwasher engine, was downgraded to GitLab 13.9 and removed from GitLab 14.0 and replaced by Trivy. We advise flexible custom customers with their container scanning practices to follow these instructions to ensure that their container scanning operations continue to operate.

DAST environment variable renaming and removal

GitLab 13.8 has renamed several environmental variables to support its widespread use in different workflows. In the new release, the old variables have been permanently deleted and will no longer work. Any setting that uses these variables should get an update on new variables. Any scanning that uses these

changes to GitLab 14.0 and over time will fail to adjust appropriately. These changes are:








DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED will see a deletion because we have already seen the removal of this feature.

Renaming of Default Browser Performance testing in GitLab 14.0

We can see the usage of the browser performance test for a function called auto-operation. With the introduction of the Load Performance Test in GitLab 13.2, the term can be confusing. To clarify which process the Browser Performance Test is using, we can see the changing of the default username to browser_performance in the template in GitLab 14.0.

The relevant issue here is the renaming of the default job, which is Browser Performance Testing.

Default DAST spider crawling at target URL

In GitLab 14.0, we can see that DAST removed the current scan reset method on behalf of the host when launching the spider. Before GitLab 14.0, the spider did not start at the specified URL path but instead reset the URL to crawl the host root. GitLab 14.0 automatically converts new DAST_SPIDER_START_AT_HOST variables to better support users’ first scanning and scanning goal at a specified URL rather than the host root URL. This change has an added advantage: scanning may take less time if the set method does not have links to the entire site. It enables easy scanning of small parts of the app rather than crawling the app as a whole during every scan.

Default branch name for new repositories

All Git repositories have a first branch, which is automatically called master. It is the first branch to see the automatic building when we create a new storage location. Future Git types will change the default branch name in Git from master to primary. In collaboration with the Git project and the wider community, GitLab has altered the default branch name for new projects in our SaaS ( and your managed offerings starting with GitLab 14.0. It will not affect any existing projects.

GitLab has already introduced changes that allow us to change the default branch name for both the instance level (autonomous users) and group level (for both SaaS and independent users). We encourage you to use these features to set default branch names for new projects.

Removal of Deprecated GraphQL fields

According to the GraphQL withdrawal and removal process, the following fields that are the downgrading before 13.7 were removed entirely by 14.0:

Changes :: Todos :: MarkAllDone, Mutations :: Todos :: RestoreMany -: updated_ids

Changes :: DastScannerProfiles :: Create, Genres :: DastScannerProfileType -: global_id

Genres :: SnippetType -: blob

EE :: Genres :: GroupType, EE :: Genres :: QueryType -: vulnerabilities_count_by_day_and_severity

DeprecatedMutations (concern **) - AddAwardEmoji, DeleteAwardEmoji, ToggleAwardEmoji

EE :: Types :: Reduced Changes (concern ***) - Changes :: Pipes :: RunDastScan, Changes :: Disabilities :: Dismiss, Mutations :: Vulnerabilities :: RevertToDetected

Deprecations for Dependency Scanning

We can see several removals for Dependency Scanning take effect.

Previously, to uninstall the DS analyst, you needed to remove it from the default editors list and then use that dynamic DS_DEFAULT_ANALYZERS configuration in the CI template for your project. We found that it should be easy to avoid using a particular analyzer without losing the benefit of newly installed analysts. As a result, we can see the request to move from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS if available.

Previously, to prevent Gemnasium analysts from downloading a time-of-service advisory database, you needed a GEMNASIUM_DB_UPDATE flexible setup. However, we can see an incorrect spelling, and the naming is inconsistent with the similarity as BUNDLER_AUDIT_UPDATE_DISABLED. As a result, we ask you to move from GEMNASIUM_DB_UPDATE to GEMNASIUM_UPDATE_DISABLED if available.

External Pipeline Validation Service Code Changes

In cases where we control using an external pipeline verification service, we can reduce the range of error codes accepted by GitLab. The pipes do not work when the verification service returns the response code from 400 to 499. In GitLab 14.0 and beyond, piping 406: Unacceptable response code only.

Removal of Geo Foreign Data Wrapper settings

As announced in GitLab 13.3, we can see that the following configuration settings on /etc/gitlab/gitlab.rb were removed at 14.0:

Removal of geo_secondary ['db_fdw']

Removal of geo_postgresql ['fdw_external_user']

Removal of geo_postgresql ['fdw_external_password']

Removal of gitlab-_rails ['geo_migrated_local_files_clean_up_worker_cron']

GitLab OAuth implicit grant deprecation

GitLab reduces the full grant flow of OAuth 2 as we can see the delivery from OAuth 2.1.

At the new update of 14.0, we cannot build new applications with OAuth 2 unauthorized flow. Move your existing applications to another OAuth2 stream before the 14.4 release.

GitLab Runner helper image in Container Registry

At 14.0, we are now downloading the GitLab Runner assistant image from the GitLab Container Registry instead of Docker Hub.

GitLab Runner installation ignoring the skel directory

In GitLab Runner 14.0, we can see that the installation process will bypass the auto guide automatically when creating a user’s home directory.

Removal of Gitaly Cluster SQL primary elector

Now that Praefect supports the last general election strategy, we have removed the sql election strategy. The per_repository election strategy is the newest, which we can use automatically when no election strategy is specified.

If you have prepared a sql election strategy, you must follow the migration instructions before upgrading to 14.0.

Helm v2 support

Helm v2 got its official unveiling in November 2020, where we keep a stable list from Helm Hub shortly after that. With the new release, which includes the 5.0 release of the GitLab Helm chart, Helm v2 will no longer get any support.

Chart users need to upgrade to Helm v3 to use GitLab 14.0 and later.

Removal of Legacy feature flags

Inheritance feature flags are read-only in GitLab 13.4. GitLab 14.0 removes support for asset features flags, so we should submit them to the new version. We can do this by taking a note (screenshot) of the asset flag, removing the flag by API or UI (you do not need to change the code), and finally creating a new Feature Flag with the same name you have deleted. Also, make sure that the strategies and locations are similar to the flag removed.

Removal of Legacy storage

As announced in GitLab 13.0, we can see the removal of legacy storage in GitLab 14.0.

Limiting projects returned in GET/groups/:id/

To improve performance, we limit the number of projects returned from a GET/groups/:id/API call to 100. We can still see the replacement of the complete list of projects with a API call GET/groups/:id/projects.

Making pwsh the default shell for newly-registered Windows Runners

We can see that in GitLab Runner 13.2, PowerShell Core support has its addition to the Shell asset filter. At 14.0, PowerShell Core, pwsh is now the default shell for newly registered Windows Runners. Windows CMD will be available as a Shell option for Windows Runners.


Up to GitLab 13.9, if you wanted to avoid using one GitLab SAST analyzer, you had to remove it from a long series of analysts in the SAST.gitlab-ci.yml file can use that to set the [SAST_DEFAULT_ANALYZERS](<>) variable in the CI file of your project. If you did this, it would leave you to new analysts of the future because this thread is hard to code the list of analysts to use. We avoid this problem by changing this dynamic concept to output without selecting default analysts. Starting at 13.9, we moved to SAST_EXCLUDED_ANALYZERS in our SAST.gitlab-ci.yml file. We encourage anyone who uses the SAST custom configuration in their CI project file to migrate to this new variation. If you have not signed up for SAST_DEFAULT_ANALYZERS, no action is required. CI / CD variables SAST_DEFAULT_ANALYZERS have been removed from GitLab 14.0, released June 22, 2021.

Removal of new Terraform template version

As we continue to improve GitLab’s Terraform integration to reduce customer disruption, we now maintain two GitLab CI / CD templates for Terraform, such as the “latest” template, updated regularly during minor GitLab releases (such as 13.10, 13.11, etc.). We can also see the removal of the template for the “major version”, which only gets an update on significant releases (such as 13.0, 14.0, etc.).

In all significant GitLab releases, the “latest version” template becomes the “major version” template, which inherits the “latest template”. As we can see many added new features to the Terraform integration, a new set of “major version” templates can be considered a significant change.

The latest template now supports the Terraform Merge Request widget and does not require any additional settings to work with the state-owned GitLab Terraform.

To view a new change, see the new “Large” template.

OpenSUSE Leap 15.1

We see the reduction of OpenSUSE Leap 15.1 support. We see a decrease in support from 15.1  by 14.0. We now provide support for OpenSUSE Leap 15.2 packages.

PostgreSQL 11 support

The minimum requirement is PostgreSQL 12 for Gitlab 14.0. It offers significant improvements in indexing, classification, and general operating benefits.

Removal of deprecated trace parameter from a jobs API endpoint

GitLab Runner has been upgraded to GitLab 13.4 to configure the internal tracking parameter to move to /api/jobs/:id. We have to ensure that our version of GitLab Runner matches our version of GitLab to ensure consistent performance.

Removal of legacy fields from DAST report

As part of the migration to the standard report format for all secure scanners at GitLab, DAST changed the DAST JSON report. Specific asset fields were reduced by 13.8 and entirely removed by 14.0. We see the creation of these fields by @generated, @version, site, and spider. This creation should not affect any normal DAST function, but it does affect users who eat the JSON report automatically and use these fields. Anyone affected by these changes and need these fields for business reasons must open a new GitLab issue and explain the need.

Removal of legacy storage for GitLab Pages

To make the GitLab Pages work with the cloud, starting with GitLab 14.0, we can see the conversion of the storage technology used by GitLab Pages to the newly launched ZIP storage.

Moving to the new ZIP archive building is designed to be automatic; however, if you see 404 Not Available on other pages after migration, automated migration may have failed. To facilitate this change in ZIP storage, we have provided a temporary flag for use_legacy_storage from GitLab 14.0 to 14.2, but the devs will remove it from GitLab 14.3. This flag will allow GitLab and its pages to use non-ZIP posts to feed content.

Removal of release description in Tags API

GitLab 14.0 removes its support for the release description in the Tags API. We can no longer add a release description when we create a new tag. And we will no longer be able to make or update releases with Tags API. We are requested to relocate using the Releases API.

Removals for License Compliance

In 13.0, Gitlab deprecated the License-Management CI template and renamed it License-Scanning. They have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, they are completely removing the License-Management CI template.

Removal of DAST default template stages

In GitLab 14.0, we removed the sections defined in the current DAST.gitlab-ci.yml template to avoid situations where the template overrides changes made by DAST users. They made this change in response to customer issues because sections in the template create problems using DAST’s custom configuration. As a result of this removal, the gitlab-ci.yml structure that does not specify the dast category must get a renewal to include this category.

Removal of SAST analyzer SAST_GOSEC_CONFIG variable in favour of custom rulesets

With SAST Custom Rulesets in GitLab 13.5, Gitlab will allow for greater flexibility in selecting our Go Analyzer (GoSec) configuration options. As a result, Gitlab will no longer plan to support their [SAST_GOSEC_CONFIG](<>) analysis setting. We see the reduction of this conversion to GitLab 13.10. GitLab 14.0 now removes the old SAST_GOSEC_CONFIG variables. If you are using or overwriting SAST_GOSEC_CONFIG in your CI file, update your SAST CI configuration anywhere in the old version of GoSec Analyst. Gitlab strongly encourages everyone to acquire and further our managed CI templates to verify your future CI templates further.

Removal of Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached the end of the service on Friday, July 17, 2020. With GitLab Runner 14.0, Ubuntu 19.10, or Eoan Ermine will no longer be available to distribute their package.

Removal of /usr/lib/gitlab-runner symlink from package

In GitLab Runner 13.3, we have seen the addition of symlink from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we can see the removal of symlink and the runner is now installed in /usr/bin/gitlab-runner.

Removal of ?w=1 URL parameter to ignore whitespace changes

To create a consistent user experience based on their preferences, the support for toggling whitespace changes via URL parameter got removal in GitLab 14.0.


In 14.0, Gitlab has deactivated the FF_RESET_HELPER_IMAGE_ENTRYPOINT feature flag.


In GitLab Runner 13.1, we have seen the introduction of sigterm and then sigkill to a process in the Shell executor. Gitlab also raised a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, to use the previous process termination sequence. In GitLab Runner 14.0, we can see the removal of the feature flag.


In the new release, GitLab Runner 14.0 removes the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag.

Removal of secret_detection_default_branch job

To ensure confidentiality by scanning the default branches and feature branches, Gitlab has introduced two different CI secret detection functions (secret_detection_default_branch and secret_detection) in our template managed by Secret-Detection.gitlab-ci.yml. These two functions of the CI have created confusion and difficulty in the concept of CI rules. This download conveys the concept of the law in the script section, which will determine how the secret_detection function is performed (history, branch, commitment, etc.). If we overwrite or maintain custom versions of SAST.gitlab-ci.yml or [Secret-Detection.gitlab-ci.yml](<>), you should update your CI templates. Gitlab strongly encourages you to acquire the managed CI templates further to verify your future CI templates further. GitLab 14.0 no longer supports old secret_detection_default_branch.

Removal of disk source configuration for GitLab Pages

We can see that GitLab Pages API-based configuration has been available since GitLab 13.0. It now replaces the unsupported disk source configuration removed in GitLab 14.0, which we can’t choose. We should stop using disk source configuration and can move to gitlab for an API-based configuration. To have a migration away from the ‘disk‘ source configuration, we have to set gitlab_pages['domain_config_source'] is equal to “gitlab” in your /etc/gitlab/gitlab.rb file. Gitlab also recommends migrating before updating to GitLab 14.0 to identify and troubleshoot any potential problems before upgrading.

Removal of legacy DAST domain validation

The DAST Domain Validation asset path for CI / CD scanners was downgraded to GitLab 13.8 and removed from GitLab 14.0. This domain verification method only allows scanning if we set the DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED variables to true in the gitlab-ci.yml file, and the Gitlab-DAST-Permission header on the site is not under configuration to allow this. This two-step method requires users to select a variable function before exiting the header application.

Removal of off-peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, we can see the introduction of new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we can see the removal of the old configuration option, off-peak time mode.

Removal of redundant timestamp field from DORA metrics API payload

The deployment point of the API delivery project has seen a reduction due to the DORA 4 API, which covers all metrics under one API and specific metrics as a required field. As a result, the timestamp field, which does not allow future extensions and causes performance issues, will be removed. With older API, the sample response can be {" 2021-03-01 ": 3," date ":" 2021-03-01 "," value ": 3}. First key / value (" 2021-03- 01 ": 3) will be deleted and replaced with the last two (" date ":" 2021-03-01 "," value ": 3).

Removal of success and failure for finished build metric conversion

In GitLab Runner 13.5, we can see the introduction of failed and success states for a job. To support Prometheus rules, Gitlab chose to convert success/failure to finished for the metric. In 14.0, the conversion will now see a removal.

Removal of support for Windows Server 1903 image

In 14.0, Gitlab has removed Windows Server 1903. Microsoft also ended support for this version on 2020-08-12.

Removal of support for Windows Server 1909 image

In 14.0, Gitlab has removed Windows Server 1909. Microsoft also ended support for this version on 2021-05-11.

Removal of Global SAST_ANALYZER_IMAGE_TAG in SAST CI template

With the maturity of GitLab’s secure scanning tools, we needed to add more granularity to our extraction process. Earlier, GitLab shared several major versions for all analysts and devices. It requires all tools to share a larger version and prevents the use of a semantic type number. In GitLab 14.0, SAST removes the global variability of SAST_ANALYZER_IMAGE_TAG in our [SAST.gitlab-ci.yml](<>) CI template, favouring analyzer function variability sets a more significant tag. Minor in SAST sold commercial template.

Each analyzer function now has a SAST_ANALYZER_IMAGE_TAG variable, which GitLab will manage and set in the appropriate tag for the proper analyzer. Depending on the version you are translating, change the conversion value to the specific version tag. If you are overwriting or maintaining custom versions of SAST.gitlab-ci.yml, update your CI templates to stop targeting the SAST_ANALYZER_IMAGE_TAG global, and submit it to the scoped analyzer task marker. Gitlab strongly encourages us to acquire our managed CI templates further to verify your future CI templates further. This change allows you to control more the granularity of future analyst updates with a major.minor pinned version. These downgrades and deletions alter our previously announced system for pinning Static analytics tools.

Ruby version got changed in Ruby.gitlab-ci.yml

By default, we can see that the Ruby.gitlab-ci.yml file has included Ruby 2.5 in the update.

To fully support Ruby’s latest versions, we observe the template changing to use ruby: latest, which is 3.0.

The relevant issue here is the update of ruby version 2.5 to 3.0

Removal of Segments from DevOps Adoption API

The first issue of the DevOps Adoption report had the concept of Categories. The sections were quickly removed from this report because they introduced an additional layer of difficulty over the Groups and Projects. The subsequent review of the DevOps Adoption report focuses on comparing group acceptance rather than segment. GitLab 14.0 removes all references in partitions from the GraphQL API and installs them into enabled groups.

Removal of Service Templates

In the new update, we see the removal of Service Templates are from GitLab 14.0. It uses to apply the same settings to many projects, but they did this only during project construction.

While they were solving part of the problem, revising those numbers later became a painful point. Project Integration Management solves this problem by allowing you to create settings at a group or Instance level, with local name projects benefiting from those settings.

Sidekiq queue selector options will no longer accept the ‘experimental’ prefix

GitLab supports the line selector to use only the background set of background functions for a given process. This option had a ‘test’ start (experimental_queue_selector in Omnibus, experimentalQueueSelector on Helm charts) when launched.

With the announcement of 13.6 release posts, the ‘test’ start is no longer supported. Instead, we will see the usage of the Omnibus_selector line and lineSelector on Helm charts should.

Support for Ubuntu 16.04

Ubuntu 16.04 reached its end-of-life in April 2021 and will no longer receive maintenance updates. Gitlab strongly recommends users upgrade to a newer release, such as 20.04.

Removal of Unicorn in favour of Puma for GitLab self-managed

The new release brings the removal of support for Unicorn in GitLab 14.0 in favour of Puma. Puma has a multi-threaded architecture that uses less memory than a multi-process application server like Unicorn. On GitLab, we saw a 40% reduction in memory consumption by using Puma.

Updating Auto Deploy template version

In GitLab 14.0, we can see updating the Auto Deploy CI template to the latest version. It includes new features, bug fixes, and performance improvements relying on v2 auto-deploy-image. We can see the further reduction of the will of Auto Deploy CI template v1.

Since v1 and v2 are not compatible backwards, our project may encounter unexpected failures if we already have a used application. Follow the development guide to improve your locations. We can also start using the latest template today by following the initial discovery guide.

Updating the CI/CD templates to stop using hardcoded master

The new release will see that CI/CD templates have seen an update to no more extended use of strict code references in the main branch. In the release, they all use a variable that points to the tailored branch of your project. If our CI/CD pipeline relies on our built-in templates, make sure this change applies to our current configuration. For example, if we have a master branch with a different branch, template updates can cause a difference in our pipe behaviour.

Renaming of ‘WIP merge requests’ to ‘draft merge requests.’

The WIP (work in progress) status for several merge requests signalled reviewers that the merge request in question wasn’t ready to merge. Gitlab has renamed the WIP feature to draft a more inclusive and self-explanatory term. The draft communicates the merge request in question isn’t ready for review and makes no assumptions about its progress toward it. The draft also reduces the cognitive load for new users, non-English speakers, and anyone unfamiliar with the WIP acronym.

Web Application Firewall

Web Application Firewall (WAF) has been downloaded from GitLab 13.6 and removed from GitLab 14.0. The WAF had limitations in the construction of buildings which made it challenging to meet the traditional expectations of the WAF. By removing WAF, GitLab can improve other areas in the product to provide more value to users. Users currently relying on WAF can continue to use ModSecurity’s open and open source project, independent of GitLab.

Removal of CI_PROJECT_CONFIG_PATH in Gitlab 14.0

GitLab 14.0 removes the CI_PROJECT_CONFIG_PATH predefined project variable in favour of CI_CONFIG_PATH, which is functionally the same. If we use CI_PROJECT_CONFIG_PATH in our pipeline configurations, we have to update them to use CI_CONFIG_PATH instead.

Removal of CI_PROJECT_CONFIG_PATH variable

The new release removed the CI_PROJECT_CONFIG_PATH predefined project variable favouring CI_CONFIG_PATH, which is functionally the same.

If we use CI_PROJECT_CONFIG_PATH in our pipeline configurations, we have to update them to use CI_CONFIG_PATH instead.

Reliability and Performance

Webhook rate limiting on the website for GitLab Free

To improve GitLab infrastructure’s reliability and prevent abuse and configuration errors, we now use a 120 calls per minute rate limit for each webhook tailored to projects or teams. This limit now only applies to free users on We are also considering introducing higher limits for GitLab paid apps, which should still support the regular use of the webhook.

Free tier scheduled pipeline has a frequency limit on the GitLab website

Scheduled pipelines that run very frequently can affect the performance of In GitLab 14.0, we see limiting the frequency of planned pipelines to no more than once per hour per planned pipeline for Free tier users. Premium and Ultimate users will not get affected by this change.

Essential notes to users on upgrading to GitLab 14.0

We have to delete the old ElasticSearch migration. By removing the ancient migration of ElasticSearch, it will be easier to make Advanced Search migrations when you upgrade GitLab.

GitLab 14.0 will only support migration from GitLab 13.12. All previous versions should get an upgrade to GitLab 13.12 before upgrading to GitLab 14.0, the latest major version of GitLab, to complete the ElasticSearch migration.

Updates: We should upgrade to the latest GitLab 14 patch release (14.0.Z). This upgradation is necessary because at least two patch releases contain integrated back migration as part of our ongoing effort to address the risks of overcrowding of the main event. We should have the completion of this background migration before upgrading to the latest version of GitLab.

We must upgrade to PostgreSQL 12 before upgrading to GitLab 14.0. PostgreSQL 12 is a low-required version that starts at GitLab 14.0. We can see the removal of PostgreSQL 11 and is no longer officially supported. You will need to schedule a rest period for PostgreSQL development because the database must be down during the upgrade. If we use the PostgreSQL database provided by GitLab, you must ensure that your database is PostgreSQL 12 in GitLab 13.12 regardless of your input method.

Multi-node database settings will need to change from repmgr to Patroni before upgrading PostgreSQL and Patroni. Geo seconds can be updated and synchronized.

Before upgrading to GitLab 14.0, we should completely migrate to instant storage.

Before upgrading to GitLab 14.0, we should move to Puma.

Also, if you want to try out GitLab 14.0, click here.


The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts


Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

What’s new in Kuma v1.3.0?

What’s new in Kuma v1.3.0?

Kuma recently came with their new version of 1.3.0. It has come up with several bug fixes and new features with this update. In this article, we will see those fixes and new features which will make users have a great experience with the product. Buck up, and lets...

What’s new in Istio v1.11.3?

What’s new in Istio v1.11.3?

Istio came with its new version recently. It is a minor release, but it contains some significant changes and fixes. In this article, we will have a detailed look at what version 1.11.3 brings to the table. So, without wasting any time. Let's start! What is Istio?...

What’s new in Traefik v2.5.3?

What’s new in Traefik v2.5.3?

Traefik came with a new version of 2.5.3. This version mainly focuses on bug fixing and adding documents. This article will cover all of those entirely. It is not a big update, so this article will be short and crisp. Buckle up for a ride. Let's start! What is...

What’s new in Prometheus v2.30?

What’s new in Prometheus v2.30?

Prometheus v2.30 was released a few days ago, and it is an exciting update. This update is not very inclined on adding new features to the ecosystem, but it brings several enhancements to configurability and resource usage efficiency. It also brings several bug fixes....

Whats new in Python-Tuf v0.18.0?

Whats new in Python-Tuf v0.18.0?

Python-Tuf v0.18.0 recently came, and it is quite a big update with major and minor changes. We will go through all of those changes, additions, fixes and removals in this document. Without further a due, let's start! What is Python-Tuf? The Update Framework (TUF) or...

What’s new in Envoyproxy v1.19.1?

What’s new in Envoyproxy v1.19.1?

Envoyproxy came with its new version a few days ago. Version 1.19.1 comes with very few updates. It provides a few minor behavioural changes and a few bug fixes to make the user experience smoother. In this article, we will cover all of the new changes. Let's start!...