12.3

GitLab 12.3 Release

GitLab 12.3 released with Web Application Firewall and Productivity Analytics

GitLab 12.3 released with Web Application Firewall, Productivity Analytics, Enhanced Compliance and much more!

This month's release of GitLab 12.3 is especially exciting following an eventful week in which we hosted our first GitLab Users Conference in Brooklyn New York and announced the completion of a $268 million Series E round of fundraising; which will enable us to invest in making all of our DevOps platform offerings, including monitoring, security, and planning, best in class.

Web Application Firewall

Modern web applications are exposed to new risk from many places, including potentially every client that connects and sends traffic. A Web Application Firewall (WAF) provides monitoring and rules to protect applications in production. In GitLab 12.3 we are shipping our first iteration of a Web Application Firewall built into the GitLab SDLC platform. Its focus is on monitoring and reporting of security concerns related to your Kubernetes clusters. Future releases will expand the WAF capabilities to block malicious traffic, create and manage firewall rules, and inform earlier stages of development to take action to further reduce risk.

Productivity Analytics - First Release

Software delivery teams everywhere need the right information and insight in order to improve their productivity and efficiency. Too often, invisible bottlenecks and roadblocks force teams to wait and waste time rather than delivering new features. Beginning with 12.3, we’re starting to release new analytics features to help teams and leaders better understand their overall productivity and effectiveness for both Groups and Projects. Productivity Analytics will help teams and their leaders discover best practices to improve productivity. Initially focusing on the time it takes to merge MRs, GitLab will make it possible to drill into the data and learn insight that can guide future improvements. In many organizations, leaders are responsible for multiple projects and Group level analytics workspace is intended to provide productivity and performance insight and visibility across multiple projects. These two features are only the first in a series of updates that will specifically improve visibility and insight so that teams can become more efficient.

Enhanced Compliance

Compliance with policies and procedures is a common challenge that software teams face. For many GitLab users, having development teams collaborate in a single application makes compliance easier. In this 12.3 release of GitLab, we're including several features that will continue to streamline efforts to reduce compliance risks. MR approval rules provides a way to prevent teams from merging in code that introduces unsupported licenses. Require code owner approval per branch makes it possible to protect branches and require code owner approval of changes.

And much more!

There are so many great features within GitLab 12.3 that we couldn’t possibly highlight them all (even though we really want to). Better resource visibility with Global view for group-level cluster deployments/environments, more efficient Git fetches with Compress Git ref advertisements over HTTP, and more efficient reviews with Keyboard Shortcut for Next and Previous Unresolved Discussion

Register now to join us at our first European user conference in London on Oct 9!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Cédric Tabin

Cédric’s contribution to GitLab 12.3 adds a new CI job keyword allowing interruptible builds. They worked for more than 9 months contributing this feature and working with our review teams to get it across the line.

Thanks so much to Cédric for their tireless effort on this contribution!

12.3 Key improvements released in GitLab 12.3

Web Application Firewall for Kubernetes Ingress

Web Application Firewall for Kubernetes Ingress

GitLab now adds the modsecurity Web Application Firewall (WAF) plug-in to your cluster when you install the Ingress app in your Kubernetes cluster.

The WAF is able to determine whether or not HTTP or HTTPS traffic to your app contains malicious code, such as SQL injection, cross-site scripting, or trojans. The WAF is pre-configured with a powerful set of rules, the OWASP ModSecurity Core Rules (CRS), to detect many different types of attacks out-of-the-box.

The documentation describes how to view the WAF logs so you can see what type of malicious traffic your app is subjected to when it is running in production.

Productivity Analytics

Productivity Analytics

Currently there are relatively few sources of data and analytics, which can help engineering leaders understand their team, project, and group productivity. As Peter Drucker has once said, “What’s measured improves”. Subscribing to this view, we are releasing our first iteration of Productivity Analytics in order to help engineering leaders uncover patterns and best practices to improve overall productivity. The focus of this release is on the time it takes to merge MRs depending on their size. Users can make use of our existing filters and drill down to a specific author or label in a group for a specific date range. As we go forward and iterate on productivity analytics, we will add additional data points in order to help identify dependencies which may be contributing to increased active development and/or wait times.

Note that in this initial release of Productivity Analytics, we have not backfilled the historical data for the newly derived metrics to ensure that this background process does not adversely impact the upgrade from 12.2 to 12.3. You’re welcome to follow the issue, where we are working on that here.

Productivity Analytics

Global view for group-level cluster deployments/environments

Global view for group-level cluster deployments/environments

Provisioning a group-level cluster is a great way for operators to provide an application development platform for developers. Scaling cluster resources can be challenging and requires a global view of resource usage. The new “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.

Global view for group-level cluster deployments/environments

Leverage merge request approvals to prevent merging prohibited licenses MVC

Leverage merge request approvals to prevent merging prohibited licenses MVC

If you have strict License Compliance restrictions, you may set the License Compliance feature to disallow a merge when a blacklisted license is found in a merge request. This prevents the new introduction of licenses which you have expressly prohibited. Currently you can set the approvers for the License-Check group in project settings then require the check by following the directions outlined in the documentation.

Leverage merge request approvals to prevent merging prohibited licenses MVC

12.3 Other improvements in GitLab 12.3

Analytics Workspace

Analytics Workspace

Engineering and product teams can span multiple GitLab groups and projects, yet most of our analytics have traditionally been developed at the project level. This is why we created a workspace where users can aggregate insights across groups, subgroups, and projects. The Analytics workspace will make it easier for teams and leaders to analyze and manage team metrics. The workspace will be available in Core. However, in some cases, specific features will be available to Enterprise Edition customers. As we move to the Analysis workspace, we will ensure that existing project-level analytics functionality is available to Community Edition users when moved to the new workspace. In GitLab 12.3, we are releasing the first iteration of group and project level Productivity Analytics and group-level Cycle Analytics. In subsequent releases, we will enable the selection of multiple groups and subgroups; porting all analytics features for an instance. We would love your feedback and input on the strategy for Analytics/Value Stream Management

Analytics Workspace

Design Management notifications

Design Management notifications

In GitLab 12.2 we released our initial iteration of Design Management. An important part of continuing to evolve is to ensure users are properly notified about these activities. Conversations in designs will now create To-Do’s for mentioned users and send notifications based on their preferences. This helps to ensure that important feedback isn’t missed and can be actioned. In a future release, we’ll add those conversations to the main discussion tab for an easier conversation flow.

Design Management notifications

API for Merge Request Approval Rules

API for Merge Request Approval Rules

Approval Rules for Merge Requests allow you to communicate who should participate in code reviews by specifying the eligible approvers and the minimum number of approvals for each. Approval rules are shown in the merge request widget so the next reviewer can easily be spotted.

In GitLab 12.3, support for Approval Rules has been added to the API for Projects and Merge Requests.

Keyboard shortcut for next and previous unresolved discussion

Keyboard shortcut for next and previous unresolved discussion

Reviewing, discussing and resolving feedback is the basis of code review in GitLab. The Jump to next unresolved discussion button makes it easy to quickly jump from discussion to discussion.

In GitLab 12.3, the new n and p keyboard shortcuts to move to the next and previous unresolved discussions in Merge Requests make it even more convenient to review changes.

Keyboard shortcut for next and previous unresolved discussion

API to require merge request approval by code owners per branch

API to require merge request approval by code owners per branch

Using merge request approvals to restrict how code is pushed to protected branches is helpful for promoting code quality and implementing compliance controls. But not all merge requests target stable branches, and not all stable branches need the same controls.

In GitLab 12.3, it is possible to require code owners’ approval for specific branches (through the API) to prevent directly pushing changes to files with code owners, or merging changes without the code owners’ approval.

Note: This feature is only available via the API in GitLab 12.3. In GitLab 12.4 it will be available through the Protected Branch settings. Follow issue #13251 for updates.

Flexible ‘rules’ keyword for controlling pipeline behaviors

Flexible ‘rules’ keyword for controlling pipeline behaviors

Only/except rules in pipelines can have a lot of implicit behaviors, and as more and more are added to your pipelines, it can become very difficult to understand if a given job is going to run or not in different situations. We are introducing a new rules: syntax that will make it much easier to implement and understand complex rules. This syntax is optional and can exist in the same pipeline, but not the same jobs, as the current only/except approach.

‘only/except: external_pull_requests’ for external repositories

‘only/except: external_pull_requests’ for external repositories

GitLab CI has an “external repos” capability intended to allow customers to use external repos for source control and GitLab for CI/CD. Until now, however, the CI_PIPELINE_SOURCE always showed push because it was based on the pull mirror rather than the source external repo or webhook. This prevented GitLab us from correctly supporting only/except: merge_requests-style options. In the 12.3 release we’ve resolved this limitation.

Remove container images from CI/CD

Remove container images from CI/CD

The GitLab Container Registry allows users to leverage GitLab CI/CD to build and push images/tags to their project. Changes to the Container Registry are made by a service account called “CI Registry User” that is invoked from .gitlab-ci.yml with the predefined environment variable CI_REGISTRY_USER. Previously, this service account could push new tags to the registry, but it lacked permissions to untag images. This prevented branch-specific images from being removed, resulting in additional storage costs and creating difficulty when navigating the registry user interface due to the large number of additional, unneeded tags.

In 12.3 we have expanded the permissions of CI_REGISTRY_USER to allow for untagging of images so you can clean up branch-specific tags as part of your regular CI/CD workflow and use GitLab CI/CD to automate your cleanup scripts. This issue is part of a larger epic to lower the cost of the Container Registry by improving storage management.

Remove container images from CI/CD

Validate domains when performing full DAST active scans

Validate domains when performing full DAST active scans

You can now ensure DAST only performs active scans against domains which are intentionally configured for DAST scanning.

This helps to ensure that DAST active scans are not unintentionally run against domains which could be serving content or being used in a production capacity.

There is no change to passive DAST scans, since passive scanning does not potentially negatively impact scanned sites.

SAST Spotbugs analyzer updated for Java 11

SAST Spotbugs analyzer updated for Java 11

The SAST SpotBugs analyzer has been updated to allow scanning of code written with Java 11.

You can enable this by setting the SAST_JAVA_VERSION environment variable in your project.

Run Pipeline button for Merge Request Pipelines

Run Pipeline button for Merge Request Pipelines

Pipelines for merge requests recently introduced a new way to run a pipeline in the context of a merge request, but the only way to trigger a new run of one of these pipelines was through a push. In this release we’ve added a button to start a new pipeline, making it much easier to retry a failed pipeline.

User-defined CI variables available to docker build with Auto DevOps

User-defined CI variables available to docker build with Auto DevOps

CI variables allow you to tailor how processes are run to build your application as part of your CI pipeline. Starting in GitLab 12.3, you can extend the availability of user-defined CI variables to the docker build step in Auto DevOps. The data is made available as a new build secret value.

List one or more variables using the AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES variable and it will be made available to use in docker build.

Knative for group and instance-level clusters

Knative for group and instance-level clusters

Group and instance-level clusters now support the installation of Knative, the Kubernetes-based platform to deploy and manage serverless workloads. This will allow multiple projects to make use of GitLab Serverless features leveraging a single cluster.

Line charts for metrics dashboard

Line charts for metrics dashboard

When it comes to visualizing metrics, oftentimes users would like to choose different types of visualization for specific metrics (e.g., line chart for CPU, area chart for disk space). To help achieve this, we added line charts as a part of our effort to enhance our dashboard offering around monitoring.

Line charts for metrics dashboard

Quick actions to add/remove Zoom meetings on issues

Quick actions to add/remove Zoom meetings on issues

Synchronous collaboration is a critical part of any fire-fight. We are streamlining the number of steps it takes to spin up a conference bridge and engage all required parties by embedding this functionality, using Zoom, directly in an issue.

Once a user has started a Zoom meeting, they can attach it to an issue using a quick action and inputting the Zoom meeting URL (e.g. /zoom https://gitlab.zoom.us/s/123456). A button will appear at the top of the issue giving users direct access to the conference bridge. When the incident has resolved, the Zoom meeting can be removed using /remove_zoom.

This feature is generally available on GitLab.com and feature flagged for use on self-managed instances. If you are interested in taking advantage of this feature for your self-managed instance of GitLab, operators can enable the issue_zoom_integration feature flag. In next month’s release of GitLab 12.4 we plan to remove the feature flag and make the Zoom Issue integration generally available for all self-managed users.

Quick actions to add/remove Zoom meetings on issues

Geo displays secondary lag when pushing via Git HTTP

Geo displays secondary lag when pushing via Git HTTP

Fetching large amounts of data can take a long time for users in remote locations. Replicating repositories with Geo reduces the time it takes to clone and fetch large repositories by creating read-only secondary nodes near remote user. Because secondary nodes lag behind the primary node, GitLab now provides an estimate of replication lag whenever git push is used over HTTP. This raises the visibility of using a Geo node and allows users to detect increases in replication lag and report them to systems administrators.

Because of protocol limitations, this message is not available when using git pull.

Disable 2FA for selected OAuth providers

Disable 2FA for selected OAuth providers

Organizations using enforced two-factor authentication and an identity provider also using 2FA may find the requirement to authenticate twice frustrating. Thanks to a community contribution, you’re now able to bypass 2FA for selected OAuth identity providers in GitLab. For those using providers that handle 2FA, this makes logging into GitLab a friendlier and easier experience.

Thanks to dodocat for the contribution!

IP address restriction supports multiple subnets

IP address restriction supports multiple subnets

Iterating on restricting group activity by IP address, GitLab 12.3 introduces the ability to specify multiple IP subnets. For geographically distributed organizations, this helps this feature shine; instead of specifying a single (and overly permissive) range, large organizations can now restrict incoming traffic to their specific needs.

Design Management status and discussion counts

Design Management status and discussion counts

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 the activity in each version of Designs wasn’t clear to the user. Now, when designs are uploaded, status icons are added in each version to let you know if it’s a new design or a change to an existing design. We also added discussion counts on designs to better inform users of conversations happening. We’re excited about these additions to Design Management to help improve the collaboration and conversation inside of GitLab for design and engineering teams.

Design Management status and discussion counts

Compress Git ref advertisements over HTTP

Compress Git ref advertisements over HTTP

When fetching changes to a Git repository, the Git server advertises a list of all the branches and tags in the repository. This is called ref advertisement and can be many megabytes for large projects.

In GitLab 12.3, when fetching over HTTP, the ref advertisement will be compressed for supported clients reducing the amount of data being transferred and making fetch operations faster.

On an average weekday, GitLab.com serves about 850GB of ref advertisements over HTTP. After enabling ref compression, bytes transferred has decreased by approximately 70 percent.

Compress Git ref advertisements over HTTP

Audit logs for Git Push events (Beta)

Audit logs for Git Push events (Beta)

Git history can be rewritten to change commits, authors and timestamps, which makes it possible to craft clear and useful history for future developers. For audit, this is a problem.

In GitLab 12.3, Git push events that add commits, rewrite history or otherwise modify the repository can be added to the audit log. Audit logs for push events are disabled by default to prevent performance degradation on GitLab instances with very high Git write traffic.

In an upcoming release, Audit Logs for Git push events will be enabled by default. Follow #7865 for updates.

Smarter Web IDE default commit options

Smarter Web IDE default commit options

Previously the Web IDE defaulted to Commit to current branch when making a commit. This made it easy for those with permissions to accidentally push changes to master or other protected branches. Now when making changes in the Web IDE, the default commit options are smarter to prevent making changes to the wrong branch. Smarter commit options prevent accidental pushes to master and protected branches for users with write access. When the user has no write access, additional details are provided as to why options are unavailable. Additionally, the new commit options also support commits to a non-default branch with or without an existing Merge Request.

Smarter Web IDE default commit options

Per-job timeouts for CI/CD pipelines

Per-job timeouts for CI/CD pipelines

Different jobs have different execution characteristics and may need different timeouts to be set on a per-job basis. Timeouts can be configured by adding the timeout: keyword to your job in .gitlab-ci.yml, along with a number to indicate the number of minutes to wait before the job fails.

Thanks to Michal Siwek for the contribution.

‘interruptible’ keyword to indicate if a job can be safely canceled

‘interruptible’ keyword to indicate if a job can be safely canceled

The new interruptible keyword can be used to indicate whether or not a job should be canceled if made redundant by a newer run of the same job. The keyword defaults to false, so it should be used to specify jobs that are safe to stop. This value will only be used if the automatic cancellation of redundant pipelines feature is enabled.

This helps avoid duplication of unnecessary jobs across your pipelines, reducing costs and making your pipelines more efficient.

Due to a bug in the Runner, some executors do not stop in-progress jobs when cancelled. This is planned to be fixed in 12.4.

Status checking for pipeline triggers

Status checking for pipeline triggers

We’ve recently improved the way cross-project pipelines can trigger each other, but one thing still missing was having the triggering pipeline wait or confirm success of the triggered pipeline. It was possible using API polling, but in this release we’ve introduced the depends and wait strategies where this can be handled automatically for you. If you are triggering a pipeline you want to depend on, it will wait for the pipeline to complete and will verify it succeeds before finishing the triggering job. If you choose wait, it will wait for it to finish but proceed regardless of pass/fail status.

API endpoint to list the Docker images/tags of a group

API endpoint to list the Docker images/tags of a group

The GitLab Container Registry allows users to build and push Docker images/tags to their project from the command line, CI/CD, or from an API. However, until GitLab 12.3 we did not offer any visibility into images/tags at the group level, a popular request from users.

We have added two API endpoints that will give visibility into which images and tags exist at the group level. This is the first step in helping improve visibility and discoverability for the Container Registry. Next, we’ll leverage the API to create a group-level browser as part of the Container Registry user interface.

SAST scanning without Docker-in-Docker

SAST scanning without Docker-in-Docker

SAST scans can now optionally be done without using Docker-in-Docker.

This means SAST scanning can be configured to not need elevated privileges.

Edit vulnerability dismissal reasons

Edit vulnerability dismissal reasons

Vulnerability dismissal reasons can now be edited and deleted.

This allows you to add and update context for a vulnerability as you learn more over time.

Edit vulnerability dismissal reasons

Improve Pages initial setup experience

Improve Pages initial setup experience

To improve the Pages user experience, we added a banner that notifies users of the possible initial setup time. We understand it can be frustrating to see the “Congratulations” message without the page being available. The banner helps make it more clear what to expect.

Improve Pages initial setup experience

Show Kubernetes cluster used for deployment

Show Kubernetes cluster used for deployment

The jobs detail page now displays the name of the Kubernetes cluster that was used for the given deployment. Project owners and maintainers are presented with a link on the cluster name which will link directly to the cluster details page.

Show Kubernetes cluster used for deployment

JupyterHub for group-level Kubernetes clusters

JupyterHub for group-level Kubernetes clusters

Group-level clusters now support the installation of JupyterHub, a multi-user service for easily launching notebooks as well as creating runbooks for operators. This extends the availability of JupyterHub to both project-level and group-level clusters.

Close issue via slash command in Slack

Close issue via slash command in Slack

Chat tools are required during fire-fights to resolve modern IT incidents. This tool needs to be closely integrated with the systems you are managing and the tools where you will actually perform remediation. As much as possible, you want to minimize context and tool switching while you’re working to restore services and update your external stakeholders.

In 12.3, we have added an additional slash command to the suite of commands we offer with our ChatOps product based on Slack. Issues can now be closed from Slack without needing to switch tools, just locate the issue in question, and manually close it. You can close it from where you are working.

Close issue via slash command in Slack

Geo natively supports Docker Registry replication

Geo natively supports Docker Registry replication

Geo natively supports replicating a Docker Registry between primary and secondary Geo nodes. This allows Geo users to use a Docker Registry on a close-by secondary node. This approach is storage-agnostic and can be used for object storage, such as S3, or local storage.

When using distributed object storage (e.g. S3) for a Docker Registry, the primary and secondary Geo nodes can use the same storage type. This approach does not rely on Geo’s native replication ability.

API activity included in IP address group restriction

API activity included in IP address group restriction

GitLab 12.0 saw the introduction of restricting a group’s activity by IP address. We’ve iterated on this feature to also include API activity, where incoming requests will be rejected if they do not adhere to the group’s restriction. This solves an important problem for compliance-minded enterprises with an extended approach to access control, covering both UI and API activity.

System hooks for project and group member updates

System hooks for project and group member updates

System hooks allow for powerful automation by triggering requests when a variety of events in GitLab take place. Thanks to a community contribution, project and group membership changes are now supported in system hooks. This is a terrific addition for those who are looking to build additional levels of oversight and automation over membership changes.

Thanks to Brandon Williams for the contribution!

S/MIME Email Signing

S/MIME Email Signing

Notification emails sent by GitLab can now be signed with S/MIME for improved security on the instance level.

Thanks Siemens, @bufferoverflow, and @dlouzan for the contribution!

Omnibus improvements

Omnibus improvements

Deprecations Deprecations

Users with manually configured .gitlab-ci.yml using Secure features should be aware of deprecations in GitLab 12.3

Users with manually configured .gitlab-ci.yml using Secure features should be aware of deprecations in GitLab 12.3

If you have manually configured your .gitlab-ci.yml configuration file to use DEP_SCAN_DISABLE_REMOTE_CHECKS or DS_DISABLE_REMOTE_CHECKS flag variables, you need to remove this as it is no longer supported.

If you utilize vendored templates, your configuration will be kept up to date with variable and argument changes.

As announced in GitLab Release 12.0 post

Planned removal date: GitLab 12.3

gitlab-monitor tool renamed to gitlab-exporter

gitlab-monitor tool renamed to gitlab-exporter

To prevent confusion with the broader GitLab Monitor feature set, the gitlab-monitor tool has been renamed to gitlab-exporter. gitlab-exporter is a Prometheus web exporter that gives administrators insight into their GitLab instance, whereas the GitLab Monitor features enable monitoring of applications built using GitLab. If you’re using Omnibus, you’ll have to update your gitlab.rb file.

Planned removal date: September 22, 2019

Update public projects and subgroups in private groups to private visibility

Update public projects and subgroups in private groups to private visibility

In GitLab 10.0, we introduced a change to clarify the visibility setting of public projects and subgroups in a private group. Since the most restrictive visibility setting applied, attempting to set a project or subgroup to public within a private group resulted in the visibility change being rejected.

To prevent errors with existing projects and subgroups with public visibility, all public projects and subgroups in private groups will be updated from public to private in GitLab 12.5.

If you’d like a less restrictive visibility setting on a particular project or subgroup, you can simply move it out of the private group.

Planned removal date: Nov. 22, 2019

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 Free

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
Edit this page View source