Use Jaeger in the GitLab UI

Tracing provides insight into the performance and health of a deployed application by tracking each function or microservice which handles a given request.

Jaeger is an open source, end-to-end distributed tracing system used for monitoring and troubleshooting microservices-based distributed systems.

With GitLab 12.4, users that are using Jaeger can access it and view the performance and health of their deployed application without leaving the GitLab UI.

Variable Expansion Support for Multi-project Pipelines

When using a multi-project pipeline flow, where one pipeline triggers another, it’s often helpful to be able to store a dynamic value in a variable upstream that you can reference in the downstream pipeline. For example, if a pipeline is running on a branch and you want the $CI_COMMIT_REF_NAME on that branch accessible throughout all of the downstream pipelines.

Previously, the variable didn’t expand so calling a variable downstream via the trigger keyword failed with a no ref name error. Getting this workflow to work required spawning a separate job whose only purpose was to execute a cURL command to kick off the next pipeline passing in the variable state. In addition to requiring extra set up and extra resources to run this workaround loses the ability to visualize the relationship between pipelines in the UI.

Now GitLab will expand variables used inside of the branch property of the trigger keyword, simplifying your pipeline design and adding more flexibility around how your pipelines trigger each other in multi-project scenarios.

DAST for the Master Branch

We are pleased to announce that DAST scans can now run against a project’s default branch inside a dedicated review app. Previously, DAST only ran against feature branches. This enhancement allows the creation of a DAST results baseline on the default branch against which MRs are compared. With this, you can pinpoint the exact branch where new security issues are introduced.

Check for Existence of Files in Pipelines

Adding to the rules: syntax initially introduced in GitLab 12.3, the new rules:exists rule is able to accept an array of paths and will match if any of these paths exist as files in the repository. This is useful in cases where you want to run a CI job only if a certain file exists. For example, only run the tests pipeline when the file tests.yml exists. Use of this rule can help speed up pipelines by skipping stages with no match.

Native Geo Support for Object Storage Replication

In GitLab 12.4, Geo natively supports replicating data in object storage such as LFS objects, job artifacts, and uploads. Previously, Geo could be configured to work with object storage; however, the replication of the content was always left to the object storage provider. This imposed limitations when users relied on local storage appliances that do not support any replication logic.

Native Geo support allows data to be replicated across different object storage providers in different regions (e.g. Amazon in Europe and Microsoft in the United States). Geo users can also use local storage, for example via MinIO, and use Geo to replicate data to secondary nodes.

Native Geo support for object storage replication is currently a beta feature and is not ready yet for production use.

Improved large file handling via Git Partial Clone (alpha)

Storing large binary files in Git has typically been discouraged to prevent the repository growing too large, making cloning and fetching changes very slow. Solutions like Git LFS have provided a workaround by storing large files outside the Git repository, and downloading large files on demand.

In GitLab 12.4, we are adding experimental support for Partial Clone, which allows large files to be excluded when cloning a repository and fetching updates. This removes the need to choose which files should be stored in Git and which files should be stored outside the repository using Git LFS. Partial Clone support is disabled by default, but can be enabled per project, and requires at least Git 2.22.0.

In comparison with Git LFS, instead of requiring large files to be specially handled when authoring the commit, Partial Clone allows developers, CI runners, or any other Git client to specify which files they want to download. This removes the need to teach people which files should go in Git LFS, avoids the problems of trying to rewrite history to migrate large files to Git LFS, and bypasses the frustrations caused by someone accidentally pushing an large file to the Git repository when it should have gone to Git LFS. Simply, large files should just work.

Date Picker for Productivity Analytics

Until now, users were not able to select a specific date range for their metrics in cycle analytics and productivity analytics. This meant that they cannot drill down or report into productivity during a specific sprint or a custom date range since we only provided preset periods such as 7, 30, 60, 90 days. With the release of this feature, users will be able to visualize how their data looks over any time frame and the periods that actually matter to them.

Use VPC Native Setting by Default When Creating GKE Cluster in GitLab

Google Kubernetes Engine provides the ability to create VPC-native clusters, which rely on Alias IPs and provide integrated VPC support for container networking, resulting in a more scalable, secure, and simple system that is suited for demanding enterprise deployments and use cases.

Starting with GitLab 12.4, GitLab’s GKE integration will enable this option by default when creating a GKE cluster.

Restrict Permissions for Manual CI Jobs

Teams often need to create manual jobs to handle things like deployments, soft approvals, or other gates, but in GitLab it’s not obvious how to restrict these permissions to prevent just anyone from completing the action.

This was actually already possible in GitLab today, but wasn’t clearly documented. In this release we’ve significantly improved the documentation for protecting manual jobs to make it more clear how to get this set up.

Delete Designs in Design Management

Sometimes mistakes happen or design goals change and the ability to remove a design from a revision can be important. With deletions in Design Management users can select one or more designs and remove them from the latest version. This enables the latest version of the design to represent the true state of ideas.

Enrich Environment and Deployment API

We have added API functionality that will return the state and last deployment attributes of environments. An example use of that information is to write a script to delete unused environments.

Improved Geo Upgrade Documentation

As part of our effort to simplify the Geo upgrade process, we reworked large parts of the Geo upgrade documentation. GitLab Geo can be deployed in different configurations and depending on the configuration Geo upgrades require different steps. At this moment, upgrading Geo is still highly manual and can involve many individual steps. To improve this in an iterative way, we focused first on improving the Geo upgrade documentation itself. This ensures that the documentation is up-to-date and covers all use cases.

We rewrote the general update steps, archived old update steps, updated zero-downtime upgrade instructions for simple deployments and investigated many other parts of the documentation.

We are also working on instructions for zero-downtime updates of a multi-node, high-availability Geo cluster; however, these instructions require more testing before we release them.

Following this work, we will work on better automation, improved testing, and making certain upgrade procedures more robust.

MR links are now shown on Pipeline view

When viewing a pipeline, it can be helpful to be able to navigate to the merge request(s) associated with that pipeline. We’ve added links directly to the related merge requests to make this simpler and more efficient.

Insert jobs at beginning or end of pipeline via include

A common use case for includes is to add a job at the beginning or end of a pipeline. However, as the author of a shared include, you don’t necessarily know what the first or last stages will be called. This makes it difficult and error prone to try to write a job that runs at the start or end of a pipeline.

In GitLab 12.4, .pre and .post pipeline stages that are guaranteed to run at the beginning or end of a pipeline to make this easier are available.

Upgraded Kubernetes NGINX Ingress Application when Installed via Kubernetes Integration

Keeping your Kubernetes-deployed apps running on the latest version ensures you have the newest features as well as up-to-date security. GitLab 12.4 allows you to use the latest NGINX Ingress application when installing it using GitLab Managed Apps. To upgrade an existing version, uninstall and reinstall the Ingress application using GitLab.

API Endpoint for 'Static Status Check Names' in GitHub Integration

It is now possible to configure the static status check names in the GitHub integration via the API, making it much easier to change this setting on large numbers of projects.

GitLab Runner 12.4

We’re also releasing GitLab Runner 12.4 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Changes include:

• Extend custom executor configuration.
• Use certutil to create a certificate chain for Git.
• Bump used Go version to 1.10.8.
• Update Kubernetes client library to 11.0.
• Add timeout when waiting for the build to finish.

The list of all changes can be found in GitLab Runner’s CHANGELOG.

Performance improvements

We continue to improve the performance of GitLab with every release for GitLab instances of every size.

Some of the improvements in GitLab 12.4 are:

• Limit the number of commits on commentable items to 5,000
• Ensure cache headers for avatars are set correctly when using object storage and proxied downloads
• Speed up Jira DVCS API for Jira Server
• Prevent certain email autoresponders from adding comments to issues
• Restrict scope for Snippet Searches
• Limit the search count query for Snippets
• Add Trigram Index on Snippet Content
• Improve load time for markdown renderer significantly

Admin Override of Artifacts Size per Project/Group

Currently, the artifacts size is set to 100MB by default but some projects need the ability to go over these limits, subject to the discretion of the administrator. To enable this, we’ve added an option in group and project settings to override the global artifacts size limit, similar to how the repository size limit can be customized.

Private Project Support for Online View of HTML Artifacts

Viewing HTML artifacts in a browser window is a key efficiency workflow. Because of how frequently this task is performed, being able to quickly go from browsing your artifacts to opening and reviewing them is important. Without an online view, you need to download the artifact and spin up a webserver locally to view the report. Doing this for every HTML artifact for all of your builds can become an intrusive time-sink that interrupts the flow of work with continual context-switching.

Previously, it was possible to view HTML artifacts in a browser window using GitLab Pages instead of downloading them locally, but this capability was limited to public projects only. This was a problem for many businesses and organizations that use GitLab predominantly with private projects - an online view was simply not available to them. Now thanks to a wonderful community contribution from Tuomo Ala-Vannesluoma, we have added support for online view of HTML artifacts to private projects as well. Note that this requires enabling access control for GitLab Pages to work correctly.

Enable "Cloud Run on GKE" When Creating a Cluster via GKE Integration

When creating a Kubernetes cluster via GitLab’s GKE integration, users can now optionally enable “Cloud Run on GKE” with a single click. GKE will automatically provision the cluster with Knative serving, Istio, and HTTP load balancing. When installed, users can continue to take advantage of the features offered by GitLab Serverless to deploy Knative services with minimal configuration.

Note: Cloud Run for GKE has recently been rebranded as “Cloud Run for Anthos”. We plan to update the name of this feature with Google’s updated branding in next month’s release.

Generic Alert Endpoint MVC

People make use of a variety of different tools to monitor their application environments. These tools send critical, time-sensitive alerts when an incident arises and action needs to be taken. Now, GitLab’s Incident Management capabilities include a generic REST endpoint where you can send alerts, regardless of the tool that generated them. When GitLab receives a POST to the endpoint, it will automatically create an incident issue. The payload is included in the issue description and commonly used fields are automatically parsed. This allows you to use GitLab issues as a central place for incident response leveraging inputs from your other tools.

Please check out a short video that highlights the Generic Alert Endpoint MVC.

Geo Supports Using a Single, Location-aware Git URL

Geo now supports providing users with a single remote URL that automatically uses the Geo node closest to them. This means users don’t need to update their Git configuration to take advantage of closer Geo nodes as they move. In fact, end users won’t even have to know that they are using a local Geo node when initially cloning a project. For systems administrators, it removes the need to maintain different Git configurations for users in different locations. This is possible because, Git push requests can be automatically redirected (HTTP) or proxied (SSH) from secondary nodes to the primary node.

Geo can be configured to use different services, such as AWS Route53 or Cloudflare.

Git Activity added to Group IP Address Restriction

GitLab 12.0 saw the introduction of restricting a group’s activity by IP address. In GitLab 12.3, we included API activity in the access restriction. In GitLab 12.4 we’re extending this further to include Git actions via SSH.

The resulting feature now provides extensive coverage, rejecting UI, API, and Git activity if they do not adhere to the group’s IP address restriction. For compliance-minded organizations, especially those on GitLab.com, this provides an comprehensive and important security layer.

Scatterplot for Productivity Analytics

Previously, users were not able to easily visualize and measure velocity over time. In order to enable them to do that, we are adding scatterplots to Productivity Analytics, where users can select ‘Time to Merge’ or any other merge request related metric in order to spot relevant trends or outliers. Users can also zoom in on a particular date range in order to research and analyze specific data sets.

API for Manually Creating Deployments

We have added API functionality that will allow for creating deployments. This also changes deployments so that the associated CI build is optional. This is needed to lay the foundation to support external environments and deployments to GitLab.

One-click Install for Group Runner on Kubernetes

It’s now easier than ever to create a shared Runner at the group level if you’re using GitLab with Kubernetes. The ability to one-click install a Runner at the project level has been available for a while, but group Runners still needed to be installed manually. Now, you can simply click a button and GitLab will install a shared group Runner for you.

Design Management System Notes

In GitLab 12.2 we released the first iteration of Design Management, which allowed uploading designs directly to issues. They were uploaded in a separate tab within issues and their activity wasn’t logged, making it harder to identify whether there were designs added the issues. From GitLab 12.4 on, when designs are uploaded, new system notes are output to the issue’s thread to inform the participants. In a future release, we’ll bring status and discussion count indications to the designs to further inform users on design’s activity.

GitHub Integration Default to Static Status Check Names

We have changed the default setting for our GitHub integration to use static status check names by default on new projects. With static status check names enabled on the integration page, your GitLab instance host name is going to be appended to a status check name, whereas in case of dynamic status check names, a branch name is going to be appended. This is a more sensible initial setting that will ensure that requiring status checks works out of the box for users using GitLab CI/CD with a GitHub repository.

Multi-Select & Move Issue Cards

Sometimes, it’s the little things that matter. Whether you’re kicking off your next sprint or you just like to pass the time dragging and dropping on Issue Boards, you’ll be happy to know that you can now multi-select issue cards via Cmd + click on a Mac or Ctrl + click on Windows to move them all at once to a different list.

Sort Packages in the Registry UI

The GitLab Package Registry allows users to build, publish and share npm, Maven and (coming soon) Conan packages. GitLab provides a user interface that displays package metadata and helps users to find their project or group’s packages. However, until recently, users had to manually scroll through their list of packages to find the package they were looking for.

In GitLab 12.4, we are happy to introduce sorting to the Package Registry user interface to improve navigation and discoverability! Now you can sort packages at the project and group level by created date, name, version, and type. In the coming milestones, we are working on adding last commit and branch and will be redesigning the user interface to include all relevant metadata.

Global View for Instance-level Cluster Deployments/Environments

The Environments view was introduced in GitLab 12.3 for group-level clusters. The Environments section of the cluster page provides an overview of all the projects that are making use of the Kubernetes cluster, including the deployments/environments that have been provisioned and the number of pods used by each environment. Now in 12.4 the “Environments” view is available for instance-level clusters. Navigate to your instance Kubernetes page and click on the Environments tab. For group-level clusters, the cluster “Environments” view has been extended to instance-level clusters.

The “Environments” section of the cluster page provides an overview of all the projects that are making use of the Kubernetes cluster, including the deployments/environments that have been provisioned and the numbers of pods used by each environment.

S/MIME is now configurable in the GitLab Helm chart

Sending emails with an S/MIME signature improves security by reducing the surface area for phishing, man-in-the-middle, and other attacks. While the ability to sign notification emails with S/MIME was added to Omnibus in 12.3, it wasn’t possible to configure S/MIME when installing GitLab on Kubernetes. Now, in 12.4, S/MIME parameters for GitLab email notifications can be configured as a global setting for the GitLab helm chart.

Upgraded Kubernetes Cert-Manager Application When Installed via Kubernetes Integration

Keeping security certificates for your Kubernetes-deployed apps updated ensures your applications are securely served without interruption. Starting with GitLab 12.4 you can now upgrade your Cert-Manager application using the GitLab Kubernetes integration. To upgrade to the latest GitLab-supported version, navigate to the cluster page from Operations > Kubernetes, then uninstall and reinstall Cert-Manager.

Omnibus improvements

• GitLab 12.4 includes Mattermost 5.15, an open source Slack-alternative. This version of Mattermost is focused on quality improvements.
• OpenSSL has been updated to version 1.1.1d, which fixes a number of CVEs. For information about the changes introduced in this minor release, visit the OpenSSL website.
• An option has been added to skip database backups during an upgrade. Database backups can extend the time required to complete an upgrade, and in some cases, you may want to skip this step so that the upgrade finishes quicker. For details on how to skip automatic database backups during upgrades, see the Omnibus upgrade documentation. If you skip the automatic backups, make sure you create your own before upgrading.