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

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

![20 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=20&style=for-the-badge "New features added in this release") ![240 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=240&style=for-the-badge "Total features") #### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![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") ![10 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=10&style=flat-square "Total features in this tier")

[Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)

> Running static checks on your code is the first step to detect > vulnerabilities that can put the security of your code at risk. > Yet, once deployed, your application is exposed to a new category of > possible attacks, such as cross-site scripting or broken authentication > flaws. > > Spotting problems automatically gets even better in GitLab 10.4, adding Dynamic > Application Security Testing (DAST) to audit a live version of your application, > for example the Review App created in a previous job, directly from your CI/CD pipeline. > Results are shown in the Merge Request to give easy access to them. Starting with GitLab 10.4.2, > [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-dast) will run DAST automatically > against the [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) of your application.

[SAST for Docker Containers](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html)

> Modern applications that run inside of Containers are more secure because > the code is separated from other Containers on the same host. But even if > your code is safe, the environment it runs on may contain flaws that can impact > the security of the entire application, for example, a vulnerable system library. > > GitLab 10.4 includes the ability to run security checks on the image > that contains your application and to report possible warnings in the > Merge Request before merging the changes into the stable branch. > These checks are part of > [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast-for-docker-images) > to provide security by default.

[Web IDE Editor (Beta)](https://docs.gitlab.com/ee/user/project/web_ide)

> With the introduction of the new editor (beta) as the first feature of > the [Web IDE](https://about.gitlab.com/direction/), > we are making it faster and easier to contribute small fixes and > resolve merge request feedback by eliminating the need to stash changes > and switch branches locally. > > In upcoming releases we will integrate the Web IDE more deeply with > [merge requests](https://gitlab.com/gitlab-org/gitlab-ee/issues/4569) > and improve > [commit staging](https://gitlab.com/gitlab-org/gitlab-ee/issues/4541), > and ultimately add live previews and a web terminal so anyone can > contribute. > > While in the early stages of the Beta, access to the Web IDE is by opting in. > To enable the Web IDE, click on your profile image in the top right > corner and navigate to **Settings > Preferences**, enable the Web IDE > and **Save**.

[Reordering Issues in Epics](https://docs.gitlab.com/ee/user/group/epics/)

> Epics allow you to manage a list of associated > issues that together share a theme. Often an epic represents a > large feature that has been separated into multiple issues to be > worked on across multiple milestones. > > Depending on an organization's workflow, > they may want the list order in epics to reflect different scenarios. > This could be priority, difficulty, feasibility, or order of implementation. > > Some organizations might want to put closed issues near the top, while others > might want them near the bottom. With this release, users can now > reorder the issues in an epic by simply dragging and dropping, similar > to that in Issue Boards.

[Epics API](https://docs.gitlab.com/ee/api/epics.html)

> With this release, the GitLab API supports Epics. So you can now > manage individual epics, lists of epics, and all epic attributes > (title, description, and dates) through the API, allowing your team > to create custom and/or automated workflows outside of GitLab. > > Managing the list of issues associated with an epic [is also supported](https://docs.gitlab.com/ee/api/epic_issues.html), > including the newly introduced reordering capability.

#### [Premium](https://about.gitlab.com/pricing/premium/) ![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") ![49 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=49&style=flat-square "Total features in this tier")

[Group Issue Boards API](https://docs.gitlab.com/ee/api/group_boards.html)

> Similar to Project Issue Boards, you can now manage Group Issue Boards > through the API, starting in this release, providing further > flexibility and opportunities for automation in managing your individual team workflows. > > For example, some teams have certain custom business requirements to move issues automatically > between board columns under certain conditions. This is now possible for group issue boards > through the API.

[GitLab Geo support for HA now Generally Available](https://docs.gitlab.com/ee/administration/geo/replication/multiple_servers.html) (self-managed only)

> In GitLab 10.2 both Geo and Postgres HA individually reached general > availability (GA), but the use of Geo in combination with HA was > considered Beta. > > Configurations using GitLab Geo in combination with HA are now > considered GA. This allows geographically distributed teams to enjoy > faster Git fetch operations using GitLab Geo and the increased > redundancy of highly available configurations

[Browser Performance Testing now included in Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-browser-performance-testing)

> In 10.3 we added > [Browser Performance Testing](/releases/2017/12/22/gitlab-10-3-released/#browser-performance-testing) > to easily determine the performance impact of a change for web apps, > *prior* to merge. To use this feature, it was necessary to [add an additional job](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html) > to your `.gitlab-ci.yml` and adapt to your needs. > > In GitLab 10.4, Browser Performance Testing is now > included in [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops) > as well, providing automatic performance analytics of the root page > with zero configuration. > > If you'd like to test add additional pages, simply add the relative > paths to a `.gitlab-urls.txt` file in the root directory of the > repository.

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

[Rebase and fast-forward in CE](https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html)

> You can now rebase and fast-forward merge directly in the merge request web UI > in GitLab CE. You don't need to jump between GitLab and your local command line > anymore while doing these activities; you can do it in a single flow right inside > GitLab. > > This feature was previously EE only. In support of [GNOME's move to GitLab CE](https://gitlab.gnome.org/GNOME) > we are excited to bring rebase and fast-forward merge to GitLab CE.

[Easily deploy Prometheus on Kubernetes](https://docs.gitlab.com/ee/user/project/clusters/index.html#installing-applications)

> GitLab can now deploy [Prometheus](https://prometheus.io/) into a > [connected Kubernetes cluster](https://docs.gitlab.com/ee/user/project/clusters/index.html) > with a single click, making it easier than ever to > begin monitoring the performance of your application. System metrics like > processor and memory utilization latency are automatically retrieved from > Kubernetes, and response metrics like latency and throughput are available > with a > [supported ingress](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/nginx_ingress.html). To get started, connect a cluster at `CI/CD > Clusters`. > > If GitLab has network connectivity to Prometheus, [Prometheus integration](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) > can be enabled to analyze and display these metrics directly within GitLab. In the next release, GitLab 10.5, integration will be > [automatically enabled](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16182) > and will not require direct network access, offering seamless integration.

[Fast SSH key lookup in CE](https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html) (self-managed only)

> When authorizing a user, OpenSSH uses linear search to find a key. This > means that SSH operations become slower as the number of users on a > GitLab instance grows. For large instances significant time and disk > I/O may be required to fulfill a request, making Git over SSH slow. > > In GitLab 9.3 fast SSH key lookup was added to GitLab EE. This > authorizes SSH users via a fast, indexed lookup in the GitLab database > instead of the default slow linear search. GitLab CE is designed for > small teams, and as a result did not previously include this > optimization. However, in support of GitLab's Cloud Native Helm Charts, > all parts of the code base will need to support fast SSH key lookup > and has thus been added to GitLab CE.

[Status icon for LFS-tracked files](https://docs.gitlab.com/ee/topics/git/lfs/index.html)

> Identify which files are tracked by Git LFS with the new LFS tracking > status icon shown in blob views and file lists, including the merge > request change list. This makes it possible to verify binary files are > correctly tracked by LFS when reviewing a merge request.

[Improved environment performance dashboard](https://docs.gitlab.com/ee/ci/environments/index.html#monitoring-environments)

> In GitLab 10.4 we have improved the design of the > [environment performance dashboard](https://docs.gitlab.com/ee/ci/environments/index.html#monitoring-environments), > which displays the system and response metrics captured by Prometheus. > > Now, when reviewing metrics at a specific point in time, they are > clearly displayed on the hover over instead of in the chart's > legend. In an upcoming release, we will add summary metrics to the legend, > displaying statistics such as the maximum throughput, or average latency > over the time span.

[Support for openSUSE Leap 42.3](https://about.gitlab.com/install/#opensuse-42-2-and-42-3) (self-managed only)

> With GitLab 10.4, Omnibus packages are now available for > [openSUSE 42.3](https://en.opensuse.org/Portal:42.3). > > This will be the > [last release with support](#end-of-support-for-the-opensuse-42.2-omnibus-package) > for openSUSE 42.2, as it is being officially discontinued.

[Clear the Runner cache](https://docs.gitlab.com/ee/ci/runners/#manually-clear-the-runner-cache)

> GitLab Runner uses a cache to speed up execution by reusing existing data > between different jobs. But sometimes it leads to inconsistent > behaviors, for example, when the local copy of the repository is > modified by one job, and the new changes impact the execution of the > following one. > > In GitLab 10.4, we introduce a new button in the Pipelines page that > can be used to clear any existing cache for the specific project and > start fresh with a new one. This immediately solves the problem of > "dirty" runs.

[GitLab Clusters now Generally Available](https://docs.gitlab.com/ee/user/project/clusters/)

> With GitLab 10.4, we are proud to announce that the Kubernetes cluster > integration is now Generally Available! You can connect your existing > clusters to your project, or create new ones on Google Kubernetes > Engine (GKE) with a few clicks of your mouse, using the new Clusters > page, under the CI/CD section. > > The old Kubernetes integration service is still accessible, but it can > be used only if it was enabled before the upgrade to GitLab 10.4. In > the upcoming releases, the existing data will be migrated to the new > Cluster page and the integration page will be eventually removed. > [Service Templates](https://docs.gitlab.com/ee/user/project/integrations/services_templates.html), > available in the Admin area, are working as usual.

[Run a scheduled pipeline manually](https://docs.gitlab.com/ee/ci/pipelines/schedules.html#running-a-scheduled-pipeline-manually)

> Scheduled pipelines are very useful to run recurring jobs without a manual > action by the user. They are normally used to perform maintenance tasks, or > to create nightly builds for your software. But sometimes that exact scope > is also needed on-demand, and recreating the same environment (e.g., adding > custom variables) can be hard and time consuming. > > GitLab 10.4 introduces the ability to run a scheduled pipeline manually, > directly from the web interface: a "play" button can be found for each > schedule in the list, and running the pipeline is just as simple as a click.

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

> We're also releasing GitLab Runner 10.4 today! GitLab Runner is the > open source project that is used to run your CI/CD jobs and send the > results back to GitLab. > > The most interesting changes: > > * [Add (overwritable) pod annotations for the Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/666) > * [`docker.allowed_images` can use glob syntax in `config.toml`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/721) > * [Add support for user-defined Docker runtime](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/764) > * [Do not use `git config --local` as it's not available in Git v1.7.1](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/790) > > List of all changes can be found in GitLab Runner's > [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.4.0/CHANGELOG.md).

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

> * GitLab Mattermost version 4.5 includes Zoom plugin for video, audio, > screen sharing, and much more. > * CA certificates have been updated to 2017.09.20 > * GitLab Monitor has been updated to 2.4.0 > * Ruby has been updated to 2.3.6 > * Go based libraries such as Registry, Workhorse, and Prometheus are built > with Go 1.9.2

[Performance improvements](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=10.4&label_name[]=performance)

> We are continuing to make great strides in improving the performance of > GitLab in every release. > [We're committed](/handbook/product/gitlab-the-product/#performance) not only to making > individual instances of GitLab even faster but also greatly > improving the performance of GitLab.com, an instance that has over one > million users! > > In GitLab 10.4 we are shipping performance improvements for issues, > merge requests, repositories and API. Some of the more noteworthy > improvements include: > > * [Drastically improved filtering performance of issues by label](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16136) > * [Improve query performance of retrieving merged and closed event information for the merge request widget](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15642) > * [Improve performance and reduce memory usage of calculating commit stats](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16186) > * [Prevent cache misses for empty markdown and HTML strings](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15856) > * [Soft removals of data such as issues and merge requests has been removed](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15789), simplifying database queries. Any soft removed data will be removed physically in this release. > * [Fix N+1 query problem when displaying a project's Atom feed](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16199) reducing the loading time of Atom feeds > * [Fix N+1 query problem in the projects build API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16445)