GitLab.org/GitLab: Release v10.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 10.2
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Epics](https://docs.gitlab.com/ee/user/group/epics/)
> With this release, we are launching a very early version of _Epics_ as the first feature of [Portfolio Management](https://gitlab.com/gitlab-org/gitlab-ee/issues/3254). Epics are
> designed to enable you to plan and track your work at the feature level,
> as opposed to the design and implementation details level of an issue.
>
> Epics are scoped at the group level. After creating an epic with a title,
> and optionally writing its description, you can then create and link
> multiple issues with the epic. This is a typical top-down workflow where you
> plan a high-level feature idea, and then break it down into smaller issues
> to be implemented. Conversely, you can take a bottom-up approach where you take
> multiple existing issues that are related and link to them together in
> a new epic.
>
> For a given epic, any issue belonging to a project in the epic's group or any
> of the epic's subgroups can be linked. An epic also has optional
> _planned start date_ and _planned end date_.
>
> Epics are included in [Enterprise Edition Ultimate (EEU)](/stages-devops-lifecycle/) and the [Gold plan of GitLab.com](/pricing/#gitlab-com).
[Configurable Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration)
> Many teams share an issue board to plan and track their work, and so they want the board
> to reflect the same set of issues seen by anyone on the team. Previously, you
> were only able to associate a milestone with an issue board. With this
> release, both project boards and group boards are entirely configurable, so that
> you can associate a board with a milestone (including the `No Milestone` choice),
> multiple labels, an assignee, and a weight, providing many more flexible possibilities
> for your team.
>
> This configuration is saved with the board itself, so that anyone who visits the board will
> see that it already has these filters pre-applied. You view and edit this configuration
> by clicking the `View scope` or `Edit board` button (depending on your
> [user permissions](https://docs.gitlab.com/ee/user/permissions.html)).
>
> [Commit Author Restriction](https://docs.gitlab.com/ee/push_rules/push_rules.html)
> [GitLab Enterprise Edition Premium](/pricing/) provides additional levels of control to
> your workflow to ensure that strict policies can be enforced within your
> development environment.
>
> With Commit Author Restriction, it is now possible to ensure that the committer
> is the same user pushing changes back to the repository. This can prevent
> unauthorized code entering your codebase or enforce tightly controlled developer
> workflows.
>
> You can choose to apply this setting to individual repositories, or across the
> entire GitLab instance to enforce server-wide control.
>
> Used in conjunction with EEP's ability to [reject unsigned commits](/releases/2017/10/22/gitlab-10-1-released/#reject-unsigned-commits)
> you can now be in complete control of identity and verification when changes
> are applied to your repositories in GitLab.
[GitLab Geo is now Generally Available](https://docs.gitlab.com/ee/administration/geo/) (self-managed only)
> Many teams who use GitLab are geographically spread out, but your
> GitLab instance is in a single location. GitLab Geo brings GitLab
> closer to your team, making fetch operations like cloning repositories
> faster.
>
> GitLab Geo is now generally available! When configured, GitLab Geo
> keeps read-only secondaries in sync with your primary GitLab instance.
> You can use GitLab Geo to access Git, LFS objects, issues, wikis, and
> CI artifacts from the closest GitLab instance.
>
> **Note**: while Geo and High Availability are now each individually GA,
> use of GitLab Geo in combination with High Availability, is considered *Beta*.
>
> Notable changes shipped with GitLab 10.2:
>
> - Added [HTTPS Git replication support](https://gitlab.com/gitlab-org/gitlab-ee/issues/3341)
> - Added [secure PostgreSQL replication](https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html)
> - Added [API to retrieve geo status](https://gitlab.com/gitlab-org/gitlab-ee/issues/3740)
> - Improved handling of replication errors
>
> See full the [list of changes for Geo on 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Geo&milestone_title=10.2)
[Postgres HA is now Generally Available](https://docs.gitlab.com/ee/administration/postgresql/index.html) (self-managed only)
> For many organizations, GitLab is a critical component of their software engineering
> tool chain, powering not only their code repository but also CI/CD, issue management,
> and much more. To ensure GitLab is available around the clock it can be deployed in a
> [highly available configuration](https://docs.gitlab.com/ee/administration/reference_architectures/), providing additional redundancy
> and scale.
>
> With GitLab 10.2, we are proud to announce that PostgreSQL High Availability is now
> generally available. As part of GitLab Enterprise Edition Premium, the Omnibus
> installation package makes [setting up a production Postgres database cluster](https://docs.gitlab.com/ee/administration/postgresql/index.html) easy.
>
> In the event a database node goes down, the cluster will automatically fail over
> ensuring your developers flow isn't interrupted.
[Compare production and canary performance](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/kubernetes.html#displaying-canary-metrics)
> In GitLab 9.1, we introduced [canary deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
> to GitLab CI, enabling organizations to easily release software in a more controlled
> fashion. A new version can be deployed to a small percentage of your app nodes,
> allowing real-world usage by a subset of users prior to full deployment.
>
> With GitLab 10.2, we have added the ability to track the system metrics of the
> canary version, allowing easy comparison of the real-world performance between
> versions. Developers can quickly determine whether a change had a positive or
> negative impact on performance, and decide whether to proceed with the broader
> deployment. The best part is that they can do all of this without leaving GitLab!
[Improved Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html) (self-managed only)
> GitLab Enterprise Edition enhances control and accountability with Audit Events.
> With GitLab Enterprise Edition Starter (EES) you can view audit events in each
> project or group. GitLab Enterprise Edition Premium (EEP) includes a
> centralised audit log where all project events are collated in a single place.
>
> GitLab 10.2 EES & EEP now include additional events for actions taken on projects
> and groups, including:
>
> - Project or group created
> - Project or group deleted
> - Project moved, renamed or transferred
> - Group visibility changed
> - User added to group, including permission level of user
> - User permission changed
> - Project added or removed from a group
>
> In GitLab EEP, deleted project and group audit data is now persisted in the server-wide
> audit log available in the admin area. The IP address of the user performing the action
> is now also included.
[Restrict push repository mirroring to admins](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html) (self-managed only)
> Push mirroring, when enabled for a repository, will automatically mirror
> it to the configured target Git repository.
>
> Admins can now limit access to push mirroring to only admin users to
> prevent private projects from being automatically mirrored to another
> repository that could be external and unsecured.
[One-click install for Helm and Ingress on Kubernetes](https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications)
> Starting with GitLab 10.1 you can easily connect your Google account to your projects and
> create a new [Kubernetes cluster](https://docs.gitlab.com/ee/user/project/clusters/)
> directly from the GitLab **Cluster** page. Then you can use it to host
> [Review Apps](https://about.gitlab.com/stages-devops-lifecycle/review-apps/) and deployment environments.
>
> In GitLab 10.2 we go even further, allowing you to install
> [Helm Tiller](https://docs.helm.sh/) and [Nginx Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
> with one click into your GKE cluster, reducing the time before you can go live with
> your applications.
[Subgroups and projects on the group page](https://docs.gitlab.com/ee/user/group/subgroups/index.html)
> Subgroups are a great way to organise projects or teams on GitLab. With nearly
> unlimited nesting of groups, you can create structures to reflect complex repositories,
> microservices, or even how your internal development teams are structured.
>
> GitLab's group page has now been given an overhaul to better navigate and explore
> subgroups and projects. You will now see an expandable tree navigation on the group
> page, allowing you to quickly find what you're looking for or discover new projects and groups.
[Personal Access Tokens replacing Private Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)
> Personal Access Tokens can be scoped to certain API privileges, thus providing
> better security when accessing GitLab through the API or third-party applications.
>
> Private Tokens were previously deprecated and have now been completely removed.
>
> All Private Tokens will be migrated to Personal Access Tokens during upgrade, ensuring
> your existing applications continue to function.
[Promote project milestones to group milestones](https://docs.gitlab.com/ee/user/project/milestones/#milestone-promotion)
> When you've outgrown your project, you can easily promote project milestones
> to group milestones. Simply click the button from the desired project milestone page
> to promote it to a group milestone. Similar to label promotion, all project milestones with that same title
> across all projects in the group will be merged together into one group milestone. And all
> issues and merge requests that previously had any of those project milestones
> will now automatically have the new group milestone. Project issue
> boards associated with the previous project milestone are now associated with the promoted
> group milestone.
[Restore project readme view](https://docs.gitlab.com/ee/user/profile/preferences.html)
> Your preferred project home page settings allow you to choose the
> content you want to see on every project's home page. You can choose
> between the projects activity, file list and readme, and readme only.
>
> In GitLab 9.0 the readme only option was removed, but has now been
> restored for those who prefer a minimal project overview.
[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 Contributors and Tag 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).
[API for GitLab Pages](https://docs.gitlab.com/ee/api/pages_domains.html)
> [GitLab Pages](https://about.gitlab.com/stages-devops-lifecycle/pages/) allow you to publish a static website
> directly from your project's pipeline. If you want to make it more professional, you can also
> define custom domains for your content, and protect them with certificates.
>
> In GitLab 10.2, the management of custom domains for GitLab Pages is available via API calls,
> so that you can automate adding new domains, getting information for existing ones, and also updating
> domain information, for example, when your SSL certificate has been renewed.
[Project visibility as a CI/CD variable](https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables)
> In GitLab, you can define if you want to create a public project, or if you prefer to keep it private.
> When dealing with pipelines, sometimes you need this information so you can take different actions.
>
> This information is now available in GitLab 10.2, and reading the `CI_PROJECT_VISIBILITY` variable
> you can define, for example, if public access to artifacts and Docker images for the project are allowed.
> Very useful in case you have a shared template that applies to multiple different projects.
[Omnibus improvements](https://docs.gitlab.com/omnibus/README.html) (self-managed only)
> * Warnings are now clearly displayed when deprecated configuration settings are used.
> * Support has been added for [running separate Redis instances](https://docs.gitlab.com/omnibus/settings/redis.html#running-with-multiple-redis-instances) for each persistence class.
> * OpenSSL has been updated to 1.0.2m.
> * libxml2 has been updated to 2.9.6.
[GitLab Mattermost 4.3.2](https://docs.gitlab.com/omnibus/gitlab-mattermost/) (self-managed only)
> GitLab 10.2 includes [Mattermost 4.3.2](https://about.mattermost.com/blog/mattermost-4-3/),
> an [open source Slack alternative](https://about.mattermost.com) whose
> newest release includes a beta support for tablet computers, mobile
> appenhancements, plus much more. This version includes [security updates](http://about.mattermost.com/security-updates/)
> and an upgrade is recommended.
[GitLab Runner 10.2](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 10.2 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:
>
> * [Upgraded minio library](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/707): support Amazon S3 Accelerated endpoints and `eu-west-2` region
> * Added [`helper_image` option to docker executor config](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/723)
>
> List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.2.0/CHANGELOG.md).
[Performance improvements](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=10.2)
> Performance is an important part of GitLab, allowing GitLab to scale to hundreds of
> thousands of users.
>
> GitLab 10.2 introduces a new GitHub importer that uses Sidekiq to perform
> its work in parallel, vastly reducing the time spent importing projects from
> GitHub. In the event of hitting the GitHub rate limit the new importer will
> suspend work and resume it once the rate limit has been reset, without blocking
> any Sidekiq workers from performing other work.
>
> For small projects such as