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.

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.

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.

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.

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!

Join us for an upcoming event

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!

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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.

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 .

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.

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.

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.

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.

We continue to improve the performance of GitLab with every release for GitLab instances of every size. Some of the improvements in GitLab 11.11 are:

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Deprecations

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. This was noted in gitlab-ce#40970.

In GitLab 11.5, we added this requirement to the Geo documentation in gitlab-ee#8053.

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

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

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

Deprecation date: Jun. 22, 2019

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.

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

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

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

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

Deprecation date: Jun. 22, 2019

Deprecate support of Linux distribution that reached EOL for GitLab Runner

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

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

Deprecation date: Jun. 22, 2019

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

Deprecation 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

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

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

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

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

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

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

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

Deprecation date: Jun. 22, 2019