Available now on GitLab | GitLab
Oct 20, 2020
Available now on GitLab

The latest features available on GitLab SaaS

New features are regularly released to GitLab SaaS (GitLab.com), with a packaged release available for GitLab Self-Managed on the 22nd of every month. Read on to learn more about the new features available on GitLab.com. Note that it may take a few days for a feature to become fully available on GitLab.com, due to deployment schedule and potential feature flags.

Additional information on past releases is available; be sure to check out the release for other features we've launched recently. We also have information about upcoming releases if you're interested in seeing what we are doing next.

Key features released in GitLab Preview


Group Wikis

For many teams, using GitLab wikis for planning and documentation is a critical part of their workflow. Wikis are so popular that they get over a million views each month on GitLab.com. Despite this popularity, teams have struggled with the limitation that wikis were only available at the project level. Teams working on multiple projects needed to create separate wikis for each repository, leading to a fragmented experience.

In Gitlab 13.5, we are so excited to bring you group wikis! With 680 upvotes this was the most upvoted feature in the entire GitLab backlog. While highly requested, making a large project-only feature like wikis available at the group level has been a non-trivial operation. We’ve worked tirelessly over the past year to make it happen and now we can’t wait to get it in your hands and hear your feedback.

Group-level wikis open up tons of possibilities to keep your information at a higher level and accessible to a broader set of people. A few examples of what you can put in your group wikis include team-specific information, coding style guides, and designs for your brand or your company.

We know a lot of folks have been looking forward to this feature and shared their input pre-release. We hope all of you will continue to weigh in now that group wikis are available and we’ve opened up a dedicated issue for your feedback.

Group Wikis

Install the GitLab Kubernetes Agent with Omnibus GitLab

Last month we introduced the GitLab Kubernetes Agent for self-managed GitLab instances installed with Helm. This release adds support for the official Linux package. In this new Kubernetes integration, the Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to your cluster. You can learn more about how the Kubernetes Agent works now and check out our vision to see what’s in store.

Install the GitLab Kubernetes Agent with Omnibus GitLab

View cluster cost management data in GitLab

Many users created their own scripts to better understand their cluster costs, but now you can see an overview of your cluster costs and resource usage in the GitLab user interface. Our integration builds on Kubecost’s cost-model and gives you flexible insights into various levels of your clusters. Use the provided cost template to see your monthly node costs and the costs of your GitLab Managed Apps, or build more elaborate custom dashboards with the 9 metrics provided by Kubecost and the Prometheus query features of GitLab.

View cluster cost management data in GitLab

Merge request reviewers

Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? comment? chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. One option is to assign a reviewer to a merge request, but when both authors and reviewers appear in the same assignee field it makes it hard for other team members to know who’s doing what.

GitLab 13.5 introduces merge request “reviewers,” which allow authors to request a review from someone. The new “reviewers” field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request. This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.

Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center. You can follow along in the merge request reviewer assignment epic for more details.

Merge request reviewers

Enable instance-level shared runners when viewing groups

GitLab SaaS includes Linux and Windows runners, which are easy to use agents that run your GitLab CI pipeline jobs. These runners, visible in the GitLab.com UI as “shared runners,” are enabled by default and can be disabled for each project. However, some organizations require their CI jobs to run only on self-hosted runners, and so disabling the use of instance level shared runners on each project resulted in unnecessary administrative overhead. Now, administrators can enable or disable shared runners at the group level. Administrators can also allow groups to override the global setting and use shared runners on a project-by-project basis.

Enable instance-level shared runners when viewing groups

Trigger downstream or child pipelines with manual jobs

Previously, you were unable to configure a trigger job to wait for a manual action with when: manual. In this release, we’ve added this capability to give you full control on when to run a downstream pipeline.

Trigger downstream or child pipelines with manual jobs

Launch Gitpod Workspaces directly from GitLab

Engineers have complicated development environments that can take time to setup and make testing changes or exploring new projects challenging. Often getting started with a project involves following documentation, installing dependencies, and hoping there are no conflicts with other services running. This process can be time consuming, error prone, and may not replicate the configuration accurately to test and contribute to a project. With Gitpod integrated into GitLab, you can easily launch your Gitpod Workspace directly from the GitLab interface. When editing a project on GitLab a new dropdown option exists to open that project in GitPod:

Launch Gitpod from the GitLab UI

Gitpod allows you to define your project’s configuration in code so you can launch a prebuilt development environment with one click. These environments are configured through a .gitpod.yml file inside of the project and include options for docker configuration, start tasks, editor extensions and more. This flexible configuration, which is part of the project’s code, allows developers to get started working on a project quickly.

Thanks to Cornelius Ludmann from Gitpod for contributing this!


Snippets with Multiple Files

Engineers often use Snippets to share examples of code, reusable components, logs, and other items. These valuable pieces of information often require additional context and may require more than one file. Sharing a link to multiple files or multiple Snippets makes it challenging for users to piece this context together and understand the scope of what is being presented.

In GitLab 13.0 we laid a foundation for Snippets by giving them version control support based on a Git repository. Version control and the history it provides are an important piece of context when looking at code and understanding its purpose, but it may not be everything. GitLab now supports multiple files inside of a single Snippet, so you can create Snippets composed of multiple parts. It broadens its use to endless possibilities. For example:

  • A snippet that includes a script and its output.
  • A snippet that includes HTML, CSS, and JS code, from which the result can be easily previewed.
  • A snippet with a docker-compose.yml file and its associated .env file.
  • A gulpfile.js file coupled with a package.json file, which together are used to bootstrap the project and manage its dependencies.

Providing all of these files in a single Snippet gives more options for the types of content that can be shared and the context that is provided when looking at them. We’re excited to see the types of content you will create and share using Snippets with Multiple Files!

Snippets with Multiple Files

Generic Package Registry

GitLab supports a wide variety of languages in our Package Registry offering. However, you may want to store other binary types in GitLab that are not yet supported. In 13.5, you now have the ability to add raw package feeds (like you could do in Nexus) to a Generic Package Registry. Looking forward, this feature helps create the foundation for Release Assets and will ultimately make it easier for you to package and release your software with GitLab.


Feature Flags Flexible Rollout Strategy

When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy. We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.

Feature Flags Flexible Rollout Strategy

Feature Flags made available in all tiers

In GitLab 11.4, we introduced Feature Flags. In GitLab 12.2, we introduced percent rollout and user ID Feature Flag strategies. In GitLab 13.1, we introduced Feature Flag user lists and support for multiple Feature Flag strategies per environment.

Earlier this year, we committed to moving 18 features to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release. Now, we’ve officially finished moving Feature Flags to our Core offering. We’re excited about making these features available to more of the GitLab community and seeing the positive impact it’ll have on your development workflow.


Template for Deploying to AWS EC2

To help you deploy to AWS Elastic Cloud Compute (EC2) more efficiently, we created a template that shows you how to get started. This template allows you to provision your own infrastructure by first leveraging the AWS CloudFormation API. You then push your previously built artifact to an AWS S3 bucket and deploy the content to an AWS EC2 instance.

Users can include the template in their configuration, specify a few variables, and their application will be deployed and ready to go in no time.


Attach binary assets to Releases

If you aren’t currently using GitLab for your releases because you can’t attach binaries to releases, your workflow just got a lot simpler. You now have the ability to attach binaries to a release tag from the gitlab.ci-yml. This extends support of Release Assets to include binaries, rather than just asset links or source code. This makes it even easier for your development teams to adopt GitLab and use it to automate your release process.

Attach binary assets to Releases

Customizing SAST & Secret Detection rules

GitLab Static Application Security Testing (SAST) and Secret Detection now support customizing detection rules. This allows GitLab users to change the vulnerability detection defaults to tailor results to their organization’s preferences. SAST custom rulesets allow you to exclude rules and modify the behavior of existing rules. Secret Detection now supports disabling existing rules and adding new regex patterns that allow the detection of any type of custom secret.

Custom rulesets can be defined by adding a new file to the .gitlab folder named sast-rulesets.toml or secret-detection-rulesets.toml containing customizations written in the correct notation. You can learn more about this file format and see examples in our documentation for SAST custom rulesets and Secret Detection custom rulesets. We intend to provide additional support for importing custom rulesets in .gitlab-ci.yml files in the future.

Customizing SAST & Secret Detection rules

SAST support for iOS and Android mobile apps

GitLab SAST now supports mobile applications including iOS apps written in Objective-C and Swift as well as Android apps written in Java and Kotlin powered by the Mobile Security Framework (MobSF). Initially this analyzer supports source code analysis but we intend to expand support for binary scanning of .ipa and .apk files in the near future. This feature was a generous contribution by the H-E-B Digital team. You can read more about integrating with GitLab Secure and view our Secure scanning integration documentation.

SAST support for iOS and Android mobile apps

Other improvements in GitLab Preview

Add Delete buttons to the SSH tab of the Credential Inventory

Managing your namespace includes ensuring you know who has access and how. To promote the security of SSH keys, you should be able to delete a user’s SSH key when appropriate. To support this control, we’ve added a delete button for self-managed administrators to delete these keys as needed.

Now you can manage your users’ SSH keys from the Credential Inventory from a single screen.

Add Delete buttons to the SSH tab of the Credential Inventory

Failed two-factor authentication sign-ins now captured in Audit Events

Full traceability and auditability of your GitLab namespace is critical to a successful security compliance program. It is important to know when a two-factor authentication attempt has failed, since it suggests that a user or bad-faith actor knows an account password but does not have access to the second factor device.

In GitLab 13.5, you can now evaluate the number of failed two-factor authentication attempts to help inform your decisions. You can find failed two-factor authentication attempts tracked in the Audit Events table at the instance level. Support for group level coming in a future iteration.

Project access tokens for GitLab.com

In GitLab 13.3, we introduced Project level access tokens for self-managed instances, allowing access to a project without the need to provision a new user. We are now making Project level access tokens available in GitLab.com! Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API and Git. Project access tokens will not increase the licensed seat count and are authorized as Maintainers. This new functionality will make programmatic access to GitLab easier, more secure, and less cost prohibitive.

Project access tokens for GitLab.com

Required approval for new user registration

To reduce the operational burden on GitLab administrators without compromising security, GitLab 13.5 introduces a new instance-level option to require admin approval for any new user accounts. This option is disabled by default but when enabled will require manual approval by instance administrators before users that completed the sign-up process can access the instance.

Remove issue labels with a single click

Removing a label from an issue used to require three clicks, fetching a fresh list of labels from the server, and using a search box to find the label you want to remove. This was unintuitive and inefficient, given that GitLab users remove labels from issues approximately 55,000 times per day. It may not be revolutionary, but you can now remove an issue’s label with a single click.

Remove issue labels with a single click

Deep-level wiki navigation

In GitLab 13.5, along with the release of group wikis, we have another huge improvement in how to view and navigate the file structure of a wiki.

Currently, it’s very difficult to see where you are or understand the structure of a wiki if you have multiple folder levels. This makes it difficult to navigate, find pages, and mentally map your information.

With this release, we’ve introduced wiki deep nesting in the sidebar so you can see all of your pages and navigate accordingly.

Deep-level wiki navigation

Embed a YouTube video in the Static Site Editor

GitLab 13.5 includes a new formatting option in the WYSIWYG mode of the Static Site Editor enabling you to embed a YouTube video in just a few clicks. After entering either the full embed URL or the YouTube video ID into the modal window, the Static Site Editor inserts the correct block of HTML at your cursor and displays a thumbnail of your video in the editor.

You no longer have to copy and paste the properly-formated HTML in order to embed a video in a Markdown file and you can edit your document in confidence knowing the video you included is correct. We’ve optimized this for YouTube video embeds but we’ll be working to add support for other services like Vimeo and self-hosted HTML5 videos in future releases.

Allow one dimensional parallel matrices

Previously, the parallel: matrix keyword, which runs a matrix of jobs in parallel, only accepted 2-dimensional matrix arrays. This was limiting if you wanted to specify your own array of values for certain jobs. In this release, you now have more flexibility to run your jobs the way that works best for your development workflow. You can run a parallel matrix of jobs in a 1-dimensional array, making your pipeline configuration much simpler.

Limit the number of unit tests parsed per report

There is now a limit to the number of tests that can be parsed from JUnit report format files that are uploaded in one build for use in the Test Summary and Unit Test Reports. For GitLab.com the maximum number of tests that can be parsed is 500,000 for all JUnit report format files in a build.

Pre-collapse sections in the job logs

Job logs often contain very long sections that make it difficult to parse when you are scanning the logs to find a specific piece of information. Now you can set job log sections to be collapsed by default. To make parsing much easier, simply add [collapsed=true] to your job scripts in your CI/CD configuration file as needed.

Validate expanded GitLab CI/CD configuration with the API

Writing and debugging complex pipelines is not a trivial task. You can use the include keyword to help reduce the length of your pipeline configuration files. However, if you wanted to validate your entire pipeline via the API previously, you had to validate each included configuration file separately which was complicated and time consuming. Now, you have the ability to validate a fully expanded version of your pipeline configuration through the API, with all the include configuration included. Debugging large configurations is now easier and more efficient.

More Conan recipe information on the Package Registry page

You can use the GitLab Conan Repository to publish and share C and C++ dependencies. But, when using the Package Registry user interface to find or verify a dependency, it was difficult to differentiate between different versions of a dependency. The user interface presented the name and version, but did not include conan_user or conan_channel. Both of these are often used to differentiate between different packages. For example, the below recipe would have been displayed in the UI as Hello version 1.0.

  • Hello/1.0@trizzi/stable
  • Hello/1.0@trizzi/beta
  • Hello/1.0@other_user/stable

Now, the entire recipe is displayed in the user interface, making it easier to find and verify the package you are looking for.

Improved SAST severity data for C/C++ and NodeJS vulnerabilities

When available from our security scan analyzers, GitLab Static Application Security Testing provides severity data for identified vulnerabilities. We recently updated our analyzers for NodeJS (nodejsscan) and C/C++ (flawfinder) to add support for severity data. This data will help increase the usability and accuracy of Security Approval Rules as fewer vulnerabilities will report ‘Unknown’ severity. In the future, we will augment other analyzers missing vulnerability metadata and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.

Improved SAST severity data for C/C++ and NodeJS vulnerabilities

Update nodejs-scan SAST analyzer to use njsscan v0.1.5

We have updated our Node.js SAST analyzer which adds 100+ new detection rules. This version also changes the detection rules to be powered by v0.1.5 of njsscan and semgrep which is now supported in our new SAST Custom Rulesets.

Update nodejs-scan SAST analyzer to use njsscan v0.1.5

Configuration option to allow Deploy Keys to push to protected branches

In release 12.0, we updated Deploy Keys so that keys with write access could no longer push commits to protected branches. As a workaround for this limitation, some users removed access restrictions to the master branch, leaving it unprotected and allowing all developers to push to master. This increases security risks, so in order to provide a better option we have decided to re-enable the previous behavior through a configuration setting.

Incremental rollout via AutoDevOps is compatible with Kubernetes 1.16

Clusters in GKE were automatically upgraded to Kubernetes v1.16 on October 6th, 2020. We updated Auto DevOps to support this version for incremental rollouts to continue working as expected. This upgrade affects users who continuously deploy to production using timed incremental rollout, and those who automatically deploy to staging but manually deploy to production.

Get started quickly with GitLab and Terraform

A new GitLab CI template enables you to set up Terraform pipelines without any manual work, lowering the barrier to entry for your teams to adopt Terraform.

Service Level Agreement countdown timer for Incidents

Service level agreements (SLA) are important to keep for customers. SLA breaches can cost you revenue, and decrease customer satisfaction and confidence, but it’s challenging to monitor SLA for multiple active incidents. The SLA countdown timer allows you to configure the length of your specific SLAs, and display SLA countdowns on Incidents to help ensure you meet your SLAs and keep your customers happy.

Service Level Agreement countdown timer for Incidents

View alert integrations list

Operations teams manage many alerting tools integrated into their central incident management platform. Managing and maintaining these tools and integrations is complex and confusing when configuration interfaces, auth keys, and important URLs are located in different places. Your GitLab project now provides your teams a single list at Settings > Operations > Alerts for viewing and modifying alerting configurations.

View alert integrations list

GitLab chart improvements

PostgreSQL 12 availability

In GitLab 13.3, initial compatibility with PostgreSQL 12 was launched, and it became available as an opt-in version in self-managed GitLab.

With GitLab 13.5, PostgreSQL 12 is now fully supported, including on deployments with Geo and PostgreSQL clusters. To use PostgreSQL 12 in a cluster, you must use Patroni for replication and failover. Using repmgr for replication and failover is not supported with PostgreSQL 12. For information on migrating from repmgr to Patroni, see Switching from repmgr to Patroni. For instructions on upgrading PostgreSQL in a Patroni cluster, see Upgrading PostgreSQL major version in a Patroni cluster. Note that major PostgreSQL version upgrades in a Patroni cluster require downtime.

PostgreSQL 12 will become the default version for new GitLab installations in 13.6. For upgrades of existing GitLab deployments it will become the default version in 13.7 with the option to opt out and stay on PostgreSQL 11.

Performance Improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!

In GitLab , we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab are:

Delete a value stream

In GitLab 13.3 we introduced multiple value streams per group into Value Stream Analytics. Now, you can delete any custom value streams created in your groups.

Delete a value stream

Merge Request analytics: filter controls

In GitLab 13.3 we introduced Merge Request Analytics, which helped you to more effectively evaluate the efficiency and productivity of your merge request throughput. 13.5 introduces filter controls to Merge Request Analytics. This helps you refine the scope of YOUR data within Merge Request Analytics based on filter criteria such as assignee, author, labels, milestone, or branch.

Merge Request analytics: filter controls

Provide minimal access to a top-level group

To help organizations using SAML SSO with finer grained access control, group owners can assign users a minimal access role. Users with minimal access can list the group in the UI and through the API. However, they cannot see details such as resources, projects or subgroups. This role can be set as the default role at provisioning time for SSO/SCIM or assigned to an existing user in a top level group.

Automatically add To Do and Doing lists on new boards

In most cases, teams will be best served by keeping their workflows as simple as possible. To encourage this and make the first experience with a board more efficient and approachable, creating a new board will now automatically pre-populate To Do and Doing lists so you can get straight to managing issues.

Synchronize iterations across subgroups & projects

Iterations are currently created at the group level and there is no way to view an iteration’s report within the context of a subgroup or project. This is problematic for organizations that operate according to the principle of least privilege. It also makes it difficult and confusing for a larger organization to use the same iteration cadence, while also providing a way for each group and project to track their progress. To solve this, iterations are now inherited down a group’s hierarchy, providing each subgroup and project the ability to view an iteration report scoped to the context in which it’s being viewed.

This change also allows organizations to have more flexibility and control over how they want to use iterations. You can configure iterations from the top-level group to align all groups and projects on the same schedule, or each subgroup can manage its own iteration cadence independently.

Edit merge request description from the Static Site Editor

Engineering best practices encourage you to include a concise title and description along with any changes you make to a file. The context provided is valuable during the review process and for documenting the justification or motivation for the change.

The Static Site Editor abstracts as much of the Git workflow away from the editor as possible. One way it does this is by using a default branch name, merge request title, and description. This makes for a simple, one-click submission but the resulting merge request lacks that critical context.

In GitLab 13.5, you can now include an optional—though strongly encouraged—title and description with your changes that will populate a more descriptive and useful merge request.

Mark merge request as 'draft' with a single click

Creating a merge request is a great way to share your contribution with others and get the conversation started, even if the code is not ready to be merged. In order to signal to others that a contribution is not ready to be reviewed/merged, you can prefix the merge request title with draft (formerly known as wip). This is useful, however, it entails going into edit mode, navigating to the merge request title, and typing the required prefix.

To make it faster to use this feature, we have introduced Mark as draft and Mark as ready buttons directly to the top-right corner of merge request pages (without having to edit its description to change it). With a single click, you can indicate that your work is in progress and not ready to be merged, and vice-versa.

Mark merge request as 'draft' with a single click

GitLab Runner 13.5

We’re also releasing GitLab Runner 13.5 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Bug Fixes:

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

Optional caching for failed pipelines

You now have the option to cache dependencies for jobs even if a pipelines fails, making it easier to fetch external dependencies (such as NPM). This helps speed up the process of getting to your first green build by caching these files even when you’re still iterating on a failing pipeline.

Track PipelineArtifact Storage on Usage Page

Following the initial release of PipelineArtifacts, there was a type of artifact that used storage but wasn’t tracked on your Storage Usage Quota page. This meant that you didn’t have an accurate representation of how much free storage was actually available.

Now both Job and PipelineArtifacts are represented by the Artifacts label so you know exactly how much space Artifacts are taking of your Storage.

Major improvements to the Container Registry cleanup policy

When using the cleanup policy for tags to remove unwanted tags from your Container Registry, you may have noticed that the tags aren’t always removed like you’d expect them to be. As a result, it’s likely that you had to manually intervene by using the GitLab API to delete registry tags in bulk, or you ignored the problem and subsequently experienced higher storage costs.

There are two potential issues that may have caused problems. The first issue is related to gitlab-#219915. This issue resolved a bug where some policies created in the user interface were failing, because the user wasn’t passed to the DeleteTagService.

In addition, you may have encountered an issue in which the policy ran, but only partially completed. This occurs when a policy attempts to delete many images and instead times out. If that happens, it will continue removing the tags in the policy’s next scheduled run. Moving forward, you will see a warning to signal that there are partially-run policies remaining. That way you can decide if you want to manually intervene or not.

We have several other improvements planned for this feature, including support for all historical projects and a preview of tags that will be removed.

Improved MR Experience for Security Scans

With SAST and Secret Detection now available to all users, we have improved the experience for all GitLab users interacting with Secure scan results in a merge request, making it easier for anyone to access Secure scanning findings. Security scan results previously were only accessible on the Pipeline Overview page and users had to know where to look to find them. Now all merge requests will show if there have been security scans run and help users find the job artifacts. We plan to continue improving this experience over the next few releases. This change does not modify the MR experience for Ultimate users.

Improved MR Experience for Security Scans

SAST configuration UI improvements

The GitLab SAST configuration UI tool has been extended to support additional setting options and can now update simple existing GitLab CI files. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab SAST. The tool helps a user create a merge request to enable SAST scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template and properly overriding template settings.

The Configuration UI now supports the configuration of specific SAST analyzer settings which allow organizations to tailor SAST results to their security preferences. The Configuration UI can now also update existing simple .gitlab-ci.yml files, allowing the tool to be used with projects that already have GitLab CI setup. We will also expand access to this tool to GitLab Core users in an upcoming GitLab release.

SAST configuration UI improvements

Allow for easier roll back from alerts page

When you receive an alert triggered from a deployment, it’s hard to immediately understand what happened because the alert is missing additional context. In this milestone, you can now click a direct link to quickly navigate to your related environment and get the context you need. This makes it much simpler to understand which environment needs attention. From the environment page, you can also easily view related deployments and rollback to a previous deployment if needed.

Allow for easier roll back from alerts page

Enable gitlab-pages daemon to send precompressed br files

If you are looking for ways to improve your GitLab Pages load times, we are excited to announce a great community contribution from feistel and Ambyjkl that adds support for Brotli compressed files. This helps lower the required bandwidth per page, improving your site load times.

Customizable namespaces for GitLab Managed Clusters

Users of GitLab Managed Clusters can now choose to use a single namespace per project, or a single namespace per environment, when creating clusters. While single namespaces per project simplified finding review apps, separate namespaces per environment can provide additional security.

View Kubernetes Agents list

GitLab now helps you manage your Kubernetes agents by displaying your agents and their configurations in the GitLab user interface. More insights and management tools for your agents are planned for future releases.

Timeline view for discussions on incidents

GitLab comments and threads are a great way to collaborate on incidents, but how can you understand everything that happened in a chronological order from threaded discussions? You can now view discussions as a comment timeline to help your team understand the sequence of events during a fire-fight, and hold an effective post-incident review.

Timeline view for discussions on incidents

Geo replicates External Merge Request Diffs and Terraform State Files

Geo now supports replicating External Merge Request Diffs and Terraform State Files to secondary nodes, allowing distributed teams to access them from the closest Geo node, which reduces latency and improves the overall user experience. Additionally, this data can also be restored from a secondary node when failing over to that node.

We currently don’t support verification of these assets but future support is planned.

Omnibus improvements

  • Additional functionality has been added for Patroni, the new solution for PostgreSQL replication and failover in Omnibus. The new restart and reload sub commands let you restart Patroni or reload the Patroni configuration on the leader database node without triggering an automatic failover. The revert-pg-upgrade command is now supported for reverting a PostgreSQL upgrade of a cluster managed by Patroni. Finally, use of the pg-upgrade command on a Patroni cluster has been validated.
  • SSL certificates can now be used for client authentication to the PostgreSQL database as an alternative to using passwords. You will need your own SSL certificate management solution to make use of this feature. For more details, see the Database Settings.
  • A package is now available for OpenSUSE 15.2. To access the package, visit the Install page. For information on end of support for OpenSUSE 15.1, see the deprecations section.
  • GitLab 13.5 includes Mattermost 5.27, an open source Slack-alternative. The newest release includes Mattermost Omnibus (Beta) for easy installation and maintenance of Mattermost, and security updates. Upgrading from earlier versions is recommended.

Deprecations

Default Browser Performance testing job will be renamed in GitLab 14.0

Browser Performance Testing currently runs in a job named performance by default. With the introduction of Load Performance Testing in GitLab 13.2, this naming could be confusing.

To make it clear which job is running Browser Performance Testing, the default job name will be changed from performance to browser_performance in the template in GitLab 14.0.

Relevant Issue: Rename default Browser Performance Testing job

Deprecation date: May 22, 2021

Deprecate Container Registry log formatters

Currently, GitLab supports text/json/logstash log formatting for app logs and text/json/combined for access logs. We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options: text (for development) and json.

Deprecation date: January 22nd, 2021

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Deprecation date: January 22nd, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to remove the redis.pool.maxidle and redis.pool.maxactive settings and add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused).

Deprecation date: January 22nd, 2021

Deprecate Container Registry proxy pull-through cache

After a recent survey of GitLab Admin, we’ve decided not to deprecate this feature.

The proxy section allows the Container Registry to be set up as a local mirror to an upstream repository.

Deprecation date: Postponed indefinitely

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Deprecation date: January 22nd, 2021

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Deprecation date: January 22nd, 2021

Deprecate pulls that use v1 of the Docker registry API

GitLab is disabling pulls via the Docker registry v1 APIs on January 22nd, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Deprecation date: January 22nd, 2021

End of support for CentOS 6

CentOS 6 reaches end of life in November 2020. GitLab 13.6 will be the last supported version for deploying GitLab on CentOS 6. You are advised to upgrade to CentOS 7 or 8. Visit the deprecated OSes page for more information on the supported distributions.

Deprecation date: November 22, 2020

End of support for openSUSE Leap 15.1

OpenSUSE 15.1 reaches its end of life in November 2020. GitLab 13.6 will be the last supported version for deploying GitLab on OpenSUSE 15.1. You are advised to upgrade to OpenSUSE 15.2. Visit the deprecated OSes page for more information on the supported distributions.

Deprecation date: November 22, 2020

Removals

GraphQL fields scheduled for deprecation will be permanently removed in 13.6

In accordance with our GraphQL deprecation process, the following fields that were deprecated in 12.x will be permanently removed in 13.6: Types::CommitType - :latest_pipeline, Types::GrafanaIntegrationType - :token, Types::IssueType Types::EpicIssueType - :designs, Types::MergeRequestType - :merge_commit_message, and Types::TimelogType - :date

Removal date: November 22, 2020

Changelog

Please check out the changelog to see all the named changes:

Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating

Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects gets access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license