May 22, 2019 - Jason Lenny    
11.11

GitLab 11.11 released with Multi-Assignment for MRs and container enhancements

GitLab 11.11 released with Multi-Assignment for Merge Requests, Windows Container Executor, Dependency Proxy, and much more!

Increased collaboration and visibility

One of the areas we focus on at GitLab is to find new ways to increase collaboration throughout the entire DevOps lifecycle. In this release, we're happy to announce that we now support Multiple Assignees for a Merge Request! This is available in GitLab Starter and truly embodies our everyone can contribute motto. We know that many people may be working/collaborating in the same merge request to make sure things are on track, and Multiple Assignees for Merge Requests provides an environment to do just that!

Additionally, we have heightened the visibility for DevOps teams by supporting automated deployment event notifications for Slack and Mattermost. Adding to the list of push events for these two collaborative environments allows a notification to kick off near real-time to update your team every time a deployment occurs.

Reduce overhead with Windows support of Docker containers and provisioning instance-level Kubernetes clusters

We đź’– containers! Containers require fewer system resources than your traditional or virtual machine environments while increasing the portability of your application. With GitLab 11.11, we now support a Windows Container Executor for GitLab Runners, something that will enable the use of Docker containers on Windows, allowing for more advanced pipeline orchestration and management.

GitLab Premium (self-managed instances only) now has a Caching Dependency Proxy for your Docker images. This MVC iteration helps to speed up time to delivery by providing a caching proxy for frequently used Docker images.

Users of self-managed GitLab instances are now able to provision an Instance Level Kubernetes Cluster, enabling all groups and projects in the instance to make use of it for their deployments. This GitLab Kubernetes integration will automatically create project-specific resources for added security.

And much more!

In addition to increased collaboration and visibility capabilities, we've also added Guest Access to Releases, extended the Add-on CI Runner minutes to GitLab Free, simplified reviews by auto-resolving a discussion whenever a suggestion is applied, and much more!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Kia Mei Somabes

In this release, we added the ability to download folders from repositories instead of the entire repository contents. This makes it a lot easier to get what you need if you’re just looking to grab a few files. Thanks Kia Mei Somabes for the great contribution!

Key features released in GitLab 11.11

Windows Container Executor for GitLab Runner

In GitLab 11.11 we are pleased to add a new executor to the GitLab Runner for using Docker containers on Windows. Previously, using the shell executor to orchestrate Docker commands was the primary approach for Windows, but with this update you are now able to use Docker containers on Windows directly, in much the same way as if they were on Linux hosts. This opens up the door for more advanced kinds of pipeline orchestration and management for our users of Microsoft platforms.

Included with this update is improved support for PowerShell throughout GitLab CI/CD, as well as new helper images for various versions of Windows containers. Please note that your own Windows runners can be used with GitLab.com, but are not currently available as part of the shared public fleet.

Windows Container Executor for GitLab Runner

Caching Dependency Proxy for Container Registry

Lots of teams are using containers as part of their build pipelines, and having a caching proxy for frequently used upstream images/packages is a good way to speed up your pipelines. By keeping a copy of needed layers locally using the new caching proxy, you can improve execution performance for commonly used images in your environment.

For this initial iteration, the container proxy is only available for self-managed instances using the Puma (experimental) web server.

Caching Dependency Proxy for Container Registry

Multiple Assignees for Merge Requests

It is not uncommon for multiple people to collaborate on a feature in a shared branch and merge request, such as the close collaboration of frontend and backend engineers, or in teams where engineers always work in pairs like in Extreme Programming.

In GitLab 11.11, merge requests allow multiple assignees so that all people who are responsible for the change can be assigned to merge request. As with multiple assignees for issues, lists, filtering and notifications, and the API, all support multiple assignees for merge requests.

Multiple Assignees for Merge Requests

Instance-level Kubernetes cluster configuration

As the Kubernetes security and provisioning model evolves, it is now possible to serve a large number of tenants via a single shared cluster.

With GitLab 11.11, self-managed users are now able to provision a cluster at the instance level, enabling all groups and projects in the instance to make use of it for its deployments. The GitLab Kubernetes integration will automatically create project-specific resources for added security.

Instance-level Kubernetes cluster configuration

Deployment notifications for Slack and Mattermost

Deployment events can now be automatically shared in your team’s channel through our Slack and Mattermost chat integrations, helping bring visibility to these important activities that your teams need to be aware of.

Deployment notifications for Slack and Mattermost

Guest access to Releases

It is now possible for guest users of your projects to view releases that you have published on the Releases page. They will be able to download your published artifacts, but are not allowed to download the source code nor see repository information such as tags and commits.

Guest access to Releases

Other improvements in GitLab 11.11

Serialized commit graphs to improve performance

Many common Git operations require walking the commit graph, like computing merge bases, or listing the branches that contain a commit. These operations become slower as the number of commits grows because those walks require each object to be loaded from disk to read its pointers.

In GitLab 11.11, we have enabled the serialized commit-graph feature, which was introduced in recent Git releases, to compute and store this information in advance – significantly improving the speed of these traversals for large repositories. The commit graph will automatically be generated next time garbage collection is run on your repository.

You can learn more about how the serialized commit-graph was built in a series of blog posts written by the feature’s contributor.

Add-on CI Runner minutes have been extended to Free plans

Last month we added the ability to purchase add-on CI Runner minutes, but only to paid plans on GitLab.com. In this iteration, we have extended this feature to Free plans on GitLab.com as well.

Applying a suggestion now automatically resolves the discussion

Suggested changes make it easier to collaborate on merge requests – no more copy/pasting to accept a suggested change. In GitLab 11.11, we are making it even easier by automatically marking the discussion as resolved when the suggestion is applied.

When viewing an issue, it can be helpful to see other related issues, epics, and merge requests in order to gain as much contextual knowledge as possible. In GitLab 11.11, we are introducing more elements into the related merge request table, including status, path, ID, title, pipeline status, and assignees.

More details for related merge requests

Access deployment details through Environments API

We have added the ability to request information on a specific environment to the Environments API, making it easier now to ask, “Which commit is deployed to my environment right now?” This will make automation and reporting easier for users of GitLab’s environments feature.

Run all manual jobs for a stage in one click

With GitLab 11.11, users who rely on stages with many manual jobs can now easily run all of the manual jobs in a given stage by using the Play all button located to the right of the stage name in the pipeline views.

API endpoint for vulnerability information

You can now query the GitLab API to return all of the vulnerabilities identified within a project. With this API, you can generate machine-readable lists of vulnerabilities filtered by type, confidence, and severity.

Install Prometheus on Group-level clusters

In this release, GitLab provided the ability to attach a Kubernetes cluster to an entire group. We’ve also added the ability to install a single Prometheus instance to that cluster, making monitoring of all the projects within that cluster easier.

Create custom metric charts from the dashboard view

Create new charts for custom performance metrics directly from the toolbar of your metrics dashboard. Users can now create, update, and delete metric visualizations within the dashboard view by clicking on the Add Metric button in the upper right-hand corner of the dashboard toolbar.

Create custom metric charts from the dashboard view

Auto-save epic descriptions to local storage

Epic descriptions have not been saved to local storage, often leading to changes being lost if they aren’t actively saved while editing an epic issue description. In GitLab 11.11, we are now saving epic descriptions to local storage. This means you can easily pick back up the work of editing an epic description in the event of an error, distraction, or accidental browser exit.

Repository read-write scope for personal access tokens

Many personal access tokens rely on api level scoping for programmatic changes, but full API access may be too permissive for some users or organizations.

Thanks to a community contribution, personal access tokens can now be scoped to only read and write to project repositories – preventing deeper API access to sensitive areas of GitLab like settings and membership.

Thanks to Horatiu Eugen Vlad for the contribution!

Sign in with Salesforce user credentials

GitLab loves Salesforce developers, and an important step in supporting this community is allowing users to log into GitLab with their credentials from Salesforce.com. Now, instances can configure GitLab as a Salesforce-connected app and use Salesforce.com to sign into GitLab with a single click.

Recently created or modified filters for epics API

Querying recently created or modified data has been difficult using the GitLab epics API. In 11.11, we are adding additional filters created_after, created_before, updated_after, and updated_before to ensure consistency with the issues API and easily find epics that were modified or created recently.

OpenID Connect authentication support

OpenID Connect is an identity layer built on OAuth 2.0, designed specifically for authentication. Thanks to a community contribution, GitLab now supports sign-in with an OpenID Connect provider.

Thank you, Horatiu Eugen Vlad, for the contribution!

Download archives of directories within a repository

Depending on the type of project and its size, downloading an archive of the entire project may be slow or unhelpful – particularly in the case of large monorepos. In GitLab 11.11, you can now download an archive of the contents of the current directory, including subdirectories, so that you download only the files you need.

Thank you, Kia Mei Somabes, for the contribution!

Download archives of directories within a repository

View time tracking in sidebar of board view

Issue sidebars should be consistent in both board and issue views. GitLab is moving towards this consistency by introducing time tracking into the issue sidebar view while on an issue board. Simply navigate to an issue board, click on an issue to pull up the sidebar, and easily view time tracking information.

View time tracking in sidebar of board view

Negative variable matching for pipeline rules

You are now able to test for negative equality or pattern matches (!= and !~) in your .gitlab-ci.yml when checking the values of environment variables, giving more flexibility to control the behavior of your pipelines.

Create a file directly from an environment variable

One common use of environment variables is to create a file, particularly for secrets that should be protected and only available on a certain environment’s pipeline. You would do this by setting the variable content to the file content, then create a file in your job that contains the value. Using our new file type environment variable, you can do this in one step without having to modify your .gitlab-ci.yml.

Full dynamic scans are now an option for DAST

With GitLab you can perform Dynamic Application Security Tests (DAST) as part of your CI pipeline. Starting in this release, you can now specify to use a full dynamic scan instead of the standard passive one. Using the full dynamic scan provides protection against a greater number of vulnerabilities.

Dismissal details on security dashboard

In GitLab Security Dashboards, security administrators can review dismissed vulnerabilities. In order to make their workflow more streamlined, we’ve added the ability to see the details of any dismissal directly in the Security Dashboard.

Issues from alerts now opened as GitLab Alert Bot user

Issues that are opened from alerts will now be authored by the GitLab Alert Bot, providing clear indication that the incident was created automatically from an important alert.

Pull mirroring support for Git LFS

Repository pull mirroring allows you to replicate Git repositories from one location to another. This makes it easy to keep a replica of a repository hosted elsewhere on your GitLab server. GitLab now supports pull mirroring repositories which use Git LFS, so that you can mirror repositories with large files, like textures for game development or scientific data sets.

Add basic support for group GraphQL queries

GraphQL APIs allows users to request exactly the data they need, making it possible to get all required data in a limited number of requests. In this release, GitLab is now supporting basic group information support in the GraphQL API.

SAML SSO now enforced on web access

We’re building on the SSO enforcement on the group level introduced in 11.8 with a persistent check on group and project resources, only allowing access if the user has signed in with SAML. This provides an extra layer of access control for security-conscious organizations on GitLab.com using SAML SSO; now, you can enforce SSO with the knowledge that the users of your group are using SSO.

Sign in with UltraAuth biometric authentication

UltraAuth is a company specializing in passwordless, biometric authentication. We’re excited to support their authentication strategy in GitLab!

Thanks to Kartikey Tanna for the contribution!

Chart improvements

The following improvements have been made to Helm Charts in GitLab 11.11:

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.

Removal date: Jun. 22, 2019

GitLab Geo will enforce using PG FDW in GitLab 12.0

This is needed for Geo Log Cursor as this significantly improves the performance of some synchronization operations. It also improves the performance of the Geo node status queries. For large projects, the legacy queries had unacceptable performance. See how to set it up in Geo database replication In GitLab 12.0, Geo will enforce the PG FDW. See gitlab-ee#11006.

Removal date: Jun. 22, 2019

Sentry settings for error reporting and logging will be removed from the UI in GitLab 12.0

These settings will be removed from the UI in GitLab 12.0 and made available within gitlab.yml. In addition, you will be able to define a Sentry Environment to differentiate between multiple deployments. For example, development, staging, and production. See gitlab-ce#49771.

Removal date: Jun. 22, 2019

Limit maximum number of pipelines created by a single push

Previously, GitLab would create pipelines for the HEAD of every branch included in a push. That makes sense for developers that may be pushing more than one change at a time (say to a feature branch, and the develop branch).

However, when pushing a large repository with many active branches – perhaps to move, mirror, or fork it from another location – it does not make sense to create a pipeline for every branch. Starting in GitLab 11.10, we will create a maximum of 4 pipelines during a push operation.

Removal date: May 22, 2019

Deprecate legacy code paths in GitLab Runner

Since GitLab 11.9, GitLab Runner has been using a new method for cloning/fetching the repository. Currently, GitLab Runner will use the old method if the new one is not supported. Please see this issue for additional details.

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.

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.

Removal date: Jun. 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 and #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.

Removal date: Jun. 22, 2019

Deprecate support of Linux distribution that reached EOL for GitLab Runner

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

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

Removal date: Jun. 22, 2019

Remove legacy GitLab Runner Helper commands

As part of adding support for 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.

Removal date: Jun. 22, 2019

Remove legacy git clean mechanism from GitLab Runner

With GitLab Runner 11.10 we introduced a way to configure how git clean command is being executed by Runner. Additionally, the new cleanup strategy removes the usage of git reset and moves the git clean command after the checkout step.

Since this is a behavior change that may affect some users, we’ve prepared a FF_USE_LEGACY_GIT_CLEAN_STRATEGY feature flag. When set to true it will restore the legacy cleanup strategy. More about how to use feature flags in GitLab Runner can be found in the documentation

In GitLab Runner 12.0, GitLab Runner will drop support for the legacy cleanup strategy and remove the ability to restore it with a feature flag. Please see this issue

Removal date: Jun. 22, 2019

Group project templates fixed to Silver/Premium

When we introduced group-level project templates in 11.6, we unintentionally made this Premium/Silver feature available at any tier.

We’re fixing this bug in 11.11 by giving any existing users/instances lower than Silver/Premium a grace period of three months.

On Aug. 22nd, 2019, this grace period will expire and group project templates will require Silver/Premium or higher as documented.

Removal date: Aug. 22, 2019

Support for Windows batch is now deprecated

We are deprecating support for Windows batch command line jobs in the GitLab Runner (e.g. cmd.exe) in favor of extended and expanding support for Windows PowerShell. We plan to remove Windows batch in GitLab 13.0 (Jun 22, 2020). For more information, see this issue.

This will align our vision for enterprise DevOps with Microsoft’s position that PowerShell is the right technology to automate enterprise applications in Windows-based environments - in July Microsoft will be ending support for the last version of windows that doesn’t support the latest version of PowerShell. For users that may still want to run items using cmd.exe, those commands can be still invoked from PowerShell, but we will not provide direct support for Windows batch.

Removal date: Jun. 22, 2020

Git 2.21.0 or greater required

Beginning with GitLab 11.11, Git 2.21.0 is required to run GitLab. Omnibus GitLab already ships with Git 2.21.0, but users of source installations that run older versions of Git will have to upgrade.

Removal date: May 22, 2019

Remove Kubernetes service template

In GitLab 12.0, we plan to remove the instance-level Kubernetes service template in favor of the instance-level cluster functionality introduced in GitLab 11.11.

Any self-managed instance making use of the service template will be migrated to an instance-level cluster as part of upgrading to GitLab 12.0.

Removal date: Jun. 22, 2019

Remove use of 'app' as matching mechanism for Kubernetes deploy boards

In GitLab 12.0, we plan to remove app label matching for the Kubernetes deployment selector. As part of GitLab 11.10, we introduced a new matching mechanism which uses app.gitlab.com/app and app.gitlab.com/env to show deployments on deploy boards.

In order to see these deployments in your deploy boards all you need to do is push a new deployment and GitLab will use the new labels for your deployments.

Removal date: Jun. 22, 2019

GitLab 12.0 packages will be signed with an extended signature

On May 2, 2019, GitLab extended the expiration date of the package signing keys for Omnibus GitLab packages from 2019-08-01 to 2020-07-01. For those verifying the package signatures, refreshing the keys is as simple as following our documentation for Omnibus Package Signatures a second time.

Removal date: Jun. 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.

Removal date: Jun. 22, 2019

Changelog

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

Installing

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

Updating

Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Cover image licensed under Free

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 for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg