Mar 22, 2019 - Kenny Johnston  

GitLab 11.9 released with secrets detection and multiple MR approval rules

GitLab 11.9 released with secrets detection, multiple MR approval rules, ChatOps in Core, and much more!

Quickly learn if secrets have been leaked

Inadvertently committing credentials to a shared repository can have serious consequences, yet it is a simple mistake to make. Once an attacker gets your password or API key, they can take over your account, lock you out, and fraudulently spend money. This can even lead to a domino effect where access to one account grants access to others. With the stakes so high, it’s of paramount importance to learn as quickly as possible if secrets have been leaked.

With this release, we’re introducing secret detection as part of our SAST functionality. Each commit is scanned by a CI/CD job to ensure it doesn’t contain secrets. If the scan detects secrets, the developer is alerted in the merge request, allowing them to take action quickly to invalidate the leaked credentials and generate new ones.

Enforce proper change management

As an organization grows and becomes more complex, it becomes difficult to keep alignment across different parts of the organization. At the same time, the consequences of merging improper or insecure code also increase when an application has more users and generates more revenue. For many organizations, ensuring proper review process is followed before code is merged is a hard requirement because the risks of not doing so are so great.

With GitLab 11.9, we’re providing greater controls and more structure with Merge request approval rules. Previously, you could specify either an individual or a group for required approval (where any single member of the group can provide approval). Now, multiple rules can be added to a merge request to require individual approvers specifically, or even require a number of approvers from a particular group. Additionally, the Code Owners feature is an integrated part of approval rules, making it easy to track down who should approve.

This allows organizations to implement complex approval flows, all while maintaining the simplicity of GitLab’s single application where issues, code, pipelines, and monitoring data are visible and accessible to inform decisions and speed approval.

Approval Rules have temporarily been disabled on and are not enabled by default in GitLab 11.9 due to a regression.

ChatOps is now open source

GitLab ChatOps is a powerful automation tool, allowing you to execute any CI/CD job and receive the status of the job directly from chat apps like Slack and Mattermost. Originally released in GitLab 10.6, ChatOps was part of the GitLab Ultimate tier. As part of our product strategy and commitment to open source, we occasionally move features down in tier and never move them up.

With ChatOps, we felt this was functionality that everyone could benefit from and that the feature itself could benefit from community contributions.

In GitLab 11.9, we’ve open sourced ChatOps so it is available to use in GitLab self-managed Core and Free, and is open for community contributions.

And much more!

So many great features are available in this release like Auditing for feature flags, Vulnerability remediation merge request, and CI/CD templates for security jobs that you’ll want to read on to learn about them all!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Marcel Amirault

Marcel has continually helped us to make GitLab’s documentation better. He made numerous contributions that improved the quality and usability of our docs. Domo arigato Marcel, we sincerely appreciate it!

Key improvements released in GitLab 11.9

Detect secrets and credentials in the repository

A recurring problem when developing applications is that developers may unintentionally commit secrets and credentials to their remote repositories. If other people have access to the source, or if the project is public, the sensitive information is then exposed and can be leveraged by malicious users to gain access to resources like deployment environments.

GitLab 11.9 includes a new check called Secret Detection. It scans the content of the repository to find API keys and other information that should not be there. GitLab displays results in the SAST report in the merge request widget, pipelines reports, and the security dashboards.

If you already have SAST enabled for your app, you don’t need to take any action to benefit from this new feature. It is also already included in Auto DevOps default configuration.

Detect secrets and credentials in the repository

Merge request approval rules

Code review is an essential practice of every successful project, but who should review the changes is not always clear. It is often desirable to have a variety of reviewers from different teams like Engineering, UX, and Product.

Approval Rules allow you to better 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 quickly be assigned.

In GitLab 11.8, Approval Rules were disabled by default. From GitLab 11.9, they are available by default.

UPDATE: Approval Rules continue to be disabled by default due to a regression

In GitLab 11.3, we introduced Code Owners to indicate which team members are responsible for which code in your project. Code owners are integrated into approval rules so that finding the right people to review your change is always easy.

Merge request approval rules

Move ChatOps to Core

Initially introduced in GitLab Ultimate 10.6, ChatOps has now moved to GitLab Core. GitLab ChatOps provides the ability to trigger GitLab CI jobs from Slack by using the slash commands feature.

We are open sourcing this feature in alignment with our buyer-driven tier designation to encourage its use and contribution by the community.

Move ChatOps to Core

Auditing for feature flags

Operations like adding, removing, or changing Feature Flags are now recorded in the GitLab audit log, giving you visibility into what is changing and when. If you’re having an incident and need to see what changed recently, or just need to look back as an auditor on how your feature flags have been modified, this is now very easy to do.

Auditing for feature flags

Vulnerability remediation merge request

Remediation should be a simple process to quickly fix vulnerabilities in your code. It is important to make security patches easy, allowing developers to focus on what they are supposed to do. In GitLab 11.7, we provided a remediation patch file, but users had to download it, apply it locally, and then push changes back to the remote repository.

GitLab 11.9 automates this flow. Now, remediation can be done without leaving the GitLab web interface. You can create a merge request directly from the vulnerability details window and this new branch will already contain the fix. You can then check if it solves the problem, and merge it into your original branch if the pipeline is green.

Vulnerability remediation merge request

Container Scanning results in the group security dashboard

The group security dashboard allows security engineers to focus on what’s most important to work on, giving a clear and high-level view of all the possible security vulnerabilities affecting their apps. That’s why it is essential that it contains all the relevant information in a single place, and allows users to drill down to start the remediation process.

With GitLab 11.9, Container Scanning results are added to the dashboard, along with the already present SAST and Dependency Scanning findings. You now have a complete view in a single place, no matter the source of the problem.

Container Scanning results in the group security dashboard

CI/CD templates for security jobs

GitLab security features are evolving very fast, and they always need to be up to date to be effective and protect your code. We know that changing the job definition is difficult if you have to manage multiple projects. We also know that you don’t want to risk using the latest GitLab version if you don’t have confidence it is totally compatible with your current GitLab instance.

That’s why with GitLab 11.7, we introduced a new way to include job definitions, using templates.

Starting with GitLab 11.9, we ship built-in templates for all the security jobs, like sast and dependency_scanning, that are compatible with the GitLab version they come with.

You can now include them directly into your configuration, and have them updated with your system every time you upgrade to a new version of GitLab, without any change to any pipeline configuration.

This new way to define security jobs is official and deprecates any other previous job definition or snippet of code. You should update the definition to use the new template keyword as soon as possible. Support for any other syntax could be removed in GitLab 12.0 or other future releases.

CI/CD templates for security jobs

Other improvements in GitLab 11.9

Reply to comment

GitLab has threaded discussions. Up to now, the user writing the initial comment has to decide at the outset if they want a discussion.

With this release, we’ve relaxed that constraint. You can now take any comment in GitLab (in issues, merge requests, and epics) and reply to it, thus starting a threaded discussion. This allows for much more organized collaboration amongst your teams.

Reply to comment

Require merge request approvals from Code Owners

It isn’t always obvious who you should ask to approve your merge request.

GitLab now supports requiring merge request approvals based on which files a merge request changes using Code Owners. Code owners are assigned using a file named CODEOWNERS, a format similar to gitattributes.

Support for automatically assigning Code Owners as merge request approvers was added in GitLab 11.5.

Alphabetically ordered labels

GitLab labels are incredibly versatile, with teams always finding new ways to use them. Consequently, users often add many labels to a given issue, merge request, or epic.

In GitLab 11.9, we are making consuming those labels a little bit easier. In issues, merge requests, and epics, the labels showing up in the sidebar are now ordered alphabetically. This is also the same in the list views of these objects too.

Alphabetically ordered labels

Reorder child epics

We recently released Child Epics, which is the ability to have epics of epics (in addition to child issues of epics).

With this release, you can now reorder the child epics of an epic simply by dragging and dropping, exactly the same as with child issues. This allows teams to use ordering to represent priority or to prescribe an order of implementation of work.

Reorder child epics

Filter by confidential issues

Confidential issues are a useful tool for teams to have private discussions on sensitive topics in an otherwise public project. In particular, they are ideal for working on security vulnerabilities. Until now, it was not particularly easy to manage or surface confidential issues.

In GitLab 11.9, you can now filter by confidential or non-confidential issues in issue list views of GitLab. You can also do the same when retrieving issues via the API.

Thank you, Robert Schilling, for the contribution!

Filter by confidential issues

Expand merge request diff to an entire file

When reviewing the changes in a merge request, the diff for each file can now be expanded to show the entire file for more context and to leave comments on unchanged lines.

Expand merge request diff to an entire file

GitLab self-monitoring with Grafana

Grafana is now bundled in our Omnibus package, making it easier than ever to understand how your instance is performing.

To enable, set grafana['enable'] = true in gitlab.rb, and Grafana will then be available at https://your.gitlab.instance/-/grafana. In the near future, we will also be including a GitLab dashboard out of the box.

In GitLab, you can easily move an issue to another project via the sidebar or with a quick action. Behind the scenes, the existing issue is closed, and a new issue is created in the target project, with everything copied over, including system notes and sidebar attributes. This is a great feature.

While there is a system note indicating the move, users have found it confusing when viewing the now-closed issue, since they may not understand that the issue is closed due to being moved.

With this release, we now indicate right in the badge at the top of the issue page in the closed issue that it has been moved, and also include a link to the new issue inline, so that anyone arriving at the older issue can quickly navigate to the new one.

Link to new issue from a moved and closed issue

Issue Boards are very powerful and teams are creating many boards per project and per group. Recently, we added a search bar to quickly filter down to boards you care about.

In GitLab 11.9, we’ve also introduced a Recent section in the dropdown, so that you can quickly navigate to boards you’ve recently interacted with.

Navigate to recent issue boards

De-duplicated Git objects for public forks (Beta)

Forking allows anyone to contribute to open source projects without needing to give everyone write permissions, by copying the entire repository into a new project. Storing full copies of frequently forked Git repositories is inefficient. Using Git alternates, forks now share common objects from the upstream project in an object pool to reduce disk storage requirements.

Object pools for forks are only created for public projects when hashed storage is enabled. Object pools can be enabled using the object_pools feature flag.

Keyboard shortcuts for next and previous file in merge request

When reviewing the changes in a merge request, quickly jump from file to file using ] or j for the next file, and [ or k for the previous file.

Simplify .gitlab-ci.yml on serverless projects

Building on the include functionality of GitLab CI, the serverless gitlab-ci.yml template has been greatly simplified, allowing new functionality to be introduced in future releases without needing to introduce changes to this file.

Restrict JupyterHub login access only to group/project members

Deploying JupyterHub via GitLab’s Kubernetes integration is a great way to serve and share Jupyter notebooks with large groups. It is also beneficial to control access to notebooks when sensitive or private data is shared.

With GitLab 11.9, login to JupyterHub instances deployed via Kubernetes integration is limited to members with “Developer” project access (via either group or project).

Add Auto DevOps build job for tags

Auto DevOps’ Auto Build stage creates a build of your application by making use of the project’s Dockerfile or a Heroku buildpack.

With GitLab 11.9, the resulting Docker image built in the tag pipeline will be named similarly to traditional image names using the commit tag instead of the commit SHA.

Thank you, Aaron Walker, for the contribution!

Upgrade Code Climate to 0.83.0

GitLab Code Quality uses the Code Climate engine to check how a change will affect the health of your code and project.

With GitLab 11.9, we’ve upgraded the engine to the latest release ( 0.83.0) to bring the benefits of additional language and linting support to GitLab Code Quality.

Thank you GitLab Core Team member Takuya Noguchi for the contribution!

SAST for TypeScript

TypeScript is a relatively new programming language based on JavaScript.

With GitLab 11.9, the Static Application Security Testing (SAST) is able to analyze and detect vulnerabilities in TypeScript code, showing them in the merge request widget, at the pipeline level, and in the security dashboard. You don’t need to change your current sast job definition, and it is also automatically included in Auto DevOps.

Omnibus improvements

The following improvements have been made to Omnibus in GitLab 11.9:

  • GitLab 11.9 includes Mattermost 5.8, an open source Slack alternative whose newest release includes MFA for Team Edition, improved image performance, and much more. This version also includes security updates and upgrading is recommended.
  • A new flag has been added that allows the GitLab Registry to be compatible with versions of Docker prior to 1.10. To enable, set registry['compatibility_schema1_enabled'] = true in gitlab.rb.
  • The GitLab Registry now exports Prometheus metrics and is automatically monitored by the bundled Prometheus service.
  • Support for Google Cloud Memorystore has been added, which requires redis_enable_client to be disabled.
  • openssl has been updated to 1.0.2r, nginx to 1.14.2, python to 3.4.9, jemalloc to 5.1.0, docutils to 0.13.1, and gitlab-monitor to 3.2.0.

Project templates for .NET, Go, iOS, and Pages

To make it easier for our users to create new projects, we shipped several new projects templates:

Move files in the Web IDE

Files and directories can now be moved to a new path in a repository from the Web IDE when renaming a file or directory.

Move files in the Web IDE

Quickly comment when filtering issue activity

We recently released a feature to enable users to filter the activity feed in an issue, merge request, or epic, allowing users to focus on only comments or system notes. Since this setting is saved per person in the system, sometimes a user may not realize they are looking at a filtered feed when they view an issue a few days later and seem to be unable to comment.

In this release, we improved this interaction. Users can now quickly switch back to a mode that allows them to comment without scrolling back to the top of the feed. This applies to issues, merge requests, and epics.

Quickly comment when filtering issue activity

Previously, we added a feature to allow a custom header and footer message to appear on every page in GitLab. This was extremely well received and teams are using it to communicate critical information such as system-wide messages relating to their GitLab instance.

In this release, we’re happy to bring this feature to Core so that even more users can use it. Additionally, we are allowing users to optionally have the same custom messages appear in all emails sent by GitLab, bringing the same consistency to another GitLab user touchpoint.

Custom header and footer system message in web and email

Edit Knative domain post-deployment

Specifying a custom domain when installing Knative allows different serverless applications/functions to be served from a unique endpoint.

GitLab’s Kubernetes integration now allows the custom domain to be changed/updated after Knative has been deployed to your Kubernetes cluster.

Validate Kubernetes CA certificate format

When adding an existing Kubernetes cluster, GitLab will now validate that the CA certificate being entered is in a valid PEM format to reduce possible errors when using the Kubernetes integration.

Run specific jobs on merge requests only when certain files change

In GitLab 11.6, we added the ability to specify only: merge_requests for pipeline jobs to enable users to run certain jobs only when creating a merge request.

Now, we’re expanding that functionality to include conjunction logic with only: changes so that users can run specific jobs only on merge requests when only particular files are changed.

Thank you, Hiroyuki Sato, for this contribution!

View ancestor epics in the epic sidebar

We recently released Child Epics, which is the ability to have epics of epics.

In GitLab 11.9, we’ve made it even easier to see that relationship. You can now see not only your parent epic in a given epic, but your entire epic tree, right in the sidebar. You can see whether those epics are closed or not, and even navigate directly to them.

View ancestor epics in the epic sidebar

YouTrack integration

GitLab integrates with many external issue tracking systems, making it easier for teams to take advantage of GitLab for other features, while still maintaining their issue management tool of choice.

With this release, we now also integrate with YouTrack by JetBrains.

Thank you, Kotau Yauhen, for the contribution!

YouTrack integration

Resizeable merge request file tree

When reviewing the changes in a merge request, the file tree can now be resized to show long filenames or take up less space on smaller screens.

Resizeable merge request file tree

Allow protected branches to be created by developers

Protected Branches prevent unreviewed code from being pushed or merged. However, when no one is allowed to push to a protected branch, no one is able to create a new protected branch, like a release branch.

In GitLab 11.9, developers can now create a protected branch from an already protected branch through GitLab or the API. Using Git to push a new protected branch is still protected to prevent accidentally creating new protected branches.

Filter the merge request list by assigned approvers

Code review is an essential practice of every successful project but, as a reviewer, it can be hard to keep track of which merge requests you have been asked to review.

In GitLab 11.9, the merge request list can now be filtered by the assigned approver, so that you can find the merge requests you have been added to as an approver.

Thank you, Glavin Wiechert, for the contribution!

Filter the merge request list by assigned approvers

Support Ingress hostnames

When deploying a Kubernetes Ingress controller, some platforms may return an IP address (for example, Google’s GKE) while others may return a DNS name (for example, AWS’ EKS).

Our Kubernetes integration now supports both types of endpoints for display in the clusters section of the project.

Thank you, Aaron Walker, for the contribution!

Adjustable time ranges for security dashboard charts

The group security dashboard includes a vulnerability chart to have an overview of the recent security status of your groups’ projects. This is very useful to security directors to tune their processes and understand how the team is performing.

In GitLab 11.9, you can now select the time range of this vulnerability chart. The default is the last 90 days, but you can set the time window to 60 or 30 days, based on the level of details you want to reach.

This doesn’t affect data shown in the counters or in the list, but only data points plotted on the chart.

Adjustable time ranges for security dashboard charts

Zoom and scroll the metrics dashboard

While investigating a performance anomaly, it is often useful to be able to take a closer look at select portions of a given metric.

With GitLab 11.9, users can now zoom in on particular time periods on the metrics dashboard, scroll across the entire time window, as well as easily reset the view back to the original time span. This makes it quick and easy to investigate these interesting events.

Zoom and scroll the metrics dashboard

SAST for multi-module Maven projects

Maven projects are often organized to aggregate multiple modules in one single repository. Previously, GitLab was not able to scan those projects correctly, and vulnerabilities were not reported to developers and security researchers.

GitLab 11.9 introduces improved Static Application Security Testing (SAST) support for this specific project configuration that can now be tested for vulnerabilities out of the box. Because of the flexibility of our analyzers, the configuration is automatically detected and you don’t need to change anything to see results for your multi-module Maven apps. As usual, the same improvements are also available as part of Auto DevOps.

GitLab chart improvements

The following improvements have been made to GitLab charts:

  • Support for Google Cloud Memorystore has been added.
  • Cron job settings are now global settings as they are shared across multiple services.
  • The registry has been updated to 2.7.1.
  • A new flag has been added that allows the GitLab Registry to be compatible with versions of Docker prior to 1.10. To enable, set registry.compatibility.schema1.enabled: true.

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 11.9 are:


GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. This was noted in gitlab-ce#40970.

In GitLab 11.5, we added this requirement to the Geo documentation in gitlab-ee#8053.

With GitLab 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed Storage is enabled and all projects are migrated. See gitlab-ee#8289. If you are using Geo, please run this check and migrate as soon as possible.

In GitLab 11.8, a permanently dismissable warning is displayed on the Admin Area › Geo › Nodes page if the above checks are not resolved: gitlab-ee!8433.

In GitLab 12.0, Geo will enforce the Hashed Storage requirement. See gitlab-ee#8690.

Planned removal date: Jun. 22, 2019

Hipchat integration

Hipchat is being discontinued. Therefore, we have removed the existing GitLab Hipchat integration feature in 11.9.

Planned removal date: Mar. 22, 2019

CentOS 6 support for GitLab Runner using the Docker executor

GitLab Runner is removing support for CentOS 6 when using the Docker executor in GitLab 11.9. This is a result of an upgrade to the underlying Docker library that no longer supports CentOS 6. Please see this issue for additional details.

Planned removal date: Mar. 22, 2019

Deprecate legacy code paths GitLab Runner

Since Gitlab 11.9, GitLab Runner is using a new method for cloning/fetching the repository. Currently, GitLab Runner will use the old method if the new one is not supported.

In GitLab 11.0 we changed how the metrics server is configured for GitLab Runner. metrics_server will be removed in favor of listen_address in GitLab 12.0. Please see this issue for additional details. Please see this issue for additional details.

In 11.3, GitLab Runner started supporting multiple cache providers, this resulted in new settings for S3 specific configuration. In the documentation there is a table of what changed, and how to migrate to the new configuration. Please see this issue for additional details.

These paths will no longer be available in GitLab 12.0. As a user, you don’t have to change anything apart from making sure the GitLab instance is running 11.9+ when upgrading to GitLab Runner 12.0.

Planned removal date: June 22, 2019

Deprecate entrypoint feature flag for GitLab Runner

In 11.4 GitLab Runner introduced a feature flag FF_K8S_USE_ENTRYPOINT_OVER_COMMAND in order to fix issues like #2338 & #3536.

In GitLab 12.0, we will switch to the correct behavior as if the feature flag was turned off. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Deprecate support of Linux distribution that reached EOL for GitLab Runner

Some Linux distributions in which you could install GitLab Runner have reached End of Life support.

In GitLab 12.0, GitLab Runner will no longer distribute packages to those Linux distributions. A full list of distributions which are no longer supported can be found in our documentation. Thanks Javier Jardón for your contribution!

Planned removal date: Jun. 22, 2019

Remove old GitLab Runner Helper commands

As part of our effort to support a Windows Docker executor, we had to deprecate some old commands that are used for the helper image.

In GitLab 12.0, GitLab Runner will start using the new commands. This only affects users who are overriding the helper image. Please see this issue for additional details.

Planned removal date: Jun. 22, 2019

Developers can delete Git tags in GitLab 11.10

Removing or modifying release notes for Git tags on non-protected branches has historically been restricted to Maintainers and Owners.

Since Developers can add tags as well as modify and remove non-protected branches, Developers should be able to remove Git tags as well. In GitLab 11.10, we’re making this change to our permissions model to improve workflow and help developers make better and more effective use of tags.

If you’d like to continue to restrict this permission to Maintainers and Owners, you can make use of protected tags.

Planned removal date: Apr. 22, 2019

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4, the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is now included. However, the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data using an included tool.

With GitLab 12.0, any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated and will be lost.

Planned removal date: Jun. 22, 2019

TLS v1.1

Beginning with GitLab 12.0, TLS v1.1 will be disabled by default to improve security. This mitigates numerous issues, including Heartbleed, and makes GitLab compliant out of the box with the PCI DSS 3.1 standard.

To disable TLS v1.1 immediately, set nginx['ssl_protocols'] = "TLSv1.2" in gitlab.rb and run gitlab-ctl reconfigure.

Planned removal date: Jun. 22, 2019

OpenShift template for installing GitLab

The official gitlab helm chart is the recommended method for operating GitLab on Kubernetes, including deployment on OpenShift.

The OpenShift template for installing GitLab is deprecated and will no longer be supported in GitLab 12.0.

Planned removal date: Jun. 22, 2019

Previous security job definitions

With the introduction of CI/CD templates for security jobs, any previous job definition is deprecated and can be removed in GitLab 12.0 or later.

Update your job definitions to use the new syntax in order to benefit from all the new security functionality provided by GitLab.

Planned removal date: Jun. 22, 2019

System Info section in the admin panel

GitLab presents information about your GitLab instance at admin/system_info, but this information can be inaccurate.

We’re removing this section of the admin panel in GitLab 12.0 and recommend using other monitoring capabilities.

Planned removal date: Jun. 22, 2019

Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation.


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


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


Check out our update page.


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

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

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Open in Web IDE View source