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

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

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

[Gemnasium dependency checks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)

> GitLab recently acquired Gemnasium and since then we have worked together to integrate this awesome technology into our security testing features. > > Thanks to the advanced detection and the database of existing vulnerabilities, with GitLab 10.5 you can now receive > very accurate security reports for dependencies of your application for the following languages: > > * Ruby > * Java (Maven) > * Javascript (NPM) > * Python > * PHP > > If you are already using [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), you don't need to change anything. > If you copied the job definition to your pipeline, you can update it to support the latest features. See the > [example](https://docs.gitlab.com/ee/user/application_security/sast/) page for more information.

[View Epics in roadmap](https://docs.gitlab.com/ee/user/group/roadmap/)

> The first iteration of roadmaps is now available in GitLab. Roadmaps allow you to view multiple epics in the same group > (and even epics in subgroups), all together in a time-based view. You can view when epics begin, and when they end together. > > This helps users plan and track work across time, and also allows users to see how different work coincides with each other. > For example, if you plan to launch a new feature in your product in the second quarter of 2018, and you want to have a marketing campaign > to go along with it, you would create one epic for the product work, and another epic for the marketing work, and you would see them > both together in the roadmap view, to ensure that they start and end according to your plans.

[Epics search and filter bar](https://docs.gitlab.com/ee/user/group/epics/)

> In this release, we've added the GitLab search and filter bar to the Epics list page. It's the same search and filter > bar that exists throughout GitLab, for issues and merge requests. In this release, you are able > to filter by epic author, and search epic titles and descriptions. Additionally, ordering functionality is also available, > for ordering by when an epic was created, or last updated. > > This brings the benefits of list organization that you already experience with issues and merge requests. You can easily manage > and narrow down to the epics that you care about by applying the search and filtering. In the future, we will bring additional > filters, most notably [labels](https://gitlab.com/gitlab-org/gitlab-ee/issues/4032).

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

[Include external files in CI/CD pipeline definition](https://docs.gitlab.com/ee/ci/yaml/#include)

> GitLab CI/CD pipelines are defined in a YML definition file that is stored in the > project's repository. Many times you are using the same job definitions for many > different projects, or just copying and pasting existing snippets from examples > and documentation. > > With GitLab 10.5 you can now import other files into your main configuration using > the new `include` keyword. These files can be both local files on the same repository, > or remote files that are publicly accessible via HTTP/HTTPS. Security checks and > deployment configurations are common examples of jobs that can be reused and shared.

[Track additional browser performance metrics](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html)

> In GitLab 10.3, we added the ability to quickly determine the performance impact of merge request with [Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html). With this release we are analyzing three additional metrics for changes: [speed index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index), transfer size, and number of requests. > > We have also added the capability to persist the full [sitespeed.io](https://www.sitespeed.io) report as an artifact, allowing developers and reviewers easy access to a trove of performance and debugging information. If you are using [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-browser-performance-testing), the report will be automatically saved for you.

[Allow developers to create projects in groups](https://docs.gitlab.com/ee/user/group/index.html#default-project-creation-level)

> As part of providing additional flexibility around our permission > model, this will allow group or server admins to set an option > that will give users with Developer role the ability to create > projects.

[Approve additionally in Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)

> We've streamlined and simplified the logic of merge request approvals, making it even > easier for users to configure and use approvals. > > In particular, users can now approve a merge request even if the number of approvals have already been met. > This makes it easier for approvers to give their approval signals, and they do not have to wait or consider > other approvers when approving. It encourages more people to approve and participate in the overall code > review process. > > However, if your workflow is more restrictive, you can set the number > of required approvals to exactly the eligible approvers you have selected. > > Approvers can continue to remove their existing approval if they have already given one in the merge request.

[Single secondary Disaster Recovery is now Generally Available](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/index.html) (self-managed only)

> Disaster Recovery uses Geo replication to allow quick failover to a > different site with minimal effort in a disaster situation. Failover > to a secondary in configurations with a single secondary is now GA.

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

[Instant SSL with Let's Encrypt for GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#let-39-s-encrypt-integration) (self-managed only)

> GitLab often contains some of the most sensitive information within an organization, their source code, and protecting that IP is important. Utilizing [HTTPS](https://en.wikipedia.org/wiki/HTTPS) to encrypt sensitive data like credentials, as well as validating the identity of a site, is a fundamental first step in securing any internet service. > > In the past, enabling HTTPS for GitLab has been a multiple-step process. An organization would have to generate a certificate request, pay a Certificate Authority, copy the files to the GitLab server, and finally configure GitLab to use them. > > With 10.5 we have made this process significantly easier, by integrating with [Let's Encrypt](https://letsencrypt.org/). If your instance is reachable on the internet via HTTP today, simply set `letsencrypt['enable'] = true` in `gitlab.rb` and reconfigure. That's it, HTTPS will now be enabled for the main GitLab domain! > > We will be enabling Let's Encrypt [by default](https://gitlab.com/gitlab-org/build/team-tasks/issues/96) as well as adding support for other GitLab features like the [Registry](https://docs.gitlab.com/ee/user/packages/container_registry/index.html), [Pages](https://docs.gitlab.com/ee/user/project/pages/), and [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/), in a future release.

[Git LFS 2 locking support](https://docs.gitlab.com/ee/topics/git/lfs/index.html)

> [Git LFS 2.0.0](https://github.com/blog/2328-git-lfs-2-0-0-released) > added file locking support to Git LFS. It is now supported by GitLab, > allowing LFS files to be locked using the Git LFS client. Locked files > are easily identified by the lock icon. > > Support for > [locking any file or directory](https://docs.gitlab.com/ee/user/project/file_lock.html) > was added to GitLab Premium 8.9, allowing files to be locked through the > GitLab interface. Git LFS locking has been > [integrated](https://gitlab.com/gitlab-org/gitlab-ee/issues/1830) > with GitLab file locking in GitLab Premium 10.5.

[Dynamic management of secret variables](https://docs.gitlab.com/ee/ci/variables/#secret-variables)

> Secret variables are useful to customize your CI/CD pipelines without exposing sensitive > values to the world. Users with Master permissions can define them in the **CI/CD > Settings** menu, > but the process allowed just one insertion at a time, making bulk definitions really hard. > > In GitLab 10.5 we have a new dynamic management for adding secret variables, supporting > multiple insertions at the same time and greatly improving the user experience.

[Persistent public projects deployments](https://docs.gitlab.com/ee/topics/autodevops/)

> Auto DevOps (Beta) can deploy your application to a Kubernetes cluster automatically, > but this deployment may stop working in case the cluster needs to restart the pods, > for example if they are moved and the source image cannot be found in the cache. > > With GitLab 10.5, public projects automatically set the cluster so it can access > the GitLab Container Registry even after the deployment pipeline ended, creating > a more stable environment for your applications.

[Instance level domain for Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-devops-base-domain) (self-managed only)

> Auto DevOps can automatically deploy your application to a Kubernetes cluster, > but in order to access it you need to provide a domain name associated to the > public IP address of the cluster. > > With GitLab 10.5, you can now specify this domain at instance level, so it can > be automatically used by any project that doesn't override this value with a > specific one, and share it across your entire organization.

[Transfer groups](https://docs.gitlab.com/ee/user/group/index.html#transfer-groups-to-another-group)

> Making it easier to structure groups and subgroups, you can now take an entire > GitLab group and transfer it into another group.

[Seamless Prometheus integration on Kubernetes](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html)

> In GitLab 10.4 we added the ability to [deploy Prometheus into a connected Kubernetes cluster](https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications) with a single click. In this release we are making further improvements by automatically enabling the project's Prometheus integration. > > GitLab utilizes the Kubernetes API to query the deployed Prometheus server without requiring it to be accessible outside of the cluster.

[Deployed Ingresses now configured for Prometheus metrics](https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications)

> [Deployed Ingresses](https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications) are now configured for Prometheus metrics, enabling easy application monitoring for response metrics: latency, throughput, and error rate.

[Global Search API](https://docs.gitlab.com/ee/api/search.html)

> We've added global search support for the GitLab API. This is taking our existing global search > capability used in the GitLab native web UI, and wrapping it in the API to allow > external systems to take advantage of the functionality. > > This allows teams to create custom workflows, for example, searching for content > in files and reporting statistics on those results. > > The API works regardless of whether you have Elasticsearch (available only for GitLab Starter or above) configured or not.

[Labels list page redesign](https://docs.gitlab.com/ee/user/project/labels.html)

> We've cleaned up the labels list page design so you can more easily parse through labels and manage > them individually. The icons have also been refreshed per our new icon designs. Also, we've rearranged > the links to issues and merge requests (of a given label), to take up less horizontal space, making > the overall experience better.

[View all issues of all subgroups on group issues page](https://docs.gitlab.com/ee/user/project/issues/)

> You can now view all issues of all subgroups on the group issues page. This makes the group issues > page more powerful when you have a nested tree structure of groups several levels deep, and you > want to view all issues in that tree in one location. For example, this is useful for teams with > microservices that may be spread across multiple projects and groups, or for teams that have a > nested organization team structure. > > The same change has been brought to the group merge requests page too.

[Navigate to related merge requests from commit page](https://docs.gitlab.com/ee/user/project/merge_requests/#find-the-merge-request-that-introduced-a-change)

> Links to merge requests related to a commit now appear on the commit page itself. This is very useful > when you are reviewing the commit history of a repository, and want to know the greater business and technical > context of a commit. You can now easily navigate to the merge request that introduced the commit, from the commit > page itself. From the merge request, you can see all the previous technical conversations, and if the issue has been > linked (via the [issue closing mechanism](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically) for example), > then you can even navigate back to the issue to see the business context. > > Thank you [@hiroponz](https://gitlab.com/hiroponz) for the contribution!

[Color chips in GitLab Flavored Markdown](https://docs.gitlab.com/ee/user/markdown.html)

> GitLab Flavored Markdown (GFM) now supports color chips. That means anywhere you can enter GFM > (such as issue and merge request descriptions and comments), you can type a color code, and GitLab > will render a helpful color chip next to it. This is especially useful for designers and frontend engineers > to collaborate on designs involving color details, within GitLab. > > Thank you [@thetonyrom](https://gitlab.com/thetonyrom) and [@raviolicode](https://gitlab.com/raviolicode) for the contribution!

[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 Issues and Merge Request sidebars, > Repository Charts page, and Repository Graph page, 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).

[Push to create a project](https://docs.gitlab.com/ee/user/project/working_with_projects.html#push-to-create-a-new-project)

> Pushing a repository to an unused project name in your personal > namespace now automatically creates a private project, so you can start > prototyping your next project even faster!

[Hashed storage is now Beta](https://docs.gitlab.com/ee/administration/repository_storage_types.html#hashed-storage) (self-managed only)

> Hashed Storage is a new storage behavior introduced in 10.0. Instead of > coupling project URL and the folder structure where the repository will > be stored on disk, we are coupling a hash, based on the project's ID. > This makes the folder structure immutable, and therefore eliminates any > requirement to synchronize state from URLs to disk structure. This means > that renaming a group, user, or project will cost only the database > transaction, and will take effect immediately.

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

> * GitLab [Mattermost 4.6](https://about.mattermost.com/releases/mattermost-4-6/) includes faster channel load times and enhanced 508 compliance. > * Chef has been upgraded to 12.21.31 > * Chef Omnibus has been updated to 5.6.3. > * SELinux rules have been added to allow [fast SSH key lookups](https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html).

[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.5)

> Some of the more noteworthy performance improvements in GitLab 10.5 > include: > > * [Global search results are restricted to 1,000 entries, to prevent database timeouts](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16502) > * [Code search results no longer time out when the result includes a very long line](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16462) > * [Faster updates for the merge request widget](https://gitlab.com/gitlab-org/gitlab-ce/issues/36876#note_55858076) > * [New option to exclude commit stats from commit API response, significantly increasing performance](https://gitlab.com/gitlab-org/gitlab-ce/issues/41681)

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

> We're also releasing GitLab Runner 10.5 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: > > * [Fix Git 1.7.1 compatibility](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/791) > * [Always load OS certificate pool when evaluating TLS connections](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/804) > * [Do not add /cache volume if already provided by the user during gitlab-runner register](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/807) > > List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.5.0/CHANGELOG.md).