GitLab 13.5 Release

Add Delete buttons to the SSH tab of the Credential Inventory

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.

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

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 is coming in a future iteration.

Project access tokens for GitLab.com

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.

Required approval for new user registration

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

Automatically add To Do and Doing lists on new boards

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

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.

Deep-level wiki navigation

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.

Embed a YouTube video in the Static Site Editor

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 making it easier for you to embed a YouTube video with 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

Allow one dimensional parallel matrices

Previously, the parallel: matrix keyword, which runs a matrix of jobs in parallel, only accepted two-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 one-dimensional array, making your pipeline configuration much simpler. Thanks Turo Soisenniemi for your amazing contribution!

Here’s a basic example of this in practice that will run 3 test jobs for different versions of Node.js, but you can apply this approach to your specific use cases and easily add or remove jobs in your pipeline as well:

Limit the number of unit tests parsed per report

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-formatted 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 formatted-files in a build.

Pre-collapse sections in the job logs

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

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

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.

Auto DevOps code intelligence for Go projects

Auto DevOps code intelligence for Go projects

GitLab’s built-in code intelligence is a great way to easily add code navigation features to your project, improving your code review workflow with useful features such as type signatures, symbol documentation, and go-to definition.

As part of GitLab 13.5, automatic setup and configuration of code intelligence for Go projects has been added to Auto DevOps. Once you run a new pipeline you will be able to take advantage of GitLab code intelligence. As more languages become available as part of the LSIF standard, we plan to update Auto DevOps to support them. You can follow the code intelligence epic for future updates.

Create release with image digest on new tag

Create release with image digest on new tag

Docker supports immutable image identifiers and we have adopted this best practice to update our cloud-deploy images. When a new image is tagged, we also programmatically retrieve the image digest upon its build, and create a release note to effectively communicate this digest to users. This guarantees that every instance of the service runs exactly the same code. You can roll back to an earlier version of the image, even if that version wasn’t tagged (or is no longer tagged). This can even prevent race conditions if a new image is pushed while a deploy is in progress.

Enable gitlab-pages daemon to send precompressed br files

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.

Incremental rollout via AutoDevOps is compatible with Kubernetes 1.16

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.

Upgrade Auto DevOps to Helm 3

Upgrade Auto DevOps to Helm 3

Auto DevOps aims to bring outstanding ease of use and security best practices to its users, out of the box. Until now, Auto DevOps in Kubernetes environments required Helm v2 to be installed on the cluster. This presented a security risk given Tiller’s root access rights. With the introduction of Helm v3, Tiller is no longer a requirement.

The current GitLab version finally supports Helm v3 so you can rest assured you’re getting the latest and great functionality and security updates. In the case of a GitLab Managed Cluster, you can upgrade your Helm installation by following our documentation. Note that Helm 2 support is expected to end around November 2020.

Service Level Agreement countdown timer for incidents

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.

View alert integrations list

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’s now provides your teams a single list at Settings > Operations > Alerts for viewing and modifying alerting configurations.

Geo replicates external merge request diffs and Terraform state files

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

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

Bug fixes

Bug fixes

Some of the notable bug fixes in GitLab 13.5 are:

• NuGet packages with extended versions fail to upload
• Container Registry cleanup policy policy doesn’t remove images
• Reporter level not enough for browsing package lists
• Group-level deploy tokens fail on Maven group endpoint
• Go get fails with a 500 error for deep nested projects
• Can’t install Python packages when the package name contains a period
• Auto Deploy encounters an error when Legacy PostgreSQL instance exists
• “Preview changes” on New/Edit Release and New Snippet page doesn’t work
• Latest docker tag was not updated after latest release v0.4.0
• Various UI fixes to Threat Monitoring Policy Editor
• “Hide dismissed” toggle doesn’t work in Pipeline Security Dashboards
• Create issue from vulnerability generates empty issue
• SAST spotbugs setting SAST_JAVA_VERSION: 11 does not work
• SAST eslint with custom CA fails to write gitconfig
• Allow use of Project Access Tokens with Git
• Allow use of Project Access Tokens for instances that require Terms of Service acceptance
• Delete Project Access Token users after Tokens are deleted
• Epic filter doesn’t work with start date or due date sorting
• Issue Search by “Epic !=” doesn’t work
• Search returns unsorted results for eager loaded scopes
• Code search does not identify the correct blob of code in the search result
• Code link in the search result should use default branch name instead of commit hash
• Geo: Fix project/design/wiki repo unable to resync after storage move
• Geo: Fix wikis/designs with no repository on primary trying to sync over and over
• Geo: Fix package files view not working by default

Improved merge request experience for security scans

Improved merge request 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.

SAST configuration UI improvements

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/CD files. We believe that security is a team effort and this configuration experience makes it easier for non-CI/CD 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/CD setup. We will also expand access to this tool to GitLab Core users in an upcoming GitLab release.

Delete a value stream

Delete a value stream

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

Merge request analytics filter controls

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.

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

Provide minimal access to a top-level group

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.

Add requirements description

Add requirements description

Requirements Management improves productivity when it’s possible to add additional details such as verification criteria, acceptance criteria, and rationale from within your tool.

GitLab Requirements Management now supports users adding detail information and content to streamline managing their requirements in a GitLab Markdown-enabled description field for each requirement.

Remove issue labels with a single click

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.

Branch access control overrides Code Owners requirements

Branch access control overrides Code Owners requirements

Merge request approvals restrict how code is pushed to protected branches. It’s helpful for promoting code quality and implementing compliance controls. It’s useful to require Code Owner approval for specific branches, to prevent direct changes to files without a Code Owner’s approval. However, it lacks flexibility for use cases like automatically updating tags, versions, or deployment trackers on your default branch.

Now, if a user or group is designated as “allowed to push” in branch protection settings, they can push directly to a protected branch that is configured for Code Owner approval. Because branch protection settings are the main access control mechanism for GitLab projects, this setting now takes precedence over Code Owners settings.

Edit merge request description from the Static Site Editor

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

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

GitLab Runner 13.5

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:

• Allow user to set kubernetes local ephemeral storage requests and limits
• Provide a Docker image to auto-install GitLab Runner on a Google Compute virtual machine
• Introduce variable to indicate current build status
• Add labels to Docker cache volumes created by GitLab Runner
• Runner on Windows using bash as a shell passes paths with backslash \ instead of forward slash /

Bug Fixes:

• Fix: Repository for Debian ships 32-bit ARM binaries for arm64

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

Optional caching for failed pipelines

Optional caching for failed pipelines

When your pipeline fetches a lot of external dependencies (such as NPM), not having the option to cache dependencies on a failed pipeline means throwing away valuable cache that is otherwise unchanged by your code. Now you have the option to save the cache regardless of the job status, which can save time and resources when iterating on a failing pipeline.

Caching only when the job/pipeline succeeds is still the default. This prevents an uncleared cache of incomplete dependencies from causing subsequent pipelines to fail. But now you can decide when it’s safe to enable caching always, to support incremental builds and help speed up the process of getting to your first green pipeline.

Track PipelineArtifact Storage on Usage page

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

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.

Allow for easier roll back from alerts page

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.

Configuration option to allow Deploy Keys to push to protected branches

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.

Customizable namespaces for GitLab Managed Clusters

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.

Get started quickly with GitLab and Terraform

Get started quickly with GitLab and Terraform

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

Support Group Milestones to be associated with Project Releases in API

Support Group Milestones to be associated with Project Releases in API

If you’re a release manager working across multiple projects in GitLab, you often use Group Milestones to collect related items for a scheduled a release. You may have realized that GitLab Releases can be associated with a Project Milestone, but now you can associate a Group Milestone with a Project Release via the Releases API. As a release manager, this helps you and your teams work more efficiently when coordinating releases with milestones.

View Kubernetes Agents list

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

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.

Experimental Geo support for PostgreSQL high-availability

Experimental Geo support for PostgreSQL high-availability

Patroni is a solution for PostgreSQL high-availability which is available in GitLab as an experimental alternative to repmgr. One of the limitations of using repmgr with GitLab is that it does not allow the configuration of a high-availability PostgreSQL standby cluster on a Geo secondary. This configuration is important when a secondary is used as part of a disaster recovery strategy because it allows systems administrators to mirror the number of database nodes on the primary and secondary. This means that after a failover no additional database nodes need to be provisioned to regain high-availability.

Geo now provides experimental support for high-availability PostgreSQL configurations using Patroni. Due to its experimental nature, Geo’s Patroni support is subject to change without notice and not recommended yet for production use.

GitLab chart improvements

GitLab chart improvements

• Documentation has been added for the Task Runner chart. Task Runner is used for administrative tasks such as rake tasks and backups. The new documentation explains the settings that can be configured for Task Runner and provides usage examples.
• The CNCF Stable Helm chart repository is being deprecated on November 13th. In preparation for this, the Grafana chart is now pulled from Grafana Community Kubernetes Helm Charts.

PostgreSQL 12 availability

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.

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

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.

Performance improvements

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

In GitLab 13.5, our performance improvement efforts focused on Cache dataOffset and symlink when requesting zip files

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

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.