Jul 22, 2020 - 转载自: GitLab.com - Justin Farris  

GitLab 13.2 released with Planning Iterations and Load Performance Testing

GitLab 13.2 released with iterations for milestones, diff changes for wiki pages, PHP Composer package support, load performance testing, and much more!

GitLab 13.2 now helps teams streamline project planning with milestone iterations, collaborate better for faster feedback with diff changes for wiki pages, and improve overall performance/efficiency with load performance testing.

Streamline agile project planning and management

Managing workflows and planning tasks for different teams can add a significant amount of development disruption to your day. In releasing our Minimal Viable Change (MVC) of iterations to break down work into smaller, more manageable, chunks, we're lessening this disruption and making project planning easier – with many enhancements to come. If your team leverages Jira for project management, it's now easier for you to view Jira issues in GitLab because we believe that GitLab should play well with others and balance integrations with native capabilities. If you're using epics to plan and manage large projects, then you can now protect sensitive content with confidential epics. When you need to update several related epics, you can now bulk edit epics to reduce your "tab overload" and the number of clicks it takes to update.

Better collaboration for faster feedback

Clear communication is key to effective collaboration because it enables development teams to get faster feedback on changes before pushing them to production. The ability to diff changes for wiki pages now makes edit history comparisons between page versions quicker and simpler, similar to viewing files in a repository. Realtime feedback for .gitlab-ci.yml in the Web IDE makes updating your CI pipeline more efficient by enabling realtime linting and autocompletion. Now you don't have to remember all of the parameters when configuring your CI pipeline or switch contexts to get the information you need.

Designers are incredibly important members of the team and 13.2 includes great improvements to design management. It's now easier to find designs in an issue so it takes less time, and the official GitLab Figma plugin simplifies the process of uploading from Figma to issues on GitLab.com.

Improved performance and efficiency

13.2 delivers new updates to improve your team's efficiency and performance. You can now take advantage of advanced global search on GitLab.com, a capability that improves search relevancy, performance, and allows for group-wide searches across all projects directly in the UI. Application performance is a challenge every development team faces and now load performance testing in GitLab makes it easy to run custom load tests as part of your CI/CD pipelines to better understand how your application will perform under stress.

Nowadays, it seems like everyone is working from home and are "distributed" more than ever. GitLab Geo helps remote teams work more efficiently by using a local GitLab node, and now offers improved replication performance for projects to ensure local content is fresh. Last but not least, GitLab includes CI test results within Release Evidence for easy access in the event you need to provide compliance data or a more efficient way to show relevant changes to production during audit.

And much much more!

There’s never enough space to highlight all the great features in our releases. An important development for package management that's worth noting: GitLab now supports the PHP dependency manager, Composer, so you can discover, share, and install PHP dependencies using GitLab's Composer Repository with ease.

Here are several other cool features that you should check out:

If you'd like to preview what's coming in the next release, be sure to check out our 13.3 kickoff video!

Join us for an upcoming event

极狐GitLab MVP badge

本月GitLab最有价值人物 (MVP) 是 Jesse Hall

Jesse contributed the new Batch Suggestions feature which allows MR reviewers to group all suggestions made to a diff and submit them at once. Because each suggestion translates into a Git operation, submitting these individually could take a long time if there were a large number of suggestions. Submitting suggestions in batches has numerous advantages, including time savings, efficient CI resource utilization (only one pipeline for all suggestions), and preventing an overly noisy Git history.

Thank you Jesse for the great effort, patience, and persistence getting this one over the line. We greatly appreciate it.

Assign issues to iterations

Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments.

Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both.

This is the first MVC towards a longer term vision we have for empowering teams to more effectively use timeboxes to move from plan-driven to value-driven development.

We’d love to get your feedback and input on where you’d like to see Iterations go next!

Container Host Monitoring and Blocking

We’re pleased to announce the first release of Container Host Security. This initial feature, container host monitoring and blocking, allows security administrators to secure their running containers at the host level by monitoring and optionally blocking unexpected activity. Such activity includes process starts, file changes, or opened network ports. This feature uses Falco to provide the monitoring functionality and AppArmor and Pod Security Policies for the blocking functionality.

Official GitLab-Figma Plugin

Recently, the GitLab product design team and our open source Pajamas Design System switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow.

In 13.2 we launched the official plugin on the Figma directory:

Official GitLab-Figma Plugin

Cluster health monitoring now available in Core

To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. We want our metrics solution to be available to all GitLab users, so as part of our 2020 gift, we’ve moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface.

Cluster health monitoring now available in Core

Manage PHP dependencies with the GitLab Composer Repository

PHP developers need a mechanism to share and consume their projects’ dependencies. Composer is a dependency manager for PHP that allows you to declare the libraries your project depends on and it will manage them for you.

We are proud to offer a Composer Repository built directly into GitLab. PHP Developers now have an easier way to discover and manage their projects’ dependencies. By integrating with Composer, GitLab provides a centralized location to view those packages in the same place as source code and pipelines. PHP dependencies in the Package Registry will be listed under the All tab and not under a Composer-specific tab. We will iterate to improve this by adding a Composer-specific tab in an upcoming milestone.

Special thanks to @ochorocho, who has been a significant contributor to this feature. We could not have done it without his help and guidance.

Organize sensitive work into Confidential Epics

You can now organize a collection of related confidential issues into a confidential epic. For customers working in areas like finance, HR, or security, there is often a need to work on items that can’t be public or openly viewable. To better support customers managing multiple confidential issues that all roll up to a shared goal or project, we have expanded our confidential functionality to epics!

Organize sensitive work into Confidential Epics

GitLab Runner support for Linux on IBM Z

GitLab customers and contributors that use IBM mainframes are adopting modern DevOps practices and want to be able to run GitLab Runners directly on their hardware. Based on this growing interest to expand platform support for z/OS mainframes, we’ve included the first version of a GitLab Runner binary Docker and helper image that you can use to run and execute Continuous Integration jobs natively on the s390x architecture under a Linux on IBM Z environment.

GitLab Runner support for Linux on IBM Z

Code Owner Sections

In large organizations, independent teams may have a common interest in parts of the application, for instance, a payment processing company may have development, security, and compliance teams looking after common parts of the codebase. All three teams may need to approve changes. While Code Owners are applied based on which files are changed, only one CODEOWNERS pattern can match per file path.

In GitLab 13.2, Code Owner Sections allow each team to configure their own code owners independently. The section rules may be used for shared paths so that multiple teams can be added as reviewers, ensuring the right groups are reviewing relevant code will help with increased code quality, while getting feedback/reviews from the right reviewers will lead to increased efficiency.

Code Owner Sections

Bring Fargate support for ECS to Auto DevOps and ECS template

We want to make AWS deployments easier. In order to do so, we recently delivered a CI/CD template that deploys to AWS ECS:EC2 targets and even connected it to Auto DevOps. Scaling container instances in EC2 is a challenge, so many users choose to use AWS Fargate instead of EC2 instances. In this release we added Fargate support to the template, which continues to work with Auto DevOps as well, so more users can benefit from it.

Advanced Global Search now available on GitLab.com

Prior to this release, GitLab.com users who wanted to do a cross-project code search would have to clone the repositories and search locally on their machine, a time-consuming and frustrating task. With GitLab 13.2, Bronze and higher GitLab.com groups can now perform group-wide code searches directly in the UI, by using Advanced Global Search. Advanced Global Search adds the ability to search code across all projects in a group, improves search relevancy and performance, allows scoping, and enables Advanced Search Syntax. This will make the experience of searching for content in GitLab much more powerful, enabling users to more easily find their content.

Advanced Global Search now available on GitLab.com

We have added the ability to associate related issues with their respective feature flags. For example, you can link the issue that introduced the feature flag itself. That relationship is visible in the feature flag details and will make it easier to find the reasons why a flag was originally introduced. It will also make it easier to follow the issue’s milestone and status directly from the feature flag itself to get better visibility into the feature details.

View Jira issue list in GitLab

For organizations using Jira as their primary work tracking tool, it can be a challenge for contributors to work across multiple systems and maintain a single source of truth.

In this extension of our current Jira integration, project admins can now choose to display a list of Jira issues natively inside the GitLab project. This allows developers working primarily in GitLab to remain in flow, without having to reference a second tool for tracking what work needs to get done. Further planned enhancements include commenting, status changes (transitions), and more.

View Jira issue list in GitLab

Load Performance Testing

It is important to know how the applications you’re developing will perform under load. For example, do you know if your API can support 1,000 users concurrently? There wasn’t an easy way to test how changes in a Merge Request would impact baseline performance before you merge.

Now, you can make use of Load Performance Testing to run custom load tests. Out of the box Load Performance Testing will report what percentage of the configured Checks pass, the 90th and 95th percentile for Time to First Byte (TTFB) and the average requests per second (RPS). This makes it easy for you to compare the results against a common baseline and see the results directly in the Merge Request before deciding to merge your code.

Load Performance Testing

Managed application logs available in GitLab UI

When triaging an incident or validating the status of your service, you must be able to explore Kubernetes pod logs from across your entire application stack. Previously, the GitLab user interface displayed only the deployed application logs (logs that originate from the application you deployed to a cluster using CI/CD). In GitLab 13.2, you can now also search across your managed application logs directly from the GitLab user interface.

Managed application logs available in GitLab UI

Multiple Kubernetes cluster deployment in Core

Using GitLab to deploy multiple Kubernetes clusters with GitLab previously required a Premium license. Our community spoke, and we listened: deploying to multiple clusters is useful even for individual contributors. Based on your feedback, starting in GitLab 13.2, you can deploy to multiple group and project clusters in Core.

Multiple Kubernetes cluster deployment in Core

Create releases from .gitlab-ci.yml

In 12.10, we introduced a way for you to automatically create release tags from the .gitlab-ci.yml file. Now we’ve made it easier and more natural to use by exposing the release keyword as a step the GitLab Runner can parse. You no longer need to add a script to call the Release API to create a release. Instead, you can simply add the correct parameters to your CI/CD file.

Create releases from .gitlab-ci.yml

Include CI test results in Release Evidence

GitLab is expanding our 12.6 Release Evidence feature by adding CI test results. These job artifacts, generated by the pipeline, are automatically included in the release evidence JSON file. As an Ultimate user, you will be able to effortlessly provide an auditor or compliance process with the relevant changes to production. You can download the evidence JSON and show corresponding test results organically as a part of using GitLab without disrupting your normal workflow.

Dynamically generate Child Pipeline configurations with Jsonnet

We released Dynamic Child Pipelines back in GitLab 12.9, which allow you to generate an entire .gitlab-ci.yml file at runtime. This is a great solution for monorepos, for example, when you want runtime behavior to be even more dynamic. We’ve now made it even easier to create CI/CD YAML at runtime by including a project template that demonstrates how to use Jsonnet to generate the YAML. Jsonnet is a data templating language that provides functions, variables, loops, and conditionals that allow for fully parameterized YAML configuration.

Dynamically generate Child Pipeline configurations with Jsonnet

极狐GitLab 13.2 其他功能

Approval group changes in Audit Events

Audit events already capture changes made to merge request approvals. In 13.2, we’re completing the loop by adding details about the changes to approval groups. When changes are made to merge request approval rules, you should now see a more complete view of the changes.

Scope instance-level merge request settings to compliance-labeled projects

Previously, when an administrator configured the merge request settings in the Admin Area, all projects in the instance inherited those settings. This inheritance model was too broad for customers who wished to apply different, more flexible requirements to non-regulated projects. Now, we’re providing added flexibility by enabling administrators to specify the project compliance framework labels they wish to enforce these instance-level settings on. When selected, only projects with the corresponding compliance framework labels will inherit these settings and they will only be editable at the instance-level by administrators.

This feature allows compliance-minded organizations to ensure this critical separation of duties controls are not editable by unauthorized users, which would create a gap in their compliance posture. This is a feature for self-managed customers only for now, but we plan to extend this functionality to GitLab.com group owners as a necessary compliance control for maintaining separation of duties.

Scope instance-level merge request settings to compliance-labeled projects

Toggle enforcement of Personal Access Token (PAT) expiration

You can now toggle enforcement of PAT credential expiration when a lifetime limit is defined and met or exceeded by a personal access token. This optional enforcement provides flexibility to organizations for how they wish to manage credential rotations. This change is part of a larger solution to make credential management in GitLab both effective for organizations and friendly for developers.

Bulk edit the Epic for multiple issues from the Issues List

Often it is necessary to assign multiple issues to an Epic to organize work together. You can now bulk edit the epic assignment for multiple issues at once. You can do this from the Issues List, which reduces the number of tabs and clicks required to properly assign work to the right epic.

Bulk edit the Epic for multiple issues from the Issues List

Map Jira users to GitLab users when importing issues

When importing issues from Jira to GitLab, you can now map Jira users to GitLab project members prior to running the import. This enables the importer to set the correct reporter and assignee on the issues you’re moving to GitLab.

Map Jira users to GitLab users when importing issues

REST API support for reordering issues

You can now change the relative order of an issue via the REST API. Prior to this release, there was no way to programmatically reorder issues. This has been particularly problematic for API consumers trying to support custom Board interfaces, as it was not possible to change the relative position of issues.

Thank you @jjshoe for adding an endpoint in our public API to support this!

View the Epic feed by newest activity first

The default order of oldest-to-newest discussions and systems notes is incredibly helpful for some use cases, such as understanding the history of a given epic. However, it is much less helpful when teams are in triage and firefighting mode, as they have to scroll all of the way to the end of the epic to see the latest updates.

Now you can reverse the default order and interact with the activity feed with the most recent items at the top. Your preferences for epics are saved separately in local storage and are automatically applied to every epic that you view.

View the Epic feed by newest activity first

Configurable default branch name for new repositories

When creating a new Git repository, by default the first branch created is named master. In coordination with the Git project, broader community, and other Git vendors, GitLab has been listening to the development community’s feedback on determining a more descriptive and inclusive name for the default branch, and offering users options to change the name of the default branch name for their repositories.

GitLab now allows instance administrators to configure the default branch name for new repositories created through the GitLab interface.

Keep track of your activity in Designs

It’s important you get credit for the work you do on designs in GitLab! We’ve added activity for uploading, revising, and commenting on Designs to your user profile, group page, and project page! Keep track of your design operations at a glance.

Keep track of your activity in Designs

Optional Merge Request Approvals in GitLab Core

Code review is an essential practice of every successful project, and giving your approval once a merge request is in good shape is an important part of the review process, as it clearly communicates the ability to merge the change. For Core users, this is usually done by leaving a comment, or giving a thumbs up, but these forms of approval are easily lost.

In 13.2, anyone with Developer permissions to a project can approve a merge request in GitLab Core. This makes it obvious to reviewers how to give their approval, and makes it easy for maintainers to know when a change is ready to merge. Approvals are optional in GitLab Core and GitLab.com Free, but users of GitLab Starter and GitLab.com Silver and higher tiers can also require approvals to get code merged into the codebase.

Redirect wikis to Confluence Workspace

If you’re collaborating as a team with Confluence, it can be hard to keep track of both your Confluence Workspace and the GitLab Projects that you use it on. In 13.2, we’ve added a Confluence integration that links your project’s left sidebar directly to a Confluence Workspace in a new tab.

Redirect wikis to Confluence Workspace

Wiki page diffs

Often Git users heavily rely on file diffs to observe, review, and track changes to content. In GitLab 13.2, we’ve added support for viewing diffs on Wiki pages. You can seamlessly see line-by-line content changes between two versions through the wiki commit history.

Thanks to Steve Mokris and Greg for the contribution!

Wiki page diffs

Custom text for coverage badges

Projects that use multiple coverage badges, but are calculating different values for each, could only use coverage as the text for every badge. This made it cumbersome to figure out what that value means.

Now, as a project maintainer or owner, you can customize the text for coverage badges to better differentiate between multiple coverage badges displaying on your project.

Thank you to Fabian Schneider for the contribution!

Custom text for coverage badges

GitLab Runner 13.2

We’re also releasing GitLab Runner 13.2 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.

View and manage group Runners

You can now take advantage of a new group management user interface (UI) for managing your organization’s Runners. In this new UI, you can view, edit, pause, and stop any Runner that’s associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.

View and manage group Runners

Validation for tag Cleanup policy regex

You can regularly remove older tags from the Container Registry by creating a per-project tag cleanup policy. These policies are based on user-created regular expressions. Unfortunately the container_repository:cleanup_container_repository job that runs against these expressions has been experiencing error rates of 25%. The Gitlab::UntrustedRegexp job considers the regex to be invalid, and when a policy fails to run, no one is notified.

We have taken the first step in resolving this issue. GitLab now validates the regex with the re2 library, so you can’t save an invalid pattern. We also added some common regex patterns to the documentation. You can find more details and our plan for adding future enhancements to this feature based on our roadmap in the epic.

Annotate non-deployment jobs in .gitlab-ci.yml

Historically, the environment:action keyword did not accurately represent environment jobs that didn’t result in a deployment, such as in-approval jobs and building images for future deployments. In GitLab 13.2, jobs now contain a prepare keyword to make the state of non-deployment environment jobs clearer, keeping them accurate and representative of your deployment activities.

Annotate non-deployment jobs in .gitlab-ci.yml

Read-only access to Terraform State API

GitLab users without Maintainer access currently cannot interact with Terraform commands, including terraform plan, which creates an execution plan useful in development workflows. In GitLab 13.2, users with the Developer role gain read-only access to the Terraform state API, enabling more users to contribute without risking improper usage.

Alert detail pages display system notes

When you change the status of an alert, assign it to a team member, or create an issue from the alert, GitLab tracks these events and displays them as notes on alert detail pages. Notes provide helpful context to responders, enabling your team to better collaborate when triaging alerts, and preventing unnecessary duplication of work.

Alert detail pages display system notes

Keyboard shortcuts for panels in metrics dashboard

You can now use keyboard shortcuts to interact with your metrics dashboards in GitLab 13.2. With keyboard shortcuts, you can quickly navigate through a dashboard while triaging an incident, speeding up the response workflow.

Search for plain text in the Alerts list

Alerts are often noisy and plentiful. To help you find relevant alerts you need to triage, and refine the list of displayed alerts, you can now conduct plain-text searches in the Alerts list.

Trigger tests for your alert integrations

After you configure your alerting systems to route alerts to your GitLab REST endpoint, you can now trigger test alerts to ensure you’ve configured your systems properly, giving you extra peace of mind.

Previously, when connecting to Amazon Elasticsearch Service on AWS to enable Advanced Global Search, you could only use static credentials or EC2 IAM roles via Aws::InstanceProfileCredentials. Now, as an additional authentication option, you can use IAM roles for Amazon ECS tasks.

Thank you to Jason Barbier @kusuriya for this community contribution!

Geo settings forms easier to read and validate input

Systems administrators can adjust Geo settings for individual nodes using the administrator interface. Until now, these forms contained some outdated user interface elements, displayed too much optional information, and some inputs were not properly validated.

In GitLab 13.2, the individual Geo node settings and general Geo settings validate user input and are divided into different sections (for example, “Performance and resource management”) to make it easier for systems administrators to find related settings.

Geo settings forms easier to read and validate input

Geo supports replicating GitLab Package Registries

Geo now supports replicating Package Registries to secondary nodes, allowing distributed teams to access them from the closest Geo node, which reduces latency and improves the overall user experience. Additionally, the Package Registry assets 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.

GitLab chart improvements

Patroni available as experimental alternative to repmgr

For self-managed GitLab installations, Patroni is now available as an alternative PostgreSQL replication and failover solution. Patroni brings improvements over repmgr, which it replaces. With Patroni, a failed primary is automatically added back to the cluster as a standby node when it comes back online. The addition of Patroni also unblocks us from adding support for PostgreSQL 12, and supporting PostgreSQL replication and failover on a Geo secondary site. Use of Patroni with Geo is currently being tested and is not yet supported. This switch supports GitLab’s goals to dogfood our solutions. Gitlab.com has been using Patroni to manage failover since 2018, making it a well tested solution. Repmgr will continue to be available in Omnibus GitLab until GitLab 14.0. For instructions on setting up Patroni, which is currently experimental, see GitLab’s Patroni documentation.

Bug fixes

Some of the notable bug fixes in 13.2 are:

Option to delay project removal

In GitLab 13.2, we’ve improved the project removal experience to be consistent across all pricing tiers and introduced a group-level toggle to allow you to enable a deletion delay period before permanent removal. Previously, the default behavior for removing a project was different across Tiers. Projects would be immediately removed in the Free/Core and Bronze/Starter Tiers and delayed by 7 days in the Silver/Premium and Gold/Ultimate Tiers.

Now, this behavior is consistent across the board and removing a project will result in the immediate removal of that project. To ensure you still have flexibility in this workflow, we’ve introduced a group-level toggle to “Enable delayed project removal” for groups and projects where preventing data loss is a key requirement. Deleting a project should be easy when it needs to be and have safeguards in place for organizations with stricter requirements around preserving their intellectual property.

Show expired or revoked SSH keys and PATs in the credentials inventory

Managing user credentials is an important element of any compliance program and requires visibility for the compliance professionals tasked with ensuring policies are being followed. The credentials inventory now highlights any SSH key or Personal Access Token (PAT) which has expired. Additionally, revoked PATs will also be highlighted to provide compliance professionals the necessary insight they need to conduct a review of user credentials.

This change is part of a larger initiative to make credential management within GitLab more simple, friendly, and flexible for customers to implement the processes that make the most sense for their users and organization.

Show expired or revoked SSH keys and PATs in the credentials inventory

Bulk edit issue health status from the Issues List

When managing and planning multiple issues, it can be cumbersome to update each issue’s health status separately. You can now edit the health status of many issues at once from the Issues List.

Bulk edit issue health status from the Issues List

Collapse milestones on the Roadmap

When sharing, reviewing, or presenting your Roadmap, you often need to minimize some sections or tailor the information displayed for the right audience. GitLab now allows you to minimize the Milestones section of the Roadmap to display more epics or hide unnecessary information.

Collapse milestones on the Roadmap

New epic creation page

Create an epic and fill out your description, add labels, and set your start/due dates in a single step with our new epic creation page.

New epic creation page

Service Desk moved to Core

In the 9.1 release, we added Service Desk to our Premium tier, allowing teams to connect directly with external users through email.

Listening to our customers, we learned that Service Desk is a useful feature for teams of any size. In GitLab 13.2 you can now enable Service Desk regardless of your GitLab tier.

Batch Suggestions

Suggesting changes in merge requests makes proposing improvements easy, but if you receive many suggestions, applying them one by one is slow.

With Batch Suggestions, you can apply multiple suggestions at once, which is faster and easier! It’s also beneficial to keep the commit history in a merge request clean and tidy. Thanks Jesse Hall for your contribution!

Gitaly Cluster TLS support

Gitaly Cluster now supports Transport Layer Security (TLS), which means all communication between Gitaly and its clients, GitLab and Praefect, are encrypted when TLS is enabled for both Gitaly and Praefect components. This is helpful when deploying GitLab to a network with other internal services that are not trusted.

Previously, communication between GitLab and Gitaly supported TLS encryption, but encryption was not supported when using Praefect, which is a component of Gitaly Cluster.

Make it easier to find Designs on an issue

Since designing is such a massive part of the product development process, it’s important that the designs you have created and added to issues are easy to find. Before 13.2, we had the Design tab, but we’ve moved designs up, so they are now right under the issue description.

This will encourage more collaboration and ensure that everyone sees the designs right beneath the issue description.

Make it easier to find Designs on an issue

Real-time feedback for .gitlab-ci.yml in Web IDE

GitLab CI is fast and highly configurable, but it can be hard to remember all the configuration parameters, and the wrong typo can make your .gitlab-ci.yml file invalid. To make it easier to configure your GitLab CI pipeline, the Web IDE now provides real-time linting and completion when editing .gitlab-ci.yml files.

Linting and completion feedback is provided inline in the Web IDE with tooltips to help understand why you’re seeing an error. Currently, this feedback is based on a community-contributed schema from Schemastore, but we are continuing to evaluate a built-in schema as part of GitLab.

Real-time feedback for .gitlab-ci.yml in Web IDE

Transactional writes for Gitaly Cluster (beta)

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. However, because write operations are currently replicated asynchronously, the GitLab server only has one copy of the change initially.

In GitLab 13.2, transactional write operations to Git repositories can be enabled for Gitaly Cluster. When this option is enabled and an update is pushed to GitLab, the write operation will be proxied to the replica Gitaly nodes. The write operation will be coordinated between the Gitaly nodes using the two-phase commit protocol, so that they agree on the new state of the repository. Write transactions are currently limited to operations pushed over the HTTP and SSH Git interfaces, and does not include write operations via the GitLab interface like the Web IDE.

Code Quality Merge Request widget moved to Core

In the 9.3 release, GitLab added Code Quality scanning to our Starter/Bronze tier, allowing you to see code quality changes directly in your merge requests. Since then, our users have provided feedback that this data is valuable to teams of any size, including individual contributors. In 13.2, you will be able to see Code Quality reports in your Merge Requests regardless of your GitLab tier.

Exclude files in CI artifact paths

With the new exclude syntax, you can prevent specific files from being added to artifacts. This eliminates the need to explicitly reference the path of every folder that should be added to the artifact (to avoid including too much). Support for wildcards (globs and double star globs) makes it easy to exclude entire subdirectories.

Notification when system removes MR from merge train

If you add a merge request to a Merge Train, but the system removes it due to an issue, you now receive a notification in the form of a To-Do task. This means you can add an MR to a Merge Train with confidence, knowing that either a merge will happen automatically, or you will receive a notification of failure. If the merge is unsuccessful, you can quickly correct errors and resubmit your MR instead of being surprised later to learn it was never merged.

Visual correlation of trigger job to downstream pipeline

If you’ve looked at a complex pipeline graph wishing there was an easy way to know which job triggered a specific downstream pipeline, then wish no more. Now you can simply hover over a downstream pipeline to see a tooltip that names the job which triggered the pipeline. And there’s no need to skim all the job names to find “the one” because the hover action also highlights the trigger job in the upstream pipeline.

Visual correlation of trigger job to downstream pipeline

JavaScript & TypeScript SAST analyzer available for all

We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being contributed and to mitigate proactively. As part of our community stewardship commitment we are making our JavaScript & TypeScript SAST analyzer (ESLint) available in every GitLab tier. This will allow ALL GitLab users developing in JavaScript or TypeScript to leverage SAST security Scans for their projects. As part of this move, we have deprecated our existing TSLint Analyzer, as its functionality is now present in ESLint. You can learn more about this in our deprecation notice. We will continue to move other open source (OSS) SAST analyzers to Core. You can follow our SAST to Core epic to see when other analyzers will become available, and even contribute to this effort.

JavaScript & TypeScript SAST analyzer available for all

Multiple Terraform plan support in Merge Requests

During a single Terraform pipeline, several infrastructure environments might be affected. Previously, GitLab enabled a quick overview of the expected changes in a Merge Request only for a single environment. Starting in GitLab 13.2, the Terraform Merge Request widget supports multiple Terraform artifact files.

We’re actively looking for feedback about our Terraform features. If you have ideas for improving the Merge Request widget, please share it with us in the Merge Request widget epic.

Access Opsgenie from the GitLab user interface

Opsgenie is a popular IT services management tool for operations tasks, including alerts and incident management. In GitLab 13.2, you can start your Opsgenie workflow directly from within GitLab. Want to give us feedback on this integration? Contribute on this issue and tell us how we can make it better!

Access Opsgenie from the GitLab user interface

Auto-grouping identical alerts to reduce noise

Teams maintaining IT services receive hundreds or thousands of alerts a day. GitLab now de-duplicates and organizes your incoming alerts, providing you counts of alerts while keeping your alert list manageable and useful. Your alerts are linked to the incidents created from the alerts, helping you track which alerts have been addressed and which alerts still need to be triaged.

OAuth for manually configured Prometheus servers

To use a manually configured (external) Prometheus server, it can be problematic to authenticate users from GitLab. In Gitlab 13.2, you can now use OAuth so that authentication is secure and easy to administer.

Set metrics dashboard variables with PromQL

You can now set variables in your metrics dashboard using PromQL. Your PromQL queries can return a list of values to use as dynamic variables in a metrics dashboard.

Set metrics dashboard variables with PromQL

Vanity URL for Metrics Dashboards

GitLab 13.2 introduces vanity metrics dashboard URLs to help you to quickly navigate between different dashboards and projects.

Faster Geo replication performance for Projects

GitLab Geo makes distributed teams work more efficiently, creating and maintaining a local copy of GitLab that reduces latency so they don’t have to wait for files to download over long distances. In this update to Geo, we’re improving how the database manages changes. To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s database queries time out, data can’t be replicated successfully. In GitLab 13.2, we use a new approach to synchronize Projects, thereby eliminating the possibility of database statement timeouts. We also improved the way we remove data from secondary nodes for all data sources, which increases the overall scalability and performance of GitLab Geo.

These iterations bring us closer to removing Geo’s dependency on Foreign Data Wrappers, which were added for improved performance, but which make Geo more complex and harder to maintain.

Geo supports pausing database replication on a Geo secondary

Geo replicates data from a primary Geo node to one or several Geo secondary nodes. While Geo supports pausing replication for repositories and files via the administrator interface, it was not possible to pause database replication. In 13.2, Geo supports pausing and resuming replication of all replicated data, including the PostgreSQL database using the new gitlab-ctl geo:pause and gitlab-ctl geo:resume commands on a secondary Geo node.

This allows systems administrators to pause all replication on a secondary Geo node while performing critical maintenance operations on the primary Geo node. In the case of a failure on the primary, no changes are replicated to the paused secondary node, which can then be used to failover to.

Geo's failover preflight-checks command checks replication status

When performing a failover using GitLab Geo, systems administrators should perform a number of preflight checks using the gitlab-ctl promotion-preflight-checks command.

In GitLab 13.2, the gitlab-ctl promotion-preflight-checks command now automatically checks the replication status and informs you of the results, removing a step that used to be performed manually. The gitlab-ctl promote-to-primary-node command also supports a force mode, which means a failover will proceed even when some preflight checks fail.

This is an iteration towards a simpler failover process and we plan to automate preflight checks further in future iterations.

Omnibus improvements

  • The minimum size for compressing NGINX responses has been lowered from 10,240 bytes to 250 bytes. This reduces the number of requests that need more than one packet, and decreases the time it takes to load web pages. For details, see the Merge Request.
  • The settings to configure object storage have been consolidated so that object storage for all objects can be configured in the same section in gitlab.rb. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for object storage in multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for a pre-signed URL. For more details, refer to the Object Storage documentation.
  • An Omnibus install package is now available for Ubuntu 20.04.
  • An Omnibus install package is now available for SLES 12.5.
  • The version of Chef that is packaged in GitLab has been updated to Chef 15.
  • GitLab 13.2 includes Mattermost 5.24, an open source Slack-alternative. This release includes an improved end-user search, an improved session experience, and much more. It also includes security updates and upgrade from earlier versions is recommended. When upgrading to Mattermost 5.24, see the important upgrade notes about enabling the new ExtendSessionLengthWithActivity setting. If you have a Mattermost environment that contains a lot of emoji reactions, please also refer to the upgrade note about longer upgrade times.

With the previous version of Advanced Global Search, if you needed to reindex, you would have to plan for Advanced Global Search to be down. Search results were unavailable while the index was deleted and the new index created. In 13.2, we have added index aliases that allow you to reindex without any downtime with a press of a button in the admin settings. Going forward Advanced Global Search can be reindexed without disrupting any of your users’ workflow! This is important, because on larger instances it can take some time for the reindex to complete.

Zero downtime reindexing for Advanced Global Search

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.2, we’re shipping performance improvements for issues, projects, milestones, and much more! Some performance improvements in GitLab 13.2 are:


Deprecation and planned removal of TSLint Secure analyzer

The recent update of our ESLint Secure analyzer includes new support for TypeScript which is actively maintained. Since 2019 the TSLint project has been deprecated in favor of ESLint. We have now unified these analyzers in GitLab’s ESLint analyzer, which renders our TSLint analyzer obsolete.

We are deprecating the TSLint Secure analyzer in 13.2 and have removed the TSLint job definition from the SAST template. If you leverage Auto Devops or include the GitLab Secure SAST Template no action is required, as this transition will happen automatically when you update to GitLab 13.2. We recommend that anyone using the TSLint SAST job in a customized CI template to migrate to the newly updated ESLint Job.

The next time the SAST job runs after this transition you may see previously present TSLint vulnerabilities being marked as “resolved” and new TypeScript vulnerabilities from ESLint. This behavior is expected due to the new unique vulnerability signatures from ESLint which are different from old TSLint job scan vulnerability signatures.

Deprecation date: September 22, 2020

Transitioning GitLab Bandit Secure analyzer OS image

In an effort to simplify and modernize our GitLab Secure SAST Analyzers, we will transition the GitLab Bandit Python Analyzer image from Debian Buster to Alpine Linux. This transition will reduce the image size and increase both the speed and security of our analyzer.

This transition will be backward incompatible though we expect limited impact. If you use a before_script to pre-build dependencies for your Python project, you should test this change before upgrading to GitLab 13.4. We will add a new section in the SAST troubleshooting documentation with more information about this change as we approach 13.4.

Deprecation date: September 22, 2020

Important notes on upgrading to GitLab 13.2

  • GitLab 13.2.0 remediates an email verification bypass. After upgrading, if some of your users are unexpectedly encountering 404 or 422 errors when signing in, or “blocked” messages when using the command line, their accounts may have been un-confirmed. In that case, please ask them to check their email for a re-confirmation link.
  • GitLab installations that have multiple web application nodes must be upgraded to 13.1 before they can be upgraded to 13.2. This is due to a breaking change in Rails that can result in authorization issues if this upgrade path is not followed. For details, see this issue. For information about upgrading, see the version-specific upgrade instructions.
  • Pre-receive and update server-side Git hooks have been reimplemented in Go. To use the original Ruby versions instead, use the available feature flags.