GitLab.org/GitLab: Release v10.1.0-ee

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

![21 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=21&style=for-the-badge "New features added in this release") ![166 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=166&style=for-the-badge "Total features") #### [Premium](https://about.gitlab.com/pricing/premium/) ![4 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=4&style=flat-square "New features added to this tier in this release") ![30 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=30&style=flat-square "Total features in this tier")

[LDAP Group Sync Filters](https://docs.gitlab.com/ee/administration/auth/ldap/index.html#group-sync) (self-managed only)

> As part of our growing Enterprise authentication capabilities, GitLab 10.1 > supports the ability to synchronize LDAP groups to GitLab based on filters, > including _user attributes_. > > For larger and more complex LDAP implementations there may be additional metadata > in LDAP to infer permissions, roles, or types of users. By leveraging group filters, GitLab makes it easier > to perform more user management capabilities directly from LDAP. > > GitLab EES already allows basic synchronization of LDAP groups to GitLab groups. This is great functionality for basic > LDAP integration, but means that your LDAP structure needs to effectively mirror GitLab's group structure. > > The introduction of LDAP Group Sync Filters in GitLab EEP means that your existing LDAP structures > and attributes can be utilized in a more powerful way to manage your GitLab permissions.

[Reject Unsigned Commits](https://docs.gitlab.com/ee/push_rules/push_rules.html#enabling-push-rules)

> Controlling and verifying identities are a key component to GitLab's Enterprise > authentication features. GitLab 10.1 introduces two new mechanisms to enforce > user identity management whilst committing code. > > Authors may be verified through [GPG](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html) integration [introduced in GitLab 9.5](/releases/2017/08/22/gitlab-9-5-released/). > With GitLab Enterprise Edition Premium it is now possible to enforce verification and reject > any commits that are unsigned using push rules.

[Improved Admin Audit Log](https://docs.gitlab.com/ee/administration/audit_events.html#audit-log-admin-only) (self-managed only)

> Knowing what happens inside your GitLab instance is an important aspect of many auditing > requirements. > > GitLab EES (Enterprise Edition Starter) has basic Audit Event capability where each group or repository has > a simple log of events that have taken place. > > The Admin Audit Log was [introduced in GitLab 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#centralized-audit-log), > allowing administrators to access a centralized log of events from > Groups, Projects, and user actions. New user actions have been added to > the central audit log in GitLab 10.1: > > - Add or remove email addresses > - Password change and forgotten password > - Login failure > - Adding SSH keys and granting oAuth access

[GitLab Geo Improvements](https://docs.gitlab.com/ee/administration/geo/) (self-managed only)

> Notable changes shipped with GitLab 10.1: > > - Improved repository sync performance supports larger GitLab instances ([#3453](https://gitlab.com/gitlab-org/gitlab-ee/issues/3453)) > - Improved handling of repository sync failures to prevent the queue > from becoming clogged with permanently failing tasks ([#3259](https://gitlab.com/gitlab-org/gitlab-ee/issues/3259)) > - Added migration path to hash-based storage format introduced in GitLab 10.0 ([#3118](https://gitlab.com/gitlab-org/gitlab-ee/issues/3118)) > - Attachments on personal snippets are now synced ([#3644](https://gitlab.com/gitlab-org/gitlab-ee/issues/3644)) > - After upgrading to 10.1, [attachments will be re-synced](https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html) due to a bug > > See the [full list of changes](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Geo&milestone_title=10.1).

#### Core ![17 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=17&style=flat-square "New features added to this tier in this release") ![136 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=136&style=flat-square "Total features in this tier")

[Image Discussions](https://docs.gitlab.com/ee/user/discussions/#image-discussions)

> Everyone can contribute to GitLab, and with this release, we are helping > interaction designers, visual designers, digital designers, graphic artists, > frontend developers, or just anyone who works with images collaborate better. > > With discussions, you can now click a specific location > of an image (within a commit or a merge request), and start a discussion with > respect to that place in the image. You can even have multiple discussions > specifying different areas of an image. > > Resolvability in the merge request > diff view works the same as before, so once a discussion is settled, simply > resolve it! > > ![Image discussions](/images/10_1/image_discussions.png){:.shadow}

[Lock Discussions](https://docs.gitlab.com/ee/user/discussions/#lock-discussions)

> In this release, we are introducing a moderation feature to lock down > continued discussion in an issue or merge request. This is useful when > there is abuse or spam or you simply want to direct users to a different > place in GitLab (another issue, for example) for continued feedback and > collaboration. A project member with master access (or higher) has > permissions to lock and unlock them. When an issue or merge request is locked, > only project members can create new comments or edit existing ones.

[Merge Requests Across Forks](https://docs.gitlab.com/ee/user/project/merge_requests/)

> Forks and merge requests are a great alternative to branch-based workflows as they > enable any developer to create an alternative copy of the repository rather than committing > changes directly against the primary codebase. > > However, this means that it can make it harder for multiple people to work on the same > code at the same time as the forks are isolated. > > With GitLab 10.1, you can now create merge requests between forks of a canonical repository. > > This makes working together on forks now much simpler, allowing multiple developers to easily review and merge > across forks, bringing the code together before sending a merge request back to the canonical > repository.

[Easily Create Kubernetes Clusters on GKE (Beta)](https://docs.gitlab.com/ee/user/project/clusters/index.html)

> Every application needs a home and in case of web apps or microservices, it can be a > [Kubernetes cluster](https://kubernetes.io/) that can also deploy > [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) during the development cycle. > But setting up a cluster properly is not an easy task, and developers should focus on > writing the code, rather than setting up the infrastructure. > > That's why, in GitLab 10.1, we add the ability to connect your Google Account to your projects and to > create a brand new Kubernetes cluster on [Google Container Engine (GKE)](https://cloud.google.com/container-engine/) > just by enabling the services for your account and specifying a few parameters. > The cluster is immediately ready to use and can be leveraged, among others, by > [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) to have your apps live.

[Online View of HTML Artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-job-artifacts)

> As many projects rely on GitLab for automated testing, developers also need to access the test results > in order to fully benefit of the feedback. This is just an example of how important it is to render HTML reports > and make them accessible in an easy way. > > With GitLab 10.1, we introduce the online visualization of HTML files created by pipelines for public projects, > just one click away from the artifacts browser view. > Your test reports, code quality and coverage information are now very simple > to access directly from your browser, with no need to download them locally.

[Signing Commits with GPG Subkeys](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html)

> GPG integration was [introduced in GitLab 9.5](https://about.gitlab.com/releases/2017/08/22/gitlab-9-5-released/#gpg-commit-verification). > allowing you to sign commits to verify your identity. Many people use verified subkeys to sign > commits, and this is now supported and displayed as verified in GitLab 10.1.

[Improved New Project Page](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-project)

> Creating a [project](https://docs.gitlab.com/ee/user/project/#project-39-s-features) > is the first step when getting started with GitLab, > and we've improved the _New Project_ page to make this simpler. Now it's > easier to take advantage of Project Templates ([introduced in GitLab 9.5](https://about.gitlab.com/releases/2017/08/22/gitlab-9-5-released/#project-templates)) to create > a project with a working example code and pre-configured CI, > create a blank project, or import an existing project from elsewhere.

[Manage Milestones with Developer Permissions](https://docs.gitlab.com/ee/user/permissions.html)

> The developer role can now create, edit, and delete both project milestones > and group milestones. Managing milestones is a software delivery team activity, > so we wanted to extend that flexibility and responsibility to the users with Developer > access in GitLab.

[Improved Internationalization](https://docs.gitlab.com/ee/development/i18n/index.html)

> As part of our ongoing effort to internationalize GitLab, we have now externalised > strings in the Branches, Group and Wiki pages allowing our translation community to add > more languages and strings to GitLab. > > If you are interested in contributing to GitLab's Internationalization efforts, we welcome > you to join our [translation community](https://docs.gitlab.com/ee/development/i18n/index.html).

[Semi-linear History and Fast-forward Merge Requests in CE](https://docs.gitlab.com/ee/user/project/merge_requests/)

> While engaging with the GitLab community, lots of folks have told us that even > in small teams, they want flexibility when choosing a merge method. With > this release, we are taking > [semi-linear history](https://docs.gitlab.com/ee/user/project/merge_requests/#semi-linear-history-merge-requests) > and [fast-forward merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/#fast-forward-merge-requests) > from GitLab Enterprise Editions into GitLab Community Edition (CE), > so that all users can enjoy them.

[Name of GitLab Users in Slack Notifications](https://docs.gitlab.com/ee/user/project/integrations/slack.html)

> Prior to GitLab 10.1, Slack notifications included only the GitLab username. > In this release, the full name is displayed as well. The new format is > `First Last (username)`.

[New keyword for Automatically Closing Issues](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)

> You can now use a new keyword, `implements` (and its variants), in a commit message > or merge request description to signal automatically closing an issue. This joins the existing > keywords such as `closes`, `fixes`, and `resolves` (and their variants).

[Secondary Email Confirmation](https://docs.gitlab.com/ee/security/user_email_confirmation.html)

> For improved security, GitLab is able to enforce email confirmation on sign up. > > This functionality is now extended to additional emails that are added to the user > account, ensuring that all email addresses added to user profiles are confirmed.

[Omnibus Improvements](https://docs.gitlab.com/omnibus/) (self-managed only)

> - Postgres has been updated to 9.6.5. > - Prometheus has been updated to 1.7.2, along with Postgres exporter 0.2.3 and Redis exporter 0.12.2. > - Additional Postgres settings are now configurable within `gitlab.rb`: `effective_io_concurrency`, `max_worker_processes`, `max_parallel_workers_per_gather`, `log_lock_waits`, `track_io_timing`, and `deadlock_timeout`. > - [Roles have been added](https://docs.gitlab.com/omnibus/roles/) to streamline configuration of GitLab in highly available installations.

[GitLab Mattermost 4.2](https://docs.gitlab.com/omnibus/gitlab-mattermost/) (self-managed only)

> GitLab 10.1 includes [Mattermost 4.2](https://about.mattermost.com/blog/mattermost-4-2/), an open source Slack-alternative whose 4.2 release includes interactive message buttons to simplify complex workflows, plus much more. This version includes security updates and an upgrade is recommended. > > Mattermost 4.2 was also included in GitLab 10.0. Anyone on GitLab 10.0 or later should have the patch already.

[Performance Improvements](https://gitlab.com/groups/gitlab-org/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=performance&milestone_title=10.1)

> Performance is an important part of GitLab, allowing GitLab to scale to hundreds of > thousands of users. > > GitLab 10.1 includes 20 performance improvements, including faster viewing of merge > requests, faster importing from GitHub and general initial page load improvements. > The Container Registry page is now paginated, making it much faster. Project search from the > toolbar has been optimized as has viewing projects and issues. The Rebase button > is now also significantly faster.

[GitLab Runner 10.1](https://docs.gitlab.com/runner)

> We're also releasing GitLab Runner 10.1 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: > > * EmptyDir support for kubernetes volumes ([merge request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/660)) > * Construct git remote URL based on configuration ([merge request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/698)) > * Set git SSL information only for GitLab host ([merge request](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/687)) > > List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.1.0/CHANGELOG.md).