11.6

GitLab 11.6 Release

GitLab 11.6 released with Serverless and Group-level Clusters

GitLab 11.6 released with Serverless and Group-level Kubernetes Clusters for even greater cloud native simplicity.

Deploy serverless workloads to any cloud via GitLab

Serverless computing dynamically allocates cloud resources whenever a piece of code is executed, optimizing allocation and distribution of the resources used to run your code. It is growing in popularity with developers because it allows them to focus on what matters most, namely writing code, without worrying about the underlying information technology infrastructure.

GitLab Serverless uses Knative, a Kubernetes-based platform, to build, deploy, and manage serverless workloads. This feature provides developers with an easy way to build and manage serverless workloads alongside the rest of their code, in a familiar user interface. For businesses, serverless enables a multi-cloud strategy and prevents being locked into a specific cloud provider.

GitLab continues to simplify development of cloud native applications

With a built-in Container Registry and Kubernetes integration, GitLab makes it easier than ever to get started with containers and cloud native development. With 11.6, users will be able to create Kubernetes clusters for groups that can be used by all the projects contained within the group or sub-groups. This further simplifies cloud native configuration and allow developers to focus on developing great applications.

It's the holidays! Get excited! We've stuffed many more features into 11.6!

A few of our favorites include Suggested Changes, Web Terminal for Web IDE, and the Group Security Dashboard Vulnerability Chart. Team contributions are more easily accepted now that changes suggested (when leaving a comment on a merge request diff) can be accepted with a single click. Also, from the Web IDE, you can now launch a Web Terminal, the first server-side evaluation feature of the popular Web IDE. Building upon Group Security Dashboards released last month, the new Vulnerability Chart shows the security team how the number of vulnerabilities is changing day by day to provide resolution metrics.

Read on for all of the holiday goodies delivered with GitLab 11.6!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Suzanne Hillman

Suzanne assisted GitLab in performing our recent Voluntary Product Accessibility Template (VPAT) review by organizing and verifying open accessibility issues, as well as helping to assess the current state of the product through static analysis tools and manual testing with assistive technologies. The VPAT evaluates compliance with accessibility standards and is a great first step towards improving accessibility so that everyone can contribute and use GitLab!

Thank you, Suzanne! We appreciate your contribution that enables more people to use GitLab.

11.6 Key improvements released in GitLab 11.6

Serverless (alpha)

Serverless (alpha)

Building on the Knative integration introduced in GitLab 11.5, our new Serverless capability allows users to easily define functions in their repository and have them served and managed by Knative.

By simply defining your function data in the repo’s serverless.yml file and using a .gitlab-ci.yml template, each function will be deployed to your cluster, with Knative taking care of scaling your function based on request volume. This will allow application developers to iterate quickly without having to worry about provisioning or managing infrastructure.

Serverless (alpha)

Run CI/CD for merge requests

Run CI/CD for merge requests

Running a given job only when dealing with a merge request is now easy. Using the merge_requests value with only/except keywords will allow you to configure jobs to run only (or except) when in the context of a merge request. This allows finer control over pipeline behavior, and also allows access to new environment variables indicating the target branch and merge request ID when relevant, offering opportunities for implementation of other more advanced behaviors.

Run CI/CD for merge requests

Suggested Changes

Suggested Changes

Collaborating on merge requests is now easier – no more copy/pasting to accept a suggested change. Changes can now be suggested when leaving a comment on a merge request diff and accepted with a single click.

Changes can be suggested when commenting on a diff in a merge request, and accepted by any user with write permissions to the source branch.

This feature is available on GitLab.com today, and can be enabled for self-managed GitLab instances using the diff_suggestions feature flag. It will be enabled by default for self-managed instances in GitLab 11.7.

Web Terminal for Web IDE (beta)

Web Terminal for Web IDE (beta)

The Web IDE makes it faster and easier to contribute changes and resolve merge request feedback by eliminating the need to stash changes and switch branches locally. Yet, without a terminal to run tests, experiment in a REPL, or compile your code, making large changes is difficult.

From the Web IDE, you can now launch a Web Terminal so that you can work in an editor side by side with a terminal, just like you would locally, to inspect API responses or check your syntax in a REPL. The Web Terminal is the first server-side evaluation feature of the Web IDE and is configured using a new .gitlab/.gitlab-webide.yml file.

Interactive Web Terminals are not yet available on GitLab.com. You can follow progress here. Changes are not currently synchronized between the editor and the web terminal. In an upcoming release, we will add support for mirroring changes and live preview.

Web Terminal for Web IDE (beta)

Project templates for Groups

Project templates for Groups

Project templates help you bootstrap new projects quickly. In 11.2, we introduced project templates on the instance level.

With GitLab 11.6, we are happy to announce this functionality is now available for groups as well. By creating a sub-group within a new group setting, projects in this sub-group become available as templates. This streamlines the setup and ensures consistency across your projects, especially in larger group structures, such as microservice architectures.

Project templates for Groups

Kubernetes clusters for Groups (beta)

Kubernetes clusters for Groups (beta)

Often, development teams working on related projects need to use the same Kubernetes cluster to deploy their applications. Starting with GitLab 11.6, users are able to create a group-level Kubernetes cluster that can be used for all projects contained within the group or sub-groups.

This will greatly reduce the time/effort required to configure infrastructure for your projects and allow you to focus on developing great applications.

Kubernetes clusters for Groups (beta)

Cert-manager for Kubernetes

Cert-manager for Kubernetes

Securing applications is critical for production-grade deployments. Cert-manager is a Kubernetes-native certificate management controller that will automatically issue and renew SSL certificates using Let’s Encrypt.

Using this SSL certificate will enable HTTPS for applications served via Auto DevOps as well as for JupyterHub deployments.

Cert-manager for Kubernetes

Vulnerability Chart for Group Security Dashboards

Vulnerability Chart for Group Security Dashboards

The Group Security Dashboard is the primary tool where Security professionals can manage vulnerabilities in their projects. One of the most important requirements is to know how the number of vulnerabilities is changing day by day, and understand if the team is solving problems quickly enough.

With GitLab 11.6, the Vulnerability Chart for Group Security Dashboards enables you to easily view the graph of vulnerabilities from the last month. For each severity level, you can read values for vulnerabilities and move over the chart to see more details about a specific point in time.

Vulnerability Chart for Group Security Dashboards

11.6 Other improvements in GitLab 11.6

Authenticate with a smart card hardware token

Authenticate with a smart card hardware token

For organizations operating in environments that use hardware tokens with X.509 certificates and smart card capabilities for authentication (like YubiKeys or Common Access Cards), GitLab now supports local user creation and login.

Users can now use hardware tokens to access GitLab, increasing security and avoiding the need for managing username/password credentials not connected to a physical token.

Discord notifications

Discord notifications

With this release, you can now integrate GitLab with Discord, allowing you to send notifications to a Discord channel in response to GitLab events, such as pushes to a repository, updates to an issue, merge requests, and others.

Thank you Vitaliy Klachkov for the contribution!

Discord notifications

Improved issue and merge request dashboard filtering

Improved issue and merge request dashboard filtering

We’ve updated the search filter bar design for the issues and merge request dashboards, making it consistent with the similar search filter bars in the rest of GitLab.

Improved issue and merge request dashboard filtering

View open or closed epics on roadmap

View open or closed epics on roadmap

We recently introduced the ability to close epics, as a way to indicate that an epic is finished or no longer relevant.

With this release, we’re providing the option to view open epics, closed epics, or both on the roadmap view. This is helpful for teams that want to focus just on remaining and upcoming work (open epics), that want to review finished work (closed epics), or see recently finished work in conjunction with current work (both). This feature provides that flexibility. Additionally, your selection is saved to the system per user, so next time you return to a roadmap view, it will be what you have selected previously.

View open or closed epics on roadmap

SSH push mirroring support with public-key authentication

SSH push mirroring support with public-key authentication

Repository mirroring allows you to replicate Git repositories from one location to another. This makes it easier to work with multiple GitLab instances by mirroring your repository in GitLab to a different server. However, some target servers only allow Git access via SSH using public-key authentication.

GitLab now supports SSH push mirroring with public-key authentication, in addition to password-authenticated SSH and HTTP push mirroring.

Trigger variables are now hidden in UI by default

Trigger variables are now hidden in UI by default

All trigger variables are now hidden by default in the UI and require a manual action to display. This will prevent unintended exposure of values when screen sharing or taking screenshots.

Trigger variables are now hidden in UI by default

Improved project overview

Improved project overview

With GitLab 11.6, we further iterate on the user interface of our project overview page, by introducing a better balance for the project header, improving whitespace and contrast to better highlight more frequently used actions, and improving the overall information structure.

Improved project overview

With this release, we enhance our GitLab breadcrumb navigation structure for milestones and labels. When creating or editing a milestone or label, the breadcrumb context shows an additional ‘New’ or ‘Edit’ item, now consistent with issues and merge requests.

Thank you George Tsiolis for the contribution!

Breadcrumb navigation shows 'New' and 'Edit' for milestones and labels

HTTPS support for JupyterHub

HTTPS support for JupyterHub

JupyterHub notebooks provide a powerful way for data teams to share information. Oftentimes, sensitive data requires increased security.

Using Cert-manager for Kubernetes, JupyterHub will automatically serve Jupyter over HTTPS, providing increased security for your sensitive data.

Unlimited free guests for Gold plans

Unlimited free guests for Gold plans

In 11.0, we introduced unlimited guest users for Ultimate plans.

We’re extending this to Gold plans, so groups using GitLab.com’s highest plan, whether self-managed or cloud SaaS, can benefit from adding guests at no additional cost.

Markdown front matter filtering for TOML and JSON

Markdown front matter filtering for TOML and JSON

Front matter is metadata included at the beginning of a markdown document, often used by static site generators such as Jekyll and Hugo. When GitLab displays markdown files in repositories as rendered HTML, front matter retains its format and is displayed as-is, for clarity.

In addition to YAML front matter delimeters (---), GitLab now also supports TOML delimiters (+++), JSON delimiters (;;;), and arbitrary delimiters, enabling the support of any data format.

Thank you Travis Miller for your contribution!

Geo improvements

Geo improvements

We continually focus on improving our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.6 include:

Omnibus improvements

Omnibus improvements

  • Postgres is now installed in a directory under its major version name, so updates within a major version no longer require a restart of the database.
  • GitLab now supports connecting to Redis over SSL (rediss://).
  • The omnibus-gitlab container image’s sshd config now supports Git Protocol v2 by default.
  • GitLab 11.6 includes Mattermost 5.5, an open source Slack-alternative whose newest release includes several bug fixes and performance improvements.
  • postgres has been updated to 9.6.11, ruby to 2.5.3, docker-distribution with a partial set of 2.7.0 commits.
  • prometheus has been updated 2.5.0, prometheus-storage-migrator to 0.2.0, postgres-exporter to 0.4.7, and pgbouncer-exporter to 0.0.4.

Subscription details for Groups on GitLab.com

Subscription details for Groups on GitLab.com

For paid plans on GitLab.com, we want to make it easy to understand the status of your subscription.

In 11.6, we have improved the Billing section underneath a group’s Settings page to include details on your group’s plan. Now, you can easily find your group’s current and past seat use, as well as the start and end date of your subscription.

Subscription details for Groups on GitLab.com

Promote issue to an epic

Promote issue to an epic

Software development is a creative process involving the whole team, and ideas should be welcome from everyone. Ideas that emerge as issues can now freely flow up into epics with the new issue promotion feature.

You can now promote an issue to an epic simply by using a new quick action. Just type /promote in a comment on the issue and hit Comment. This will close the issue, and copy over the content of the issue into a new epic, in the immediate parent group of the issue’s project. Labels, participants, and even upvotes/downvotes will be copied over to the newly created epic, in addition to the title, description, and comment thread itself.

Promote issue to an epic

Per-user saved sort order in issues, merge requests, and epics

Per-user saved sort order in issues, merge requests, and epics

There are now user-specified sort order selections in issues, merge requests, epics, and even roadmap views. Which type of attribute you choose to sort by, and in which order you choose to sort (ascending or descending), is saved to the system, so that when you return to the same type of object list, it will remain what you have selected previously.

Per-user saved sort order in issues, merge requests, and epics

Similar issues

Similar issues

As projects grow and more issues are created, often the same issues are created again and again.

To help people find answers faster, and save maintainers time, similar issues are now shown when creating a new issue. In particular, they are shown when entering the title in the new issue web form. This will help users see similar issues right away, and allow them to navigate to them, and participate in those existing conversations immediately, allowing for more collaboration in GitLab.

Similar issues

Pipelines can now be deleted by project maintainers using API

Pipelines can now be deleted by project maintainers using API

Deleting a pipeline is now possible using the API, which allows for cases where perhaps secrets have been leaked in a pipeline, many unneeded pipelines have been created, or other issues have occurred where pipelines need to be deleted.

Single email notification for Merge Request Reviews

Single email notification for Merge Request Reviews

Code review is an essential practice of every successful project, but receiving email notifications for each comment can be overwhelming. Reviews now only send a single email notification listing all the feedback to help keep your inbox tidy.

Reviews, added in GitLab 11.4, make code review easier, allowing comments to be drafted, reviewed, and submitted in a single action.

This feature is available on GitLab.com today, and can be enabled for self-managed GitLab instances using the batch_review_notification feature flag. It will be enabled by default for self-managed instances in GitLab 11.7.

User profile popovers

User profile popovers

In this release, we introduce enriched popovers when hovering over a username, starting with issue and merge request pages. While we previously only displayed the full name, you can now view the user’s full name, ID, company, and location information, as well as their status if available.

Besides providing this extended tooltip on further pages, we are working on follow-up enhancements for issue and merge request tooltips that will be available shortly.

User profile popovers

HTTPS Support for Auto DevOps

HTTPS Support for Auto DevOps

Auto DevOps aims to solve the many challenges posed when delivering quality software. GitLab 11.6 furthers its capabilities by adding HTTPS support.

Using Cert-manager for Kubernetes, Auto DevOps will automatically serve applications over HTTPS, providing increased security for your applications.

Show Kubernetes HTTP response code

Show Kubernetes HTTP response code

To aid troubleshooting the installation of GitLab-managed apps in your Kubernetes cluster, our integration will now return the HTTP response code from Kubernetes, so resolving issues will be easier and faster.

Disable impersonation of users by admins

Disable impersonation of users by admins

For some organizations, allowing admin impersonation presents a security risk since the actions of administrators are attributed to the user they are impersonating. In order to address this, we’re adding a configurable option to disable admin impersonations.

Auto DevOps support for Group Security Dashboard

Auto DevOps support for Group Security Dashboard

In GitLab 11.5 we released the Group Security Dashboard where SAST results are displayed.

With 11.6, we update the Auto DevOps template with the latest version of the SAST job definition, and now results are fully compatible with the Group Security Dashboard, so users can enjoy both features at the same time.

Note: The new SAST job definition requires GitLab Runner 11.5 or above, you can read more details in this blog post.

GitLab Runner 11.6

GitLab Runner 11.6

We’re also releasing GitLab Runner 11.6 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:

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

Performance improvements

Performance improvements

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

In GitLab 11.6 we have significantly reduced the memory usage of the ReactiveCaching worker by switching to Nokogiri for XML parsing, and we’ve halved the compressed payload size of the merge request discussions endpoint.

These and other noteworthy performance improvements include:

The chart shows the reduction in memory usage by the ReactiveCaching worker since deploying GitLab 11.6 to GitLab.com.

Performance improvements

Deprecations Deprecations

Ruby 2.5 required

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.

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on Geo secondaries. 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.7, we will add a dismissable warning that will be displayed on the “Admin Area › Geo › Nodes” page.

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

Planned removal date: Mar. 22, 2019.

Support for Prometheus 1.x in Omnibus GitLab

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4 (Oct. 22, 2018) 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: GitLab 12.0

TLS v1.1 will be disabled by default in 12.0

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: GitLab 12.0

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.

Upgrade barometer Upgrade barometer

To upgrade to GitLab 11.6 from the latest 11.5 version, no downtime is required for multi-node/HA deployments. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

Due to the ruby upgrade, a single GitLab node will be down until the unicorn processes have been restarted. The restart is done automatically at the end of gitlab-ctl reconfigure, which is run by default on upgrade.

For this release we have migrations, post-deploy migrations, and to help with the larger migrations, we have introduced background migrations.

GitLab.com migrations took approximately 25 minutes and post-deploy migrations amounted for a total of around 2 minutes. Background migrations on the other hand are sidekiq jobs that will run synchronously. For this release these migrations took around 15 minutes to complete, and no side effects were expected nor present.

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

Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

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

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash

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