Oct 22, 2020 - 转载自: GitLab.com - Thao Yeager  

GitLab 13.5 released with Mobile App Sec, Group Wikis, and more!

GitLab 13.5 released with with Mobile App Sec scanning, Group Wikis, Generic Package Registry, and much more!

One of GitLab’s core values is collaboration and it's a key part of DevOps. This month we have several features aimed at collaboration among your team, across your tools, and with your peers as part of the 60 improvements packed into this release.

Mobile application security scanning

Community contributions are one of the best kinds of collaboration! One of our customers embraced our security scanning capabilities to shift left and empower developers to find and fix security flaws, yet they also wanted the same abilities for iOS and Android mobile applications. Using our integration guidance, they brought MobSF into the merge request pipeline and the security dashboards alongside SAST and all the other GitLab security scan results.

For their contribution, Brian Williams and the H-E-B Digital team are this month’s MVP. This new Mobile SAST language coverage, combined with our existing fuzz testing for Swift and Java projects, now offers a valuable security testing solution for mobile apps.

Giving works both ways. Therefore, we have officially finished moving Feature flags to core, open-sourcing it for greater community engagement. This completes one more step of our plan to move 18 features to Core.

Group wikis and more!

Groups collaborate in many ways and we now offer a few more ways to do so. A feature long sought after is Group Wikis, with the most upvotes ever! Now you can have a central point of collaboration for your team at the group level. Accompanying this, you’ll find deep-level wiki navigation in the side bar for easier navigation.

Thanks to another community contribution, you can now easily launch your Gitpod Workspace directly from the GitLab interface.

A picture is worth a thousand words! During an incident, it can be hard to understand the sequence of events from threaded discussions. With the new Timeline view for discussions in incidents, you can toggle a timeline view of the discussion.

Snippets and templates aid sharing

Snippets facilitate code sharing among group members. Snippets with multiple files is now supported inside a single Snippet, so you can create and share complex Snippets composed of multiple parts. The sky’s the limit!

Templates promote best practices and consistency across teams. This month you'll find more templates such as a template for deploying to AWS EC2, a new GitLab CI/CD template for Terraform, and the new SAST configuration UI that enables the GitLab CI/CD SAST template for users without CI/CD experience.

Collaborating across tools

At GitLab, we want to play well with others. Whether it’s pulling in third-party security scanner results, or integrating with other DevOps tools, we want to meet you where you need us. Now with Generic Package Registry, you can store other binary types in GitLab that are not yet supported via raw package feeds and attach binary assets to releases, enabling release and build teams to effectively work in GitLab no matter what type of binary they are building in CI/CD.

Of course there's more!

These are just a few highlights from the many new features and performance improvements described below.

If you'd like to preview what's coming in next month’s release, be sure to check out the 13.6 release kick off video series where the Product Managers highlight key features coming soon. Our Upcoming Releases page is where you can find all of the juicy details of our roadmap. Here, you can comment and upvote existing issues and contribute new ideas!

极狐GitLab MVP badge

本月GitLab最有价值人物 (MVP) 是 Brian Williams (H-E-B Digital)

The H-E-B Digital Security Engineering team contributed a new GitLab Secure SAST Scanner integration which will add Static Application Security Testing (SAST) support for Mobile apps. This contribution adds a highly requested capability of SAST scanning for iOS and Android mobile apps coded in Objective-C, Swift, Java, and Kotlin.

We thank the H-E-B Digital team for their significant contribution that allows all GitLab customers to scan their mobile applications for security issues. Learn more about integrating with GitLab Secure.

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. However, 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 nine metrics provided by Kubecost and the Prometheus query features of GitLab.

View cluster cost management data in GitLab

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/CD 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/CD jobs to run only on self-managed 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, it was not possible to configure a trigger job to wait on a manual action. This made it challenging to configure either downstream or child pipeline triggers to wait for a user to click on them before running.

In this release, we’ve added the ability to add when: manual to trigger jobs. Use this keyword to make trigger jobs wait until you click on the play button. This gives you more control of your downstream and child pipelines, and they will only run when you want them to.

Trigger downstream or child pipelines with manual jobs

Launch Gitpod Workspaces directly from GitLab

Engineers have complicated development environments that can take time to set up 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. Try this today with the GitLab project which is already setup to work with Gitpod.

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 GitLab 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 allows you to attach binary assets making it easier for you to package and release your software with GitLab.

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

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.

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-ruleset.toml or secret-detection-ruleset.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

极狐GitLab 13.5 其他功能

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 is 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 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

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.

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

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:

One dimensional matrices example

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

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

Improved merge request experience for security scans

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.

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.

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.

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.

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.

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

View alert integrations list

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.
  • 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 GitLab 13.5 are:

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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

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.

Create release with image digest on new tag

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

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.

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

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

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 13.5, our performance improvement efforts focused on Cache dataOffset and symlink when requesting zip files


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, and logstash log formatting for app logs.
  • Text, JSON, and combined log formatting 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.
  • 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) settings.

Deprecation date: January 22nd, 2021

Deprecate Container Registry proxy pull-through cache

After a recent survey of GitLab administrators, 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.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

  1. Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
  2. If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

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


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
  • Types::TimelogType - :date

Removal date: November 22, 2020

Important notes on upgrading to GitLab 13.5

  • An issue has been discovered affecting some instances, where the upgrade to 13.5.0 generates an assertion error. This has been resolved in 13.5.1.
  • The default path for the Workhorse socket changed from /var/opt/gitlab/workhorse/socket to /var/opt/gitlab/workhorse/sockets/socket in 13.5. A gitlab-ctl reconfigure is required during upgrade to apply this change. If you use SELinux and have specified a custom socket path, see the upgrade documentation for some manual steps that are required.
  • The Puma Worker Killer RAM limits were raised to avoid frequent out of memory kills. This change can result in memory increase of around 20% on web nodes.
  • An issue was discovered in instance merge request approvals that affects self-managed users on versions 13.2.0 to 13.5.3. It allows project maintainers to modify MR approval rules even when an admin enabled the instance-level settings that are supposed to make the respective project settings read-only. We’ve deployed a fix to address this in 13.5.4 and later versions.