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

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

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.

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

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.

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.

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 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.

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.

Join us for an upcoming event

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!

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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:

The following improvements have been made to GitLab charts:

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 .

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.

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.

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

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

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.

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.

Thank you, Aaron Walker , for the contribution!

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

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).

Thank you, Glavin Wiechert , for the contribution!

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.

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, 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.

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.

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.

Thank you, Kotau Yauhen , for the contribution!

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

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.

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.

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

Thank you, Hiroyuki Sato , for this contribution!

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.

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.

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.

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

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

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.

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 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.

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.

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

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

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

A complete list of changes can be found in GitLab Runner’s CHANGELOG .

The following are some of the changes in GitLab Runner 11.9:

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

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 .

TypeScript is a relatively new programming language based on JavaScript .

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

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.

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

Thank you, Aaron Walker , for the contribution!

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 .

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, login to JupyterHub instances deployed via Kubernetes integration is limited to members with “Developer” project access (via either group or project).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

Thank you, Robert Schilling , for the contribution!

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.

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.

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.

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

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.

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.

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

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 .

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

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.

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

Deprecations

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.

Deprecation date: Jun. 22, 2019

Hipchat integration

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

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation 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!

Deprecation 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.

Deprecation date: Jun. 22, 2019

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.

Deprecation 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.

Deprecation 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 .

Deprecation 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.

Deprecation 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.

Deprecation 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.

Deprecation date: Jun. 22, 2019