Feb 22, 2020 - Tim Rizzi

GitLab 12.8 Release

GitLab 12.8 released with Log Explorer, NuGet, and Compliance

GitLab 12.8 is here celebrating "one place!" Get one place for your logs, one place for your NuGet packages, and one place for your compliance activity just like GitLab is one place for your entire DevOps lifecycle.

Triage faster with the new Log Explorer

When triaging an incident or validating the status of your service you need to be able to explore Kubernetes Pod Logs from across your entire application. Previously, this was a painful process as you could only see limited logs, couldn't go back in time, and didn't have search. This was complex and time-consuming enough that it could make using Pod Logs impractical for meaningful analysis and instead limit it to simple troubleshooting use cases.

Now, a new Log Explorer lets you interact with all your logs aggregated into one place. Powerful features including filtering, time picker, and full-text search let you quickly get the information you need. This important milestone moves our Logging category from minimal to viable! To get started, install the Elastic stack on your Kubernetes cluster with just one click using the GitLab Managed app, and your logs will be automatically collected and aggregated.

Windows has a large, active, and growing development community. While GitLab has already had built-in package management for C/C++, Java, and Node.js, teams writing applications in C# and .NET still needed to use tools external to GitLab in order to store and manage their binaries. This meant they were missing out on the benefits of using a single application across their DevOps lifecycle.

Now, GitLab 12.8 gives teams writing code in C# and .NET a built-in NuGet repository so they have one place to manage and share project binaries both privately and publicly. Developers can now benefit from having their source code, CI/CD pipelines, and the resulting packages all in the same application so they can get work done faster with less effort.

Manage risk with the Compliance Dashboard

Merge requests (MRs) are an elegant and powerful change management tool for keeping a record of changes and approvals. Release teams use MRs to track deployments, and infrastructure teams use MRs to practice GitOps.

Additionally, tracking all MR activity can be critical for organizations that have specific company policies that govern their operations in order to adhere to compliance frameworks, such as SOC 2, ISO 27001, GDPR, SOX, HIPAA, or PCI-DSS, and have specific company policies that govern their operations.

Some examples of governing policies are:

All MRs have a related issue with detailed information about the change(s)
All MRs are reviewed and approved by someone who isn't the author
All MRs pass QA and security testing
Any exceptions to the requirements require separate approval.

Previously, GitLab users lacked the necessary tools to effectively manage their GitLab environment's change management and compliance. Project-level activity was confined to each project, and there was no easy way to view this information in aggregate at the group level. This lack of control and insight created increased potential for risk, reducing users' ability to manage compliance within GitLab.

We have a vision for adding robust compliance management to Gitlab. As a first step towards this vision, we're starting with a Compliance Dashboard which provides a view of the most recent merge requests for each project in a Group. With the capabilities available today, you can manage auditing of your code changes for releases and GitOps from one place. Similarly, this makes it easier for compliance-focused organizations to quickly understand which projects might have greater risk and therefore warrant extra attention. Be on the lookout for more capabilities and improvements in our coming releases.

And much more!

These are just a few highlights in 12.8. Check out the other great updates, such as blocking issues, Docker image expiration policies, and Single-level Epics, now available in Premium!

GitLab 12.8 is here celebrating "one place!" Get one place for your logs, one place for your @nuget packages, and one place for your compliance activity just like @GitLab is one place for your entire DevOps lifecycle. via @tim_rizzi Click to tweet!

Join us for an upcoming event Release survey

MVP This month's Most Valuable Person (MVP) is awarded to Roger Meier

Roger added support for S/MIME Signature Verification of Commits, which allows you to verify yourself as the author of a commit using x509. This feature is important for sensitive projects and in regulated industries. Roger’s teammate, Henning Schild, contributed the change upstream to Git and Roger made the change in GitLab.

Check out the Signing commits with x509, and get started today! Thank you, Roger, for your contribution!

12.8 Key improvements released in GitLab 12.8

Explore aggregated logs

Explore aggregated logs

SaaS

Self-Managed

In a cloud-native world with short-lived services and logs distributed across multiple pods and services, aggregation of logs for observability becomes critical. GitLab 12.8 introduces log aggregation using the Elastic stack.

After attaching a Kubernetes cluster, you can install the Elastic stack, which contains an Elasticsearch instance with Filebeat, a light-weight log shipper. Once enabled, GitLab automatically collects all application logs and surfaces them on the UI.

With this, you will be able to view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs.

This can be useful if you are triaging an application incident or validating the status of your service and need to explore logs from across your application and conduct a full-text search. It also helps you to understand what is affecting your application’s performance and resolve any problems as they arise.

SaaS

Self-Managed

For any organization delivering software, providing teams with an easy and secure way to manage dependencies is critical. Package managers, such as NuGet for C# .NET, provide a standardized way to share and version-control these libraries across projects.

In GitLab 12.8, we are proud to offer NuGet repositories built directly into GitLab. Developers now have an easier way to publish their projects’ NuGet packages. All you have to do is set the NuGet remote to the GitLab Package Registry and start uploading, installing, and deleting packages today.

Documentation Issue

Build, publish, and share packages to the GitLab NuGet (.NET) Repository

Compliance Dashboard

Compliance Dashboard

SaaS

Self-Managed

Compliance-minded organizations need visibility. This becomes more difficult as more groups, projects, and users are added to GitLab, which can make it difficult to manage risk and compliance appropriately.

In GitLab 12.8, we’ve added a group-level dashboard as a first iteration towards bringing compliance insights to group owners. This first iteration focuses on aggregating all of the most recent merge requests (approved and merged) from each project in a group. Group owners can now see all of their merge request activity to be informed and take action if necessary.

Documentation Issue

Network Policies for Container Network Security

Network Policies for Container Network Security

SaaS

Self-Managed

We’re pleased to announce initial support for Container Network Security to help prevent lateral security attacks. You can now configure Network Policies in GitLab-managed Kubernetes clusters to limit communication between Kubernetes pods.

Network Policies can control communication between pods and the internet and can prevent unauthorized pods from communicating with other pods in the same Kubernetes cluster. In a multi-application cluster, this feature also enables network segmentation between the different applications.

Documentation Issue

Single-level Epics now available in Premium!

Single-level Epics now available in Premium!

SaaS

Self-Managed

To support our users who are planning larger collections of related work and manage them across multiple milestones, sprints, and iterations for their teams, we are releasing single-level Epics for our Premium customers!

Spin up an Epic, create and add associated issues, set start and due dates, and organize it quickly with our drag-and-drop Epic Tree.

Documentation Issue

Single-level Epics now available in Premium!

Blocking issue support

Blocking issue support

SaaS

Self-Managed

Clearly defining issue dependencies has just become easier. You can now mark issues as blocking or blocked by other issues. With this new dependency construct, it is now easier than ever to understand issues that may need extra attention (blocked), or to identify issues which will yield high rewards (blocking)! Collaboration efficiency is also increased as inter-team dependencies can now be represented.

Documentation Issue

Issue Board Work In Progress Limits

Issue Board Work In Progress Limits

SaaS

Self-Managed

The more issues in progress in a given workflow stage, the longer it takes to complete any one given issue. Work In Progress (WIP) limits are commonly used by teams that practice Kanban and is a proven method to improve throughput.

As of 12.8, you can now set WIP limits based on max Issue count per list in an Issue Board. If you exceed your limit, the list background color will change to red.

Documentation Issue Merge Request

Visually differentiate blocked issues on issue boards

Visually differentiate blocked issues on issue boards

SaaS

Self-Managed

Blocked issues need attention! Being able to differentiate which issues are blocked while looking at your issue board makes it easier than ever to identify what may be slowing down your team. Remove blockers, and enable your team to run more efficiently than ever!

Documentation Issue

Automatically stop environments after a specified period

Automatically stop environments after a specified period

SaaS

Self-Managed

You can now set the expiration time to stop environments automatically after a certain idle period. This is especially useful for short-lived environments (such as the ones used for Review Apps) to avoid wasting resources. It can be set up through a new entry in .gitlab-ci.yml, for example, auto_stop_in: 1 week, and can be manually overridden from the GitLab UI. Users can also disable auto-stop by pinning their particular environment through the UI and keeping the environment running regardless of the setting.

By preventing a situation where many stale environments are laying around, you don’t waste infrastructure resources by keeping them running. You also gain back development time that would otherwise be spent manually stopping environments.

Documentation Issue

Automatically stop environments after a specified period

Instance-level Security Dashboard

Instance-level Security Dashboard

SaaS

Self-Managed

An instance-level view of the security vulnerabilities is now available. Use this dashboard to see an overview of possible security issues across all of your groups and projects.

In addition to seeing a list of vulnerabilities in your projects and a trend of vulnerabilities over time, you are now able to see your projects across all of your groups categorized by their Security Report letter grade for quick decision making as to which project needs the most attention.

Documentation Issue

Automated accessibility scanning of Review Apps

Automated accessibility scanning of Review Apps

SaaS

Self-Managed

Accessibility of web pages and applications is a growing concern for software developers today. Unfortunately, accessibility testing is often an afterthought occurring late in the software development process. It’s typically a manual and inconsistent process if it’s done at all. Development teams often lack clear requirements from Product Managers or Product Designers outlining accessibility standards to follow when building an application.

Starting in GitLab 12.8, you will be able to automatically scan and get a report of accessibility issues in your Review App. This saves development time by bringing the feedback loop of accessibility issues much closer, so you can have the most impact on making the application accessible for all users. As a first step, you can download a report for every Merge Request.

We see this as a solid foundation to build on in the accessibility testing category. We are looking forward to feedback from customers on our Accessibility Testing category vision.

Documentation Issue

Automated accessibility scanning of Review Apps

12.8 Other improvements in GitLab 12.8

Credential inventory for group-managed accounts

Credential inventory for group-managed accounts

SaaS

Self-Managed

Managing access to your GitLab.com groups requires visibility into the credentials people are using to take actions within those groups.

In GitLab 12.8, we’ve extended the credentials inventory from self-managed instances to GitLab.com. Now, owners of group-managed accounts can view the SSH credentials and personal access tokens that exist within their groups. This inventory shows the user, the type of credential, and the expiration date so you can make informed decisions about access and rotation.

Documentation Issue

New audit events

New audit events

SaaS

Self-Managed

We’re continuing to add audit events to improve the visibility of activity in your self-managed instances and GitLab.com groups. In this release, we’ve added administrator actions to create, block, or delete users and include username changes in the self-managed instance logs.

These new audit events will help compliance-minded organizations to maintain separation of duties, access management, and nonrepudiation.

Documentation Epic

Dark syntax highlighting theme for Web IDE

Dark syntax highlighting theme for Web IDE

SaaS

Self-Managed

GitLab has long supported alternative syntax highlighting themes for use when browsing files in the repository or viewing diffs during the code review process. However, our code editor areas have not supported the use of this preference despite being the most requested feature for the Web IDE.

The Web IDE now supports the Dark syntax highlighting preference in the code area. We’ve started with this theme, as it’s the most widely used one beyond our default, but we’ll continue to expand our support for syntax highlighting preferences in the Web IDE. We’ll also be working on expanding the dark theme to the rest of the Web IDE, including the file tree and sidebars.

Dark syntax highlighting theme for Web IDE

Documentation Issue

Enable Git delta islands core

Enable Git delta islands core

SaaS

Self-Managed

Depending on the structure of a Git repository’s packfile on disk, cloning can be CPU- and memory-intensive because Git may need to build and compress a packfile on the fly. Extreme CPU and memory use can occur when a large repository is cloned many times simultaneously, for example during a parallelized CI pipeline. However, if you trigger packfile reuse, instead of constructing the response on the fly, Git streams the packfile directly from disk, eliminating most CPU and memory usage of the clone.

In GitLab 12.8, when repacking repositories, a delta island core is created that contains all the reachable branches and tags so that packfile reuse is triggered when cloning a Git repository. GitLab performs repacks automatically for active repositories, but they can also be triggered manually by clicking Run Housekeeping in the projects General Settings. Note, when using a shallow clone strategy for CI, packfile reuse will not be triggered.

Documentation Issue

Faster repository browser

Faster repository browser

SaaS

Self-Managed

Exploring the source code of a project you’ve just discovered, or a project which you contribute to is now faster. In GitLab 12.8, when browsing between directories, the file list and commit data are updated without reloading the entire page, which eliminates unnecessary page loads.

Documentation Epic

Merge Request changes are loaded progressively

Merge Request changes are loaded progressively

SaaS

Self-Managed

Merge Requests, particularly the Changes tab, is where source code is reviewed and discussed. Previously, as proposed changes became larger, the diff would load slowly and couldn’t be read until fully loaded.

In GitLab 12.8, the file changes list loads immediately, and the diffs are loaded progressively so that you can begin reading the diff almost immediately rather than waiting for the page to load fully.

Documentation Issue

Smarter Git packfile reuse

Smarter Git packfile reuse

SaaS

Self-Managed

In GitLab 12.8, we are including a patched version of Git 2.24 in GitLab Omnibus with improvements to Git packfile reuse.

When a client fetches or clones, it is more efficient for the server to respond by reusing existing packfiles as much as possible. The improvements implement a new smarter algorithm for reusing packfiles that makes a better compromise between the cost to serve a clone or a fetch, and the quality of the resulting packfile.

Thank you Peff and GitHub for sharing this improvement, and Jonathan Tan (Google) for your help reviewing! We hope the patches land in Git 2.26.

Documentation Issue

Allow-failure action is now available in new rules syntax

Allow-failure action is now available in new rules syntax

SaaS

Self-Managed

Expanding on our new rules syntax, it is now possible to define pipeline rules that are allowed to fail. This gives users more flexibility when setting up their job behaviors and makes it easier to migrate additional projects to our new, more human-readable syntax.

Documentation Issue

Extended log length in pipeline failure emails

Extended log length in pipeline failure emails

SaaS

Self-Managed

The length of the log in pipeline failure emails has been increased from 10 to 30 rows, making it easier to see more of the trace and more likely that the complete error message is included in the email.

Thanks to Philipp Hasper for the contribution!

Documentation Issue

Jobs in Directed Acyclic Graph (DAG) pipelines can be set up with no predecessors

Jobs in Directed Acyclic Graph (DAG) pipelines can be set up with no predecessors

SaaS

Self-Managed

Specifying an empty needs: array can be used to indicate to GitLab that there is no predecessor for that job and that it can always start immediately, regardless of what stage it is in. You can use this to set up more flexible relationships in a DAG pipeline, speeding them up and making them more efficient.

Documentation Issue

GitLab NPM Registry to support NPM distribution tags

GitLab NPM Registry to support NPM distribution tags

SaaS

Self-Managed

To verify that their NPM package was uploaded or to look up the correct version of a package, users would like to use package metadata. NPM tags can be used to provide an alias instead of version numbers, making it easier to discover packages. For example, a project might choose to have multiple streams of development and use a different tag for each stream, such as stable, beta, dev, or canary.

In GitLab 12.8, we are excited to announce that we now support NPM distribution tags in the GitLab NPM Registry. You can now add, remove, and list tags associated with any package hosted in their registry, making it both faster and easier to find and discover packages.

Documentation Issue

Improved performance for the GitLab Container Registry garbage collection algorithm for S3

Improved performance for the GitLab Container Registry garbage collection algorithm for S3

SaaS

Self-Managed

For organizations building many images across many projects, it is important to remove old, unused images and tags. The container registry garbage collection takes a long time to run and consumes resources inefficiently during the process. This makes it difficult for instances with large registries to run garbage collection and results in an increased cost of storage.

In GitLab 12.8, we are excited to announce a significant improvement in the performance of garbage collection for instances using S3 for storage. These improvements optimize both the mark and sweep phase of the algorithm. While testing on 15 thousand images, the mark phase went from 25 minutes to 90 seconds! The sweep phase went from 20 minutes to 3 seconds! Read more on performance tests and benchmark optimization in the merge request.

Documentation Issue

Leverage policies to remove Docker images

Leverage policies to remove Docker images

SaaS

Self-Managed

You build many Docker images as part of your pipelines, however, many of these images are only needed for a short time. Until now, you’ve had to rely on removing images via the Container Registry API or using the user interface. Both require effort. Wouldn’t it be great to define a policy and have those unwanted tags removed automatically?

In 12.8, we are excited to introduce Docker tag expiration policies for all new projects. This new feature allows you to identify a tag by name, select how many versions of the tag to keep, and define when it should be removed. For example, you can set up a policy that will remove all tag names that match a regex like the Git SHA, always keep at least five images, and remove any image that is older than 30 days.

Leverage policies to remove Docker images

Documentation Issue

Collect Release Evidence at Release end date

Collect Release Evidence at Release end date

SaaS

Self-Managed

When users first create a Release entry, a snapshot of the metadata is taken for Evidence in the event of an audit. As of 12.8, we automatically take an additional snapshot of the Release Evidence at the Release end date. By providing a second snapshot, it becomes possible to compare the start state of a Release with its end state. This gives audit teams better visibility into what changed between these two points in time.

Documentation Issue

Documentation for using earlier Knative Versions

Documentation for using earlier Knative Versions

SaaS

Self-Managed

As Knative approaches version 1.0, many GitLab users need to build older versions of Knative as many kinks in the Knative upgrade process have not yet been ironed out. A problem arises because new versions of gitlabktl only support a specific version of Knative because of API changes. Because GitLab Serverless is in alpha, we’ve chosen not to support backward compatibility. As we shipped updates, each version of gitlabktl has only supported a specific version of Knative. While this strategy keeps development simple and lets us iterate quickly, it has made it painful to update GitLab, because we were forced to update Knative as well.

The solution to this problem is to use a pinned version of gitlabktl. While this has always been possible, it hasn’t been easy to figure out. We’ve now added a clear set of instructions to our docs to aid in discoverability and execution.

Documentation Issue

Install more Kubernetes applications using CI/CD templates

Install more Kubernetes applications using CI/CD templates

SaaS

Self-Managed

Installing Kubernetes applications using GitLab CI/CD provides a great way to customize applications before installation.

In GitLab 12.8, new templates are available for installing JupyterHub and the Elastic Stack using GitLab CI/CD. Installing applications via GitLab CI/CD will additionally enable version control and access control to the installed charts.

SaaS

Self-Managed

Managing errors in your application is tough enough without needing to also remember to close the GitLab issue after fixing the error. GitLab issues now close automatically after the related Sentry error is resolved. It eliminates the extra manual work and prevents confusion over which issues are still active.

Documentation Issue

Duplicate a dashboard including custom metrics

Duplicate a dashboard including custom metrics

SaaS

Self-Managed

Previously, duplication of dashboards included only default metrics. With this new enhancement in 12.8, custom metrics are now included when cloning a default dashboard with both custom and default metrics.

Duplicate a dashboard including custom metrics

Documentation Issue

Navigate from metrics chart to logs

Navigate from metrics chart to logs

SaaS

Self-Managed

When troubleshooting an incident, reviewing both logs and metrics is important. When viewing a metric chart, you can now drill down directly into the log explorer while preserving context and without ever leaving the GitLab console.

Documentation Issue

Searchable environment in metrics dashboards

Searchable environment in metrics dashboards

SaaS

Self-Managed

Searching for a specific environment could get cumbersome when you have many of them. You can now quickly find the environments you want to see in the metrics dashboard with the new search bar in the dropdown menu.

Searchable environment in metrics dashboards

Documentation Issue

Support Go Modules in Dependency Scanning

Support Go Modules in Dependency Scanning

SaaS

Self-Managed

We are excited to add support for Go Modules as a Dependency Scanning supported language.

Although this scanner is viable, the feature is currently in alpha as the database only contains Go Module vulnerability definitions from 2019 and later. We appreciate any feedback in this epic around the age and types of Go support desired in addition to any issues you experience. It will help us continue to move this language support out of alpha.

Documentation Issue

Geo moves towards a self-service developer framework

Geo moves towards a self-service developer framework

SaaS

Self-Managed

Geo helps distributed teams by replicating data to local Geo nodes, and is also used for disaster recovery. Today, some of GitLab’s features are not yet supported by Geo. We want all upcoming features to ship with Geo support out of the box. To accomplish this, we are moving towards a developer framework, which will make it easier for developers in the GitLab community to contribute new data types that need to be replicated and verified.

This is valuable, because it standardizes the technical processes used in Geo to extend Geo to other parts of GitLab, and it will give the GitLab developer community a solid technical foundation to contribute future features and improvements to Geo. Effectively, future development work will be faster and more efficient.

In this release, we have merged a significant first iteration for package files that establishes the technical foundations of this work. In the next iteration, we will add support for package file replication and verification.

Documentation Issue Epic

PostgreSQL 11 is now available in Omnibus GitLab

PostgreSQL 11 is now available in Omnibus GitLab

SaaS

Self-Managed

The Omnibus GitLab package now includes PostgreSQL 11. The PostgreSQL 11 release includes enhancements to partitioning and other performance improvements that we will be building upon in GitLab 13.x to increase its overall speed and responsiveness. PostgreSQL 11 has been fully tested with Omnibus GitLab for new installs and upgrades, including HA configurations. Testing with Geo is in progress.

Upgrades to PostgreSQL 11 are opt-in for GitLab 12.8. For instructions on upgrading, see the upgrade notes. New installs, and automatic upgrades from 9.6, will still default to PostgreSQL 10. PostgreSQL 11 will become opt-out in GitLab 12.10 and the minimum required PostgreSQL version in GitLab 13.0. For more details about GitLab’s PostgreSQL 11 roadmap, see the epic for adding support for PostgreSQL 11.

We encourage administrators of instances not using Geo to upgrade to PostgreSQL 11 at their earliest convenience to benefit from performance improvements and to prepare for the removal of PostgreSQL 9.6 and 10.x in GitLab 13.0.

Documentation Issue

Bug fixes

Bug fixes

SaaS

Self-Managed

Some of the notable bug fixes in GitLab 12.8 are:

Bug Fixes

Disable self-approval at the instance level

Disable self-approval at the instance level

SaaS

Self-Managed

We’ve introduced new instance-level settings to prevent unwanted changes to merge request approval settings by bringing some of the merge request approval settings from the project settings into the Admin Area. This will give administrators better control of their deployments and allow them to maintain separation of duties when deploying code.

By enabling these settings at the instance level, all projects in a self-managed instance are forced to adopt these settings, and only administrators can change them for an individual project. This new enforcement capability ensures only approved deployments make it into production and brings your GitLab projects into a more compliant state.

Documentation Issue

Change the name of the Service Desk user

Change the name of the Service Desk user

SaaS

Self-Managed

Emails sent from your Service Desk on GitLab.com come from the GitLab Support Bot by default. Many times, the originator of the issue does not know that they are emailing GitLab, which makes it confusing.

It’s now possible to configure the name for your Service Desk user! This allows you the opportunity to give your users a recognizable name that matches your brand!

Documentation Issue

Drag-and-drop Design badges

Drag-and-drop Design badges

SaaS

Self-Managed

When viewing a design inside the Design tab of an issue, you can drop comment badges on any area of the image and attach a comment. This is great for having point-of-interest discussions. However, as feedback is given and you upload new revisions, sometimes you need to move the badge to a new spot. This release lets you drag badges around. Now you can:

Drag the comment badge around after you drop it.
Move someone else’s badge over to fit yours.
Move the badges to match a new Design after you make a layout revision.

Documentation Issue

Enable Git protocol v2 for HTTP

Enable Git protocol v2 for HTTP

SaaS

Self-Managed

We’ve re-enabled support for Git protocol v2 over HTTP. It was previously announced in GitLab 11.4, but was disabled due to a security issue in Git versions before Git 2.21.

Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.

Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and tens of megabytes of data.

Git protocol v2 is supported from Git 2.18.0 and is opt-in. To enable it, run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled. Follow this issue for updates.

Documentation Issue

Merge Request Approval Rules for Protected Branches

Merge Request Approval Rules for Protected Branches

SaaS

Self-Managed

Code review is an essential practice of every successful project, and Approval Rules can be used to make sure the right people review each change. When practicing continuous delivery or working on higher risk projects, this is especially important. Previously, adding more restrictive approval requirements to protect the default branch would impose the same requirements on every branch. This forced all merge requests to meet the same approval requirements, whether it be merging a bug fix from master into a release branch, or between two feature branches.

GitLab 12.8 resolves this problem: Approval Rules for Merge Requests set at the project level can be required selectively based on the target branch of the merge request. This allows restrictive approval rules to apply exactly when needed, and even different approval rules to apply to different branches like for stable release branches.

Documentation Issue

S/MIME Signature Verification of Commits

S/MIME Signature Verification of Commits

SaaS

Self-Managed

Every commit in a Git repository has an author, but this is not verified by Git and means that it is easy to create commits that appear to be authored by someone else. Commit signing allows you to prove that you are the author of the commit. This is important for sensitive projects and in some commercial environments.

In Git 2.19, OpenGPG signing and verification support was extended to include support for S/MIME using X.509 certificates, because managing these certificates is more friendly for large organizations.

GitLab now also supports S/MIME Signature Verification of commits, thanks to Roger Meier from Siemens! Further thanks go to Henning Schild, also from Siemens, for contributing this feature to Git in the first place!

Documentation Issue

Tab width user preference

Tab width user preference

SaaS

Self-Managed

Tabs, in contrast to spaces, are more than a matter of preference for some. For those who use tabs, the correct tab width is no trifling matter. Particularly for C and Go projects, where tabs are most common, it is important that tab width can be configured to match local preferences for the best code review.

GitLab now provides a Tab width user preference, used when viewing code including diffs, CI logs, and rendered code blocks in Markdown.

Thank you Alexander Oleynikov for your contribution!

Documentation Issue

Automatically bring in artifacts from cross-project jobs

Automatically bring in artifacts from cross-project jobs

SaaS

Self-Managed

You can now specify that a job in a project depends on the latest artifact produced by a job in another pipeline, making it much easier to set up cross-project pipelines that have artifact dependencies on each other.

As an example, you might have a pipeline that builds an executable binary. Before this update, you had to rebuild all of the libraries the binary depended on every time you built the binary, even if the library didn’t change. This was a waste of time and computing power, and the workarounds required using a brittle mix of API keys, cURL, and secure variables. Now, by specifying artifacts: true on your needs: job, you can pull the artifact generated by the library pipeline and use it in your final executable pipeline without the need to rebuild.

Documentation Issue

GitLab Runner 12.8

GitLab Runner 12.8

SaaS

Self-Managed

Welcome to the 12.8 release of GitLab Runner. GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Key highlights include:

You can find the full list of changes in GitLab Runner’s changelog.

Documentation

Clean up corrupted Docker manifests during garbage collection

Clean up corrupted Docker manifests during garbage collection

SaaS

Self-Managed

When running garbage collection to remove old, unused images, users have frequently run into an issue in which the process fails due to corrupted Docker manifests. To resolve this issue, administrators have had to manually remove the corrupted files from object storage, which is slow and risky.

In 12.8, we are excited to announce that any corrupted manifests will now be deleted as part of the garbage collection process. If a bad link file (zero bytes in size or with an invalid checksum) is found during garbage collection, instead of stopping the garbage collector, it will log a warning message and ignore it. Blobs related with invalid link files will be deleted in the sweep stage if those blobs are not associated with another valid link file. This update makes the garbage collection process more reliable and efficient.

Documentation Issue

GitLab metadata is now available in the Package Registry user interface

GitLab metadata is now available in the Package Registry user interface

SaaS

Self-Managed

We learned from a recent round of user research that users navigate to the Package Registry UI to verify which version of a package they should use or verify that their pipeline built it correctly. However, since we did not display any information in the user interface about how a package was built, users were forced to navigate between several different areas of the application.

In GitLab 12.8, we are excited to announce that packages built via GitLab pipelines will now include pipeline_id, branch, and commit in the Package Registry user interface. This will help users understand how a package was built and troubleshoot much easier when something goes wrong!

Documentation Issue

Improved performance of the delete API for the Container Registry frontend

Improved performance of the delete API for the Container Registry frontend

SaaS

Self-Managed

The GitLab Container Registry user interface allows you to view, discover and manage your project’s images. The problem is that deleting a tag has been the worst-performing action on GitLab.com, with some requests taking up to 60 seconds to complete. This has resulted in slow page load times and an increased number of support requests.

In GitLab 12.8, we are excited to announce that we have improved the performance of this function by ~70%. This will improve page load times and reliability.

Documentation Issue

Resolve Docker garbage collection issues for GitLab Container Registries hosted on DigitalOcean S3

Resolve Docker garbage collection issues for GitLab Container Registries hosted on DigitalOcean S3

SaaS

Self-Managed

There is a known Docker issue where Ceph-based storage for all requests with absolute URI impacts the Docker garbage collection process. Since DigitalOcean uses Ceph, it prevents users from running garbage collection if they are using DigitalOcean for storage. This results in higher storage costs for those users.

In GitLab 12.8, we resolved this issue by updating the driver for Ceph to support the latest version of the API. This allows any organization using DigitalOcean for storage for their GitLab Container Registry to run garbage collection and lower their cost of storage.

Documentation Issue

Display Kubernetes namespace on the job page

Display Kubernetes namespace on the job page

SaaS

Self-Managed

When a CI/CD job deploys to a Kubernetes environment, the job detail page will now display the Kubernetes namespace used for that deployment. You can use the detail page to verify workloads are deployed to the correct destination.

Display Kubernetes namespace on the job page

Documentation Issue

Enable Review Apps via a code snippet

Enable Review Apps via a code snippet

SaaS

Self-Managed

We want to make Review Apps easy to set up even if you already have a functioning .gitlab-ci.yml file. A new Enable Review Apps button has been added to the environments page; if you are using Kubernetes and want to enable Review Apps, this will show you the YAML snippet that needs to be added to your .gitlab-ci.yml.

Documentation Issue

Manage access to protected environments from the API

Manage access to protected environments from the API

SaaS

Self-Managed

Until now, users configuring access levels for protected environments needed to update developer and maintainer permissions through the Settings UI instead of the CLI. This wasn’t efficient for users who want to work from the command line and need to maintain the same level of environment access across groups. With this release, maintainers can save time when adding or removing access to protected environments by using the API, rather than having update permissions in the Settings UI.

Documentation Issue

Column charts for Metrics Dashboard

Column charts for Metrics Dashboard

SaaS

Self-Managed

When it comes to visualizing metrics, users often like to choose different types of visualization for different metrics. To help achieve that, we’ve added column charts as a new visualization option on your monitoring dashboard so you can display your data how you want.

Documentation Issue

GitLab self-monitoring project

GitLab self-monitoring project

SaaS

Self-Managed

GitLab administrators can now gain insights into the health of their GitLab instances, using a new base project which will be added under the “GitLab Instance Administrators” group. Created for visualizing and configuring key metrics to monitor your GitLab instance.

Documentation Issue

Scale metrics chart

Scale metrics chart

SaaS

Self-Managed

The y-axis value on the metric chart had previously always started from zero. This made it difficult for users to detect minor changes on the metric charts. Starting with version 12.8, the y-axis values will automatically scale according to the data.

Documentation Issue

Rapidly updated vulnerability database

Rapidly updated vulnerability database

SaaS

Self-Managed

We keep updating our vulnerability database with the latest vulnerabilities. This ensures that GitLab’s scanners are always scanning for the latest vulnerabilities, protecting you and your applications.

In February 2020, we’ve added known vulnerabilities to our database on average within 2.2 days of their announcement. You can see the latest status of our vulnerability updates in the Handbook.

SaaS

Self-Managed

Geo is only available at the Premium and Ultimate tier. Previously, when you tried to enable Geo in the administrator interface using a Starter or Core license, we just told you that the license was invalid - not very helpful! We now provide a clearer message stating which license you are using, which one you need to use Geo, and we also provide a link to manage your license.

We hope you give Geo a try!

Documentation Issue

Omnibus improvements

Omnibus improvements

SaaS

Self-Managed

Omnibus GitLab now includes PostgreSQL 11 as an opt-in version of PostgreSQL. See the main release post announcement for more details.

GitLab 12.8 includes Mattermost 5.19, an open source Slack-alternative. This release of Mattermost includes faster development cycles with GitLab, a Webex plugin, 1-click Mattermost install on DigitalOcean, and security updates. We recommend upgrading from earlier versions.

Documentation Issue

Project import and exports are faster and more reliable

Project import and exports are faster and more reliable

SaaS

Self-Managed

GitLab 12.8 includes significant improvements to how projects are imported and exported, resulting in much faster execution times and improved reliability.

Project exports are now four times faster to complete, with 80% reduction in memory footprint. Previously, large projects could fail to export due to exceeding the memory limitations of the export job. With the reduced footprint, these jobs are now much more likely to succeed.

Project imports are approximately 50% faster, due to a significant reduction in database calls. In the future, we plan to reduce the memory required for imports, by switching to newline-delimited JSON.

Documentation Issue

Performance improvements

Performance improvements

SaaS

Self-Managed

We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!

In GitLab 12.8 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.8 are:

Performance improvements

Deprecations Deprecations

Auto DevOps Auto Deploy setting value deprecated

Auto DevOps Auto Deploy setting value deprecated

Because several APIs were removed in Kubernetes 1.16, the default value of extensions/v1beta1 for the deploymentApiVersion setting in Auto DevOps’ Auto-Deploy chart is now deprecated.

The deploymentApiVersion setting is scheduled to be changed to a new default of apps/v1 in GitLab 13.0.

Planned removal date: May. 17, 2020

Backported `os.Expand`

Backported `os.Expand`

In GitLab Runner 13.0 we will remove the backported os.Expand() from Go v1.10.8. This backport was needed to include a change in behavior introduced in Go v1.11. You can find more details in issue #4915.

Planned removal date: May 22, 2020

Docker services flag on register command

Docker services flag on register command

In GitLab Runner 13.0, we will support the legacy configuration structure for defining services for Docker which used an array of strings. You can find more details in issue #6404.

Planned removal date: May. 22, 2020

GitLab 12.9 will no longer use Alpine for Python Dependency Scanning

GitLab 12.9 will no longer use Alpine for Python Dependency Scanning

We are excited to announce that we are making Debian slim the base image for our Python Dependency Scanning. In issue #13694, we evaluated enhancing our Python support by changing our base image from Alpine Linux, specifically enabling manylinux2010. We decided to switch to Debian slim to make the scanner support more Python projects. You can follow the work in progress in issue #196833.

Because the base image is no longer Alpine Linux, those using Alpine-specific commands, such as apk add <package>, right before the scan (this only applies to users who have disabled Docker-in-Docker) or when building a variant of the official Docker image must make modifications.

Planned removal date: Mar. 22, 2020

GitLab 13.0 renames License Management to License Compliance

GitLab 13.0 renames License Management to License Compliance

GitLab License Management will be renamed to GitLab License Compliance in GitLab 13.0. After review with users and analysts, we determined that this new name better indicates what the feature is for, aligns with existing market terminology, and reduces confusion with GitLab subscription licensing features. You can find the research and work on this issue in the epic Rename License Management to License Compliance. The analyses of your projects done as a part of License Compliance will be called License Scanning.

Starting with GitLab 12.8, those using the License Compliance vendored template may start using License-Scanning.gitlab-ci.yml instead of License-Management.gitlab-ci.yml. With the release of GitLab 13.0, support for License-Management.gitlab-ci.yml will be dropped, and all users on GitLab 13.0 or later using the License Compliance vendored template will have to use License-Scanning.gitlab-ci.yml.

If you are directly referencing the results of the License Scan running as part of License Compliance, you also need to use the new report type artifacts:reports:license_scanning instead of artifacts:reports:license_management. This is optional with the release of GitLab 12.8 through GitLab 12.10, but mandatory with the release of GitLab 13.0. This will not apply to users of versions GitLab 12.7 and earlier.

Planned removal date: May 22, 2020

Legacy build directory caching feature flag.

Legacy build directory caching feature flag.

In GitLab Runner 13.0, we will remove the legacy build directory caching feature flag that was introduced in 11.10. You can find more details in issue #4180.

Planned removal date: May. 22, 2020

Manual parsing of DockerService

Manual parsing of DockerService

In GitLab Runner 13.0, we will revert to using the default TOML parser. You can find more details in issue #4922.

Planned removal date: May. 22, 2020

Offset pagination limit of 50,000 for /projects endpoint

Offset pagination limit of 50,000 for /projects endpoint

An offset-based pagination limit of 50,000 will be applied on GitLab.com, and by default on self-managed instances, to the /projects API endpoint in GitLab 13.0. Integrations which make API calls with offsets above 50,000 will need to switch to a keyset-based pagination method, which will offer significantly improved response times and reduced load on the GitLab server. Self-managed instances will be able to customize the limit to a desired value.

To provide the optimized performance, keyset-based pagination only offers ordering based on project id. Use cases which require more flexible ordering options can continue to use offset-based pagination, provided the offsets remain below the limit. If use cases require flexible ordering options with deep offsets, we recommend sorting client-side.

Planned removal date: May 22, 2020

Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0

Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0

To take advantage of improved performance and functionality in PostgreSQL 11, such as partitioning, we plan to require PostgreSQL 11 in GitLab 13.0. To prepare for this, PostgreSQL 11 is now supported and available in Omnibus GitLab 12.8. While PostgreSQL 9.6 and 10.x are still supported and bundled in Omnibus GitLab, they will be removed in GitLab 13.0.

By requiring a minimum version of PostgreSQL 11, we can use its new features without the overhead of maintaining multiple code paths. Going forward, we will maintain a yearly cadence of PostgreSQL upgrades, with the minimum required version of PostgreSQL being no more than two versions behind the latest. We welcome your feedback on the proposed removals in the Move to PostgreSQL 11 and 12 epic.

Planned removal date: May 22, 2020

Removed `debug/jobs/list?v=1` endpoint

Removed `debug/jobs/list?v=1` endpoint

In GitLab Runner 13.0, we will remove the /debug/jobs/list?v=1 endpoint used for monitoring. This is superseded by the /debug/jobs/list?v=2 endpoint. You can find more details in issue #6361.

Planned removal date: May. 22, 2020

Shell executor legacy process termination feature flag

Shell executor legacy process termination feature flag

In GitLab Runner 13.0, we will remove support for the FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL flag for the shell executor. You can find more details in issue #6413.

Planned removal date: May. 22, 2020

Windows Batch `cmd` for the shell executor

Windows Batch `cmd` for the shell executor

In GitLab 11.11, we deprecated the use of the Windows Batch executor for the GitLab Runner. Support for Windows Batch will be removed in GitLab 13.0. You can find more details in issue #6099.

Planned removal date: May. 22, 2020

`Undefined` will be removed for Severity and Confidence in Secure

`Undefined` will be removed for Severity and Confidence in Secure

Our UX team found that the terminology we used for Severity and Confidence was similar but not the same, which resulted in a lot of confusion. You can read more about that work in the epic Security reports: Remodel severity and confidence. In Secure, we will be deprecating the use of undefined for both Severity and Confidence properties in Security Reports (JSON) and the vulnerabilities API.

If you are searching for or expecting undefined as a filter value in the vulnerability API, you can instead use unknown.

Planned removal date: May 22, 2020

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Changelog Changelog

Please check out the changelog to see all the named changes:

Installing Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

Free
Free-forever features for individual users
Premium
Enhance team productivity and coordination
Ultimate
Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash free license

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert

GitLab 12.8 Release