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

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.

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.

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

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.

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.

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.

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.

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

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:

• Cache dataOffset and symlink when requesting zip files
• Update vulnerability dismissal to not refetch vulnerabilities on dismissal
• Improve performance of the Roadmap view
• Geo: Improve performance of LFS objects queries

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.

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.

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.

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

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.

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.

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.

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.

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.

Bug fixes

Some of the notable bug fixes in are:

• [Auto Deploy encounters an error when Legacy PostgreSQL instance exists(https://gitlab.com/gitlab-org/gitlab/-/issues/262015)
• “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
• “Error fetching the vulnerability list” on Pipeline security report
• “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