Jan 22, 2019 - Victor Wu  

GitLab 11.7 shipped with Releases, Multi-level Child Epics, and NPM Registry

GitLab 11.7 shipped with Releases, Multi-level Child Epics, and NPM Registry!

Managing releases just got a whole lot easier

GitLab 11.7 delivers Releases in GitLab Core. Users now have release snapshots that not only include the source code but all related artifacts. This eliminates the need for manual collection of source code, build output, and other metadata or artifacts associated with a released version of your code. Additionally, Releases sets the stage for broader, more robust release orchestration in the future.

Portfolio Management supports more complex work breakdown structures

Multi-level Child Epics are the newest addition to GitLab portfolio management, available in Ultimate. Child Epics enable multi-level work breakdown structures, helping you manage more complex projects and workplans. You can now have an epic containing both issues and epics. This structure enables a direct connection between planning and actionable issues to implement.

Streamlining JavaScript development with NPM registries

Gitlab 11.7 Premium delivers NPM registries directly in GitLab, providing a standard, more secure way to share and version control NPM packages across projects. Simply share the package name and NPM and GitLab handles the rest, all within a single interface!

And so much more

It is always so hard to pick which features are our top features in our monthly releases, so we are calling out a couple of additional cool features:

  • Remediate vulnerability with patch file: As you know, GitLab security features help you to detect vulnerabilities. With GitLab 11.7, you now have the ability to remediate that vulnerability and suggest a solution for Node.js projects managed with Yarn. While this is our first official remediation-type feature, you can be sure it is only just the beginning!

  • API integration with Kubernetes: If you are into creating a lot of Kubernetes clusters or consider yourself a Kubernetes ninja, we have a Kubernetes API to greatly reduce manual efforts and make your life a whole lot easier!

  • Cross-project pipeline browsing: With the ability to view pipelines across projects, the sky's the limit on what information is readily at your fingertips with this feature!

Read on for the complete list of features for GitLab 11.7!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is MortyChoi

MortyChoi added support for private Go packages in subgroups. Thank you for making a contribution to help further support this popular language inside GitLab!

Key improvements released in GitLab 11.7

Publish releases for your projects

Our new Releases feature adds the ability to create releases in GitLab and view them on a summary page. Releases are a snapshot in time of the source, links, and other metadata or artifacts associated with a released version of your code, and allow for users of your project to easily discover the latest released version of your code.

Publish releases for your projects

Multi-level Child Epics

Epics and issues work great together to provide flexibility in defining longer-term work plans. However, they are still limited to providing only a two-layer structure.

With this release, we are introducing Child Epics. You can now have an epic containing both issues and epics. This allows you to create multi-level work breakdown structures. So you can now represent even longer-term strategic initiatives or organization goals as high-level epics, and then have multiple levels of epics below those to break them down into more tangible deliverables, all the way down to issues.

Multi-level Child Epics

Cross-project pipeline browsing

It is now possible to expand upstream or downstream cross-project pipelines right from the pipeline view, giving you visibility into your end-to-end pipelines, no matter in which project they start or finish.

Cross-project pipeline browsing

Remediate vulnerability with patch file

GitLab can detect different types of vulnerabilities in your apps, and also suggest a possible remediation to fix them.

Starting with GitLab 11.7, you can download a patch file, and apply it to your repo using the git apply command. Then you can push changes back to your repository, and the security dashboard will confirm if the vulnerability is gone! This makes the resolution process very easy and reduces the time needed to deploy a solution. Currently, Dependency Scanning vulnerabilities for the yarn package manager are supported, and you don’t need to change anything to make it work. The patch will be available, every time it is possible, in the vulnerability details window.

Remediate vulnerability with patch file

Configure Kubernetes app secrets as variables for Auto DevOps pipelines

Operators and administrators require that the configuration of secrets takes place outside the application’s repository to reduce risk and exposure of sensitive data. To address this need, GitLab now offers the ability to configure secrets as environment variables that are made available to the Auto DevOps application running in your Kubernetes cluster.

Simply prepend your variable with K8S_SECRET_ and the relevant Auto DevOps CI pipeline will take your application secret variable to populate a Kubernetes secret.

Configure Kubernetes app secrets as variables for Auto DevOps pipelines

NPM registry

JavaScript developers need a secure, standardized way to share and version control NPM packages across projects. An NPM registry offers developers of lower-level services a way to publish their code in such a way.

In GitLab 11.7, we are proud to offer NPM registries built directly into GitLab. This being integrated right into GitLab would mean they can then share a simple package-naming convention to utilize that library in any Node.js project, and NPM and GitLab will do the rest, all from a single interface. This feature is available with GitLab Premium.

Check out a sample project which builds and pushes to the GitLab NPM registry, and see how easy it is!

NPM registry

API support for Kubernetes integration

With this release, we have brought API support to our Kubernetes integration. This means that all the actions currently available in the GUI, such as listing, adding, and deleting a Kubernetes cluster are now accessible via the API. Teams can use this new functionality to fold in cluster creation as part of their workflow.

API support for Kubernetes integration

Other improvements in GitLab 11.7

Search filter box for issue board navigation

Teams often use many issue boards in a given project or board, making the dropdown navigation difficult to use if the list is very long. With this release, we are introducing a search filter. Simply type a few characters in the search filter box to quickly narrow down to the issue board you are interested in, making navigation much easier.

Search filter box for issue board navigation

Support catch-all email mailboxes including Microsoft Exchange and Google Groups for incoming email features

GitLab has some great features that use incoming email, such as reply by email, new issue by email, new merge request by email, and service desk. Previously, you could only take advantage of these features if you used an email server configured to use sub-addressing.

With this release, GitLab now supports both sub-addressing and catch-all email mailboxes, using a new email format, allowing more email servers to be used with GitLab, including Microsoft Exchange and Google Groups (which do not support sub-addressing).

Short commit SHA available as environment variable

Git SHAs are 40-character pointers to specific objects (i.e., commits) in a Git repo. Often, showing the full string is unwieldy and you just want to show the first eight characters as a quick (though not guaranteed unique) reference. We’ve added the CI_COMMIT_SHORT_SHA environment variable to the CI pipeline for this purpose, which will give you the first part of the commit SHA being built.

Short commit SHA available as environment variable

Authorization support for fetching includes

When including external files in your pipeline definition using the include keyword, these are fetched using HTTP/HTTPS requests. You are now able to access yamls on another project with no public access (e.g., a private project on GitLab.com) using the credentials the pipeline is running as.

Show Dependency Scanning results in the Group Security Dashboard

The Group Security Dashboard was initially released with SAST results only, so users were not able to manage other types of vulnerabilities with this feature.

With GitLab 11.7, Dependency Scanning findings have been added to the set of available data. If you are already using the new report syntax, you will automatically see results in the dashboard. The Auto DevOps template has been updated as well, and it now requires GitLab Runner 11.5 or above to run the Dependency Scanning job correctly.

Show Dependency Scanning results in the Group Security Dashboard

RBAC mode default for Kubernetes cluster creation

Securing your Kubernetes cluster is vital in order to control and limit who can access the cluster and what actions they are allowed to perform.

Starting with GitLab 11.7, all clusters will default to RBAC-enabled at time of creation, providing more secure and protected infrastructure.

Support for NGINX Ingress 0.16.0+ metrics

With the release of NGINX Ingress 0.16.0, Prometheus metrics are now built in natively rather than relying on an external exporter.

GitLab 11.7 now includes support for the metrics exported by NGINX Ingress 0.16.0+, and will automatically detect and display the throughput, latency, and error rate of deployments.

GitLab Runner 11.7

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

Most interesting changes:

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

Performance improvements

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

In GitLab 11.7, we have significantly improved the performance of viewing merge requests by caching syntax highlighted discussion diffs.

Other noteworthy performance improvements include:

Project list redesign

Projects are first-class citizens in GitLab, and we want to make project lists visually pleasing and easy to parse.

In GitLab 11.7, we introduced a redesign of the project list UI that focuses on readability and a summary of the project’s activity. We’ve given each project row additional project information and whitespace, and will continue to iterate on the design based on feedback.

Project list redesign

Import issues CSV

Often when teams start using GitLab, they may be using different tools and have legacy data. You may be currently using Jira but would like to move to GitLab issues.

With this release, we are making this transition easier. Since many issue tracking systems allow for a CSV export, you can now import such an export of issues into GitLab, allowing you to continue managing your existing work, importing legacy data into GitLab for future search and retrieval as necessary. This will work with Jira or any issue tracking system that can generate a CSV export.

GitLab also has an existing CSV export feature too.

Import issues CSV

Stricter self-approval restrictions

Code review is an essential practice of every successful project, and should be conducted by someone who isn’t the author of the change. By default, self approval of merge requests is not permitted, but was prevented based on the author of the merge request, not the commits in the merge request.

From GitLab 11.7, self-approval restrictions also prevent people who have committed changes to the merge request from approving, so that merge requests authored by multiple engineers receive fully independent code reviews and approvals.

Filter vulnerabilities in the Group Security Dashboard

The Group Security Dashboard allows security teams to keep everything under control by showing vulnerabilities that affect their groups.

With GitLab 11.7, users can filter displayed vulnerabilities by severity, report type, and project name. With this ability, they can focus on what they need and reach their data faster, especially useful when there are many entries in the list.

Filter vulnerabilities in the Group Security Dashboard

Include CI/CD files from other projects and templates

The include keyword allows users to create CI/CD pipelines dynamically, with external files included into the configuration. This was previously possible only for files in the project repository, or for remote files fetched via HTTP.

With GitLab 11.7, users can include their snippets of configuration also from other projects and from the predefined templates. GitLab will include snippets for specific jobs, like sast or dependency_scanning, so users can reference them instead of copying and pasting the current definition. The jobs will automatically be updated to the latest version when GitLab is updated, so there is no need for manual changes.

Include CI/CD files from other projects and templates

Support for private Go packages in subgroups

Go packages hosted in GitLab can be installed using go get, however this was not supported for private projects in subgroups. Starting with GitLab 11.7, any project can be used as a Go package, including private projects in subgroups.

Private packages are supported by the go get command using a .netrc file, and using a personal access token in the password field.

Thank you MortyChoi for the contribution!

Skip CI builds during git push

For commits where users don’t want to run the CI/CD pipeline, they were able to add a note to the commit message with [ci skip] or [skip ci]. However, many users don’t want to or can’t change their commit messages to contain additional information.

As of GitLab 11.7, users can use Git push options in Git 2.10 or newer when pushing to GitLab to prevent the pipeline run for their push. Using git push -o ci.skip will now achieve the same goal without any changes to the commit message.

Thank you Jonathon Reinhart for the contribution!

Omnibus improvements


Ruby 2.5 required

Beginning with GitLab 11.6, Ruby 2.5 is required to run GitLab. Omnibus GitLab already ships with Ruby 2.5.3, but users of source installations that run Ruby 2.4 will have to upgrade.

Planned removal date: Dec. 22, 2018.

Debian 7 Wheezy support

GitLab 11.6 was the last release with support for Debian 7 Wheezy. Deprecation was originally announced in GitLab 10.6.

Debian Wheezy is no longer supported by the Debian project as of May 2018, we strongly recommend users to upgrade to Stretch or Jessie.

Planned removal date: Dec. 22, 2019

Raspbian Jessie support

GitLab 11.8 will be the last release with support for Raspbian Jessie.

Jessie has transitioned to LTS, and the latest Raspbian Jessie image is over a year old. We recommend that users upgrade to Raspbian Stretch.

Planned removal date: Feb. 22, 2019

CentOS 6 support for GitLab Runner using the Docker executor

GitLab 11.9 will be the last release with Runner support for CentOS 6 when using the Docker executor because we are planning to update to a more current Docker library which no longer supports it. Please see this issue for additional details.

Planned removal date: Mar. 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 will be disabled by default in 12.0

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

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 11.5, we added this requirement to the Geo documentation: gitlab-ee#8053.

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

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

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

Planned removal date: Jun. 22, 2019

Google OAuth2 SSO only supported in GitLab 11.7+

On Mar. 7, 2019, Google is shutting down all Google+ APIs. You can read more about the announcement from Google here.

Since GitLab versions prior to 11.7 rely on these APIs for Google OAuth2, Google single sign-on will no longer function on these versions. GitLab 11.7 and beyond will support Google SSO.

If your instance relies on Google OAuth2 for authentication, we recommend upgrading to 11.7.

Planned removal date: Mar. 7, 2019

Developers can delete Git tags in GitLab 11.9

Editing/deleting Git tags on non-protected branches has been historically restricted to Maintainers and Owners.

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

Planned removal date: Mar. 22, 2019

Hipchat integration

Hipchat will be discontinued. So we are removing the existing GitLab Hipchat integration feature as part of the 11.9 release.

Planned removal date: Mar. 22, 2019

Removals and breaking changes

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

Upgrade barometer

To upgrade to GitLab 11.7 from the latest 11.6 version, no downtime is required. Consult the documentation on upgrades without downtime.

Database migrations in this release may take between 30 and 60 minutes for instances similar to the size of GitLab.com. For smaller instances, the total time should be no more than roughly 15 minutes.

GitLab Geo users, please consult the documentation on upgrading Geo.


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