11.4

GitLab 11.4 Release

GitLab 11.4 released with Merge Request Reviews and Feature Flags

GitLab 11.4 released with Merge Request Reviews, Feature Flags, Git protocol v2, and much more!

We're excited to announce the release of GitLab 11.4 with incredible updates to help teams work together more efficiently. Most teams adopting DevOps are focused on shortening cycle time, so improvements that reduce waste and extra work are welcome contributions toward faster delivery and better business results.

With GitLab 11.4 we're making code reviews more efficient with Merge Request Reviews and a file tree for diffs. We are introducing Feature Flags in alpha. Auto DevOps and CI is more powerful with PostgreSQL migrations and timed incremental rollout. Even Git is faster with support for Git protocol v2.

Code review

Merge Request Reviews will reduce the noise from comments on code and merge requests. Batch Comments lets a reviewer enter multiple comments on the code or merge request and then finalize them in one batch. Now, the people subscribed to the project can more efficiently keep track of changes.

Having the right people review and approve code changes is a key step to delivering high-quality code. Building on Code Owners from the 11.3 release, GitLab can now suggest who should review and approve a specific merge request based on the CODEOWNERS file. This way, you can quickly and efficiently get changes reviewed and approved. This will also be useful when defining separation of duties and roles on a team, where you want to have defined reviewers for certain parts of the code.

The addition of the file tree view to the merge request makes it easier and faster for reviewers to navigate through multiple changed files and then provide their feedback.

Russell Levy, co-founder and CTO of Chorus.ai, explains how the reviews and file-tree view features are helping their team:

We're pretty thorough in code reviews and there are generally 10-20 comments on a medium-sized merge request, plus a few rounds of conversations based on it. Using the review feature reduces the noise and interruptions during the review process.

For larger merge requests, the new file tree and diffs feature makes reviews that much faster, as it makes it easy to jump around the code to understand dependencies.

Feature flags

We are introducing an Alpha version of Feature Flags, a feature toggle system. Teams can now practice Continuous Delivery by deploying new features to production in small batches, mitigating risk before a full rollout.

Auto DevOps and CI/CD

We're also updating the ability for all users to take advantage of having Include files in their .gitlab-ci.yml files, moving it from Starter to Core. This will make it easier for all teams to leverage this best practice and more efficiently manage their CI/CD pipelines.

Extra polish

Together with the wider GitLab community, there are many more wonderful improvements we have included in this release including a new profile layout, faster access to your profile status, highlighted @mentions, new quick actions, and the ability to close epics.

Read on to learn more about all the great features in GitLab 11.4.

Join us for an upcoming event Watch the 11.4 Release Radar webcast

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Luke Picciau

Luke added the ability to download 2FA recovery codes as a file, making them easier to backup. 2FA recovery codes are needed to access your GitLab account if you lose access to your phone or one time password secret.

Thank you, Luke for your contribution!

11.4 Key improvements released in GitLab 11.4

Merge Request Reviews

Merge Request Reviews

Code review in merge requests is a powerful feature in GitLab. Team members have conversations linked to specific lines of code in a diff, and can even resolve them. However, the process can get unwieldy in merge requests with large diffs. Often, a reviewer may need to leave upwards of 10 or more comments in a single sitting. And the 9th or 10th comment may actually render earlier comments unnecessary. The end result is that the merge request author gets a slew of notifications and has to sort them out one by one.

With this release, we are introducing Merge Request Reviews. This will allow a reviewer to draft as many code comments in a merge requests as they wish, make sure they are all consistent, and then submit them all as a single action. Since the drafts are saved to GitLab, a reviewer can even spread their work over many sessions, say starting a review on their desktop at work during the day, and then wrapping it up at home on their tablet device later in the evening. Once the draft comments are submitted, they appear as normal individual comments. This allows individual team members the flexibility to do code review however they want, but still being compatible with the entire team.

In future iterations, we will improve the feature to provide a preview before the batch submit action, and also combine all those notifications that those comments currently generate, into one batched notification.

Merge Request Reviews

Create and toggle feature flags for your applications (alpha)

Create and toggle feature flags for your applications (alpha)

This feature gives you the ability to create and manage feature flags for your software directly in the product. Simply create a new feature flag, validate it using the simple API instructions in your software, and you have the ability to control the behavior of your software in the field via the feature flag within GitLab itself.

Feature Flags offer a feature toggle system for your application. They enable teams to achieve Continuous Delivery by deploying new features to production in smaller batches for controlled testing, separating feature delivery from customer launch. This helps reduce risk, and allows you to easily manage which features to enable.

Note that this is an alpha feature being introduced for the first time, so while we encourage you to check out the feature and provide feedback, we want you to be aware that the implementation could change in subsequent releases.

Create and toggle feature flags for your applications (alpha)

File tree for browsing merge request diff

File tree for browsing merge request diff

Code review is an essential practice of every successful project, but knowing what has changed can be hard to determine from a flat list of diffs. GitLab now includes a searchable file tree of changes to make it easy to see which files have changed and jump between them.

The file tree summarizes the structure and size of the change, similar to diff-stats, providing an overview of the change and improving navigation between diffs. Search allows reviewers to limit their code review to a subset of files by path or filetype, simplifying reviews by specialists focussed on only a subset of the merge request.

Previously the list of changed files was available through a searchable drop down, that was best suited to jumping to a specific file.

File tree for browsing merge request diff

Suggest Code Owners as merge request approvers

Suggest Code Owners as merge request approvers

Knowing who is the best person to review your changes isn’t always obvious. Code owners are now shown as suggested approvers when creating or editing a merge request to make assigning the right person easy.

Support for defining code owners was introduced in GitLab 11.3. In upcoming releases, code owners will be further integrated into the merge request workflow with automatic assignment and required approvals.

Suggest Code Owners as merge request approvers

New user profile page overview

New user profile page overview

No matter how engaged you are on GitLab, your activity is a relevant source of information and engagement indicator, displayed right at your personal profile page. Your personal profile should give a simple insight into what you are interested in and working on.

With this release, we introduce a redesigned profile page overview, showing your activity via the familiar but shortened contribution graph with your latest activities and your most relevant personal GitLab projects.

New user profile page overview

Set and show your status message within the user menu

Set and show your status message within the user menu

With GitLab 11.2 we introduced personal status messages for the first time, allowing you to share your current availability, mood, or simply your favorite animal.

With this release, we make setting your status even more simple and frictionless. A new “Set status” item in your user menu provides a fresh modal that allows you to set and clear your status right within context. In addition, your set status is also shown in your user menu, on top of your full name and user name, including set Emoji and message.

Set and show your status message within the user menu

Move ability to use includes in .gitlab-ci.yml from Starter to Core

Move ability to use includes in .gitlab-ci.yml from Starter to Core

We are very happy to announce in this release that the usage of includes within the .gitlab-ci.yml is now available in Core. This will help ensure templates and other shared resources are always compatible between free and non-free users, and also unlocks the ability for everyone to do best-practice development using reusable snippets in your CI/CD pipelines.

Move ability to use includes in <code>.gitlab-ci.yml</code> from Starter to Core

Run jobs only/except for modifications on a path or file

Run jobs only/except for modifications on a path or file

A popularly requested feature, we’re proud to now offer the ability within the .gitlab-ci.yml to use only/except rules for jobs based on when modifications occur to a specific file or path (glob).

This will allow more control for users whose repositories contain different kinds of assets or builds, ensuring only the appropriate steps are executed for the kinds of changes that were committed, speeding up overall pipeline execution.

Run jobs <code>only</code>/<code>except</code> for modifications on a path or file

Add timed incremental rollouts to Auto DevOps

Add timed incremental rollouts to Auto DevOps

You’ve had the ability within Auto DevOps to setup incremental rollouts for a while now, and with this release, we are adding an option to also set up timed incremental rollouts where the rollout will automatically continue on a timed cadence unless there is some error.

Add timed incremental rollouts to Auto DevOps

Support Kubernetes RBAC for GitLab managed apps

Support Kubernetes RBAC for GitLab managed apps

Security is paramount when setting up your infrastructure for the first time or connecting to existing one. Role-based access control (RBAC) was made generally available as part of Kubernetes’ 1.8 release, providing more granular controls to regulate access to Kubernetes resources.

Our Kubernetes integration will now offer the capability to either create an RBAC-enabled cluster on GKE or to connect with an existing cluster that is RBAC-enabled, providing increased security for your infrastructure.

Support Kubernetes RBAC for GitLab managed apps

Auto DevOps support for RBAC

Auto DevOps support for RBAC

Auto DevOps now supports interacting with and deploying applications to RBAC-enabled Kubernetes clusters.

Role-based access control (RBAC) is an important tool that allows operators to ensure the reliability, security, and efficiency of their Kubernetes cluster. Using Auto DevOps in conjunction with an RBAC-enabled cluster ensures your applications take advantage of the increased infrastructure security.

Auto DevOps support for RBAC

Support PostgreSQL DB migration and initialization for Auto DevOps

Support PostgreSQL DB migration and initialization for Auto DevOps

Using Auto DevOps to automatically detect, build, test, deploy, and monitor your application just got more powerful. Starting in 11.4, Auto DevOps now provides the ability to initialize or migrate PostgreSQL databases in your project.

Simply define a project variable to initialize or migrate your PostgreSQL database, and Auto DevOps will do the rest.

Support PostgreSQL DB migration and initialization for Auto DevOps

11.4 Other improvements in GitLab 11.4

List of subscribed labels

List of subscribed labels

Labels in GitLab are very powerful since they can be applied to issues, merge requests, and epics. As you use more labels, it can be difficult to maintain them.

In a recent previous release, we added the ability to search by labels on the project labels list page. With this release, you can now search by labels, sort by name/created at/updated at, and even see a list of labels you have subscribed to. This is available both in group and project labels list pages.

List of subscribed labels

Highlight @mentions for yourself distinctly

Highlight @mentions for yourself distinctly

When collaborating in a long discussion in an issue or merge request, often many users are involved, making it difficult to quickly at a glance, see comments that are directed at you.

With this release, @mentions for yourself (i.e. the current user), are highlighted in a different color, allowing you to easily see which comments involve you, helping you focus on them quickly.

Highlight <code>@mentions</code> for yourself distinctly

Include new issues created in Burndown Chart

Include new issues created in Burndown Chart

Burndown Charts help teams track work, as it progresses throughout a milestone. Usually, the scope of work is decided and agreed on before the milestone begins. But occasionally, there will be important exceptions to the rule, (such as an emergency bug or security fix) and new scope needs to be included, in the form of new issues.

With this release, burndown charts now accounts for these new issues that are created in the middle of a milestone, resulting in an uptick of its line.

Include new issues created in Burndown Chart

Lock discussion quick action

Lock discussion quick action

Locking discussions in issues and merge requests is helpful to direct conversations to newer issues (or merge requests). It can also be used to control abusive or otherwise unproductive behavior.

With this release, we now have quick actions to lock and unlock discussions, making it easier to type a comment and lock/unlock all one action.

Thank you Mehdi Lahmam for the contribution!

Lock discussion quick action

Improve Admin Area settings structure

Improve Admin Area settings structure

Depending on your responsibilities, administrating GitLab can provide a very complex challenge due to all things GitLab offers.

With this release, we improve the experience of our Admin Area Settings by moving all sections into new, individual Settings sub-pages. This provides admins a time-saving shortcut to access any detail to manage.

Improve Admin Area settings structure

Display code language percentage on project overview

Display code language percentage on project overview

We recently introduced a new code language bar on the Project overview page, providing a quick overview about programming languages involved.

With GitLab 11.4, we introduce an additional absolute measure by showing a new percentage value for each relevant code language shown. This provides a more quantitative view of your project’s technology stack.

Thank you for this contribution, Johann Hubert Sonntagbauer!

Display code language percentage on project overview

Filter admin Runners view by Runner type and state

Filter admin Runners view by Runner type and state

The admin runner view now supports the ability to filter by runner type and state, giving you more options to manage especially large fleets of runners in your environment.

Filter admin Runners view by Runner type and state

Skip Auto DevOps jobs based on feature availability

Skip Auto DevOps jobs based on feature availability

Starting in 11.4 Auto DevOps will now evaluate the plan (GitLab.com) or tier (self-managed) for the instance in which it’s running in order to determine which jobs to skip. This will result in faster Auto DevOps pipeline when certain features are not in use.

This will not only save you time but will also result in a cleaner view of Auto DevOps pipeline, showing you only the relevant jobs for your project.

Interactive runbooks with Nurtch and JupyterHub

Interactive runbooks with Nurtch and JupyterHub

Interactive runbooks provide a powerful way for operators to interact with various systems to carry out common tasks such as diagnosing, deploying, and measuring infrastructure components.

The JupyterHub app offered via GitLab’s Kubernetes integration now ships with Nurtch’s Rubix library, providing a simple way to create DevOps runbooks. A sample runbook is provided, showcasing common operations.

Interactive runbooks with Nurtch and JupyterHub

Alert thresholds now displayed on metrics dashboard

Alert thresholds now displayed on metrics dashboard

With GitLab 11.4, configured alert thresholds are now displayed directly on the metrics charts. This allows easier determination of which metrics are currently generating alerts, and better visualization of the interplay of the metric and alert threshold.

Alert thresholds now displayed on metrics dashboard

Geo UX improvements in Admin Area

Geo UX improvements in Admin Area

As a Geo admin, keeping an overview of your secondary nodes setup and the synchronization state is crucial when working with distributed teams.

With GitLab 11.4, we improve the Geo-related Admin Area settings by improving and showing even more synchronization and verification details in the user interface. On your primary node, a new button “Open projects” adds a new quick link to navigate to the “Projects” list of the corresponding secondary node. On secondary nodes, a new “All” tab gives you a quick overview about the verification state of all projects.

Further UX improvements are in our pipeline!

Geo UX improvements in Admin Area

Filter by WIP merge requests

Filter by WIP merge requests

Merge requests are a core part of GitLab, allowing team members to collaborate on code transparently. In particular, we encourage teams to share their work early, and use the WIP (work in progress) feature to indicate that a merge request is still undergoing active work and should not be merged yet.

With this release, we’re making it easier for users to differentiate between WIP and non-WIP merge requests by having a dedicated filter in both group-level and project-level merge requests lists. This allows users to quickly focus in on merge requests that are still in their early stages of work, versus those that are toward the final stages of review before merge.

Filter by WIP merge requests

GitLab supports GitLab Flavored Markdown (GFM) in most places throughout GitLab where you enter text, providing the power of rich formatting with a simple syntax. In particular, you can create tables in GFM. Previously, this was painful to use, especially for large tables, since you had to type a lot of characters or paste in a previous table just to format it the way you want. Similarly, GFM also supports URL links. But sometimes you may forget the particular syntax.

With this release, you can now click on the table button in the GFM editor, and this will automatically insert a table for you. You can then easily enter table values or extend the table, formatting it just the way you want. You can use this in description and comment boxes all throughout GitLab.

You can now also click on the link button, and this will generate the URL link syntax skeleton for you. Allowing you to quickly paste in a link and write the name of it.

Thank you George Tsiolis for the table contribution!

Thank you Jan Beckmann for the URL link contribution!

Click to insert Markdown table and link

Expanded weight values in issues API

Expanded weight values in issues API

In a previous release, we expanded the allowable values of issue weight from a small number to effectively unlimited, any number greater than zero.

With this release, we’ve brought this flexibility to the issues API as well, allowing users to set this field with the newly expanded number range with the API.

Close epics

Close epics

Similar to issues and merge requests, you can now close (and re-open) epics in GitLab. The epics list now has the Open, Closed, and All tabs, just like issues. So when you have completed all the work in an epic, or it is no longer relevant, you can close it, and it won’t appear anymore in the default list view.

You can close (and re-open) an epic via buttons on the epic, via quick actions in an epic comment, and also via the API, exactly like issues.

Close epics

Explore projects by popularity

Explore projects by popularity

At GitLab, we do our best to enable you to explore relevant and cool projects on your GitLab instance. With this release, a new filter “Most stars” provides an incredible useful filter to show projects most starred on your instance.

Thank you for this contribution, Jacopo Beschi!

Explore projects by popularity

Download two-factor recovery codes

Download two-factor recovery codes

Two-factor authentication is a de facto standard for signing up for any relevant web-based application. At GitLab we understand and take this seriously. Whenever you set up a two-factor authentication initially, we provide limited recovery codes that allow you to regain access to your account as a fallback.

With this release, we now support download of recovery codes as a text file using the new “Download codes” button.

Thank you for this contribution, Luke Picciau!

Download two-factor recovery codes

Add support for interactive web terminal to Docker executor

Add support for interactive web terminal to Docker executor

The interactive web terminals feature has been expanded to be compatible with Docker executors as well. For now, the Docker session is closed as soon as the script exits, but we are aiming to further improve this behavior by resolving #3605 in our next release.

Add support for interactive web terminal to Docker executor

Allow pipelines to schedule delayed jobs

Allow pipelines to schedule delayed jobs

It is now possible to set a job to start after a delay via the when keyword in .gitlab-ci.yml. The timer starts ticking when the job would have otherwise started, giving you control to implement tasks that need to wait for a period of time to occur - for example, when implementing timed incremental rollouts, or any other delays needed after performing some other action.

Allow pipelines to schedule delayed jobs

Add manual entries for License Management

Add manual entries for License Management

License Management policy allows developers to define if they want to approve or blacklist a specific license for their project. This can be done as soon as a new license is introduced, directly in the merge request page. But sometimes project maintainers want to populate the list beforehand, so that developers already know if their changes are aligned with the policy.

In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project maintainers can prefill the policy in the Settings > CI/CD > License Management page by choosing from a set of common licenses, or add a custom entry to that list.

Add manual entries for License Management

Git protocol v2

Git protocol v2

Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.

Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and 10s of megabytes of data.

Git protocol v2 is supported from Git v2.18.0 and is opt-in. To enable globally run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled on GitLab.com and must be enabled manually for self-managed installations.

Prometheus 2.0 upgrade for Omnibus GitLab

Prometheus 2.0 upgrade for Omnibus GitLab

Omnibus GitLab comes out of the box with Prometheus, allowing easy observability of deployed instances. The Prometheus team has released a major new version, the 2.x series, which offers a number of improvements. These include improved performance and a more efficient time-series database format. Unfortunately because of the architectural changes to the database, it is not backwards compatible with the old 1.x format.

With GitLab 11.4, Prometheus 2.4.2 is now available in the Omnibus package so users can take advantage of its benefits.

  • New installations of 11.4 and above will start with Prometheus 2.
  • Existing installations will not be automatically upgraded. We have added a new command, gitlab-ctl prometheus-upgrade, which can be utilized to upgrade Prometheus and optionally migrate data. Prometheus will be stopped during data migration.
  • GitLab 12.0 will automatically upgrade to Prometheus 2.0. With the automatic upgrade, Prometheus 1.0 data will not be migrated.

For more information on upgrading Prometheus to 2.4.2, please review our update documentation.

Geo improvements for SSH Git commands proxy to primary node

Geo improvements for SSH Git commands proxy to primary node

Making Geo as easy to use as possible is one of our constant goals to support widely distributed teams using GitLab. In 11.3 we added initial support for proxying SSH git push from secondary nodes to primary nodes.

With this release, we further improve the performance and usability of this feature, allowing to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.

Geo improvements for SSH Git commands proxy to primary node

Omnibus improvements

Omnibus improvements

  • redis has been updated to 3.2.12, which is a critical security update that fixes multiple vulnerabilities. After upgrading to 11.4, run sudo gitlab-ctl restart redis to ensure the new version is running.
  • GitLab 11.4 includes Mattermost 5.3, an open source Slack-alternative whose newest release includes enhanced search on desktop and mobile, plus much more. It includes security updates and upgrading is recommended.
  • git has been updated to 2.18.1, and libpng to 1.6.35.
  • gnupg has been updated to 2.2.10, gpgme to 1.10.0, libgcrypt to 1.8.3, npth to 1.6, libgpg-error to 1.32, and libassuan to 2.5.1.
  • Certificates in the trusted_certs directory are now set to 0644 permissions instead of 0755.

Deprecations Deprecations

Support for Docker versions in GitLab Runner

Support for Docker versions in GitLab Runner

With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) have been be deprecated in line with Docker’s latest version recommendation guidance. Beyond the 11.4 release these older versions are no longer be officially supported and could stop working at any time.

Planned removal date: October 22, 2018

Support for Prometheus 1.x in Omnibus GitLab

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4 (October 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

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.4 from the latest 11.3 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

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 34 minutes and post-deploy migrations amounted for a total of around two minutes.

This release includes a critical security update for redis. We strongly recommend running sudo gitlab-ctl restart redis to ensure the new version is running.

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

To ease setup, Omniauth is now enabled by default. As no external providers are automatically configured, this shouldn’t affect most installations. However, if you have previously configured an external provider without enabling omniauth, it will be activated when upgrading to 11.4. To prevent this from happening, you can either remove the provider from your configuration, or explicitly disable Omniauth.

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