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

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

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

[Related Issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html#related-issues)

> Whenever you share a link from one issue to another, GitLab shortens it and crosslinks it automatically. > But when issues get longer and projects more complex, it becomes hard to manage links and quickly find > related issues. > > To solve this problem, we're introducing Related issues. With Related issues, you can formally declare > another issue as related. A link to the other issue, its status and name will be shown in each issue. > > Simply paste a link to the issue you want to link or search for it by typing `#` (as you were able to do already) > to link it. In the future, we will introduce different types of relationships through this mechanism.

[Environment-specific Secret Variables](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-secret-variables)

> Variables are often the right solution to define values that are then used during deployments to specific [environments](https://docs.gitlab.com/ee/ci/environments/index.html). > Since different environments (e.g.: **staging** and **production**) may require different values for the same task, > such as the app name, it is important to create a direct binding between some variables and the related environment. > > With GitLab 9.4, Environment-specific Variables are introduced to solve this issue, as developers can now define which environments > will receive a variable, even using wildcards to include dynamic environments, like `review/*. > It is now easy to deploy to different environments with a minimal effort!

[PostgreSQL High Availability (Beta)](https://docs.gitlab.com/ee/administration/postgresql/index.html) (self-managed only)

> GitLab 9.4 arrives in Beta for deploying the bundled PostgreSQL > server in a highly available manner, with a simple manual action to recover in the event > a node goes down. This allows for a more robust deployment of GitLab, reducing the duration > of an outage and potential for data loss. We are working to > [automate the failover process](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2571) in a subsequent release.

[Mini-Graph for Multi-Project Pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#multi-project-pipeline-graphs)

> We recently introduced [Multi-Project Pipeline Graphs](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs) to easily > follow dependencies between related projects. > With GitLab 9.4 we extend this also to mini-graphs in the Merge Request widget, where you can now see pipelines for downstream projects with their current status.

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

> Notable changes: > > - GitLab Geo now supports PostgreSQL replication slots to prevent secondary Geo > nodes from getting out of sync with the primary. See > [the documentation](https://docs.gitlab.com/ee/administration/geo/setup/database.html#step-3-initiate-the-replication-process) > for more details on how to use it the primary. > - We've increased the performance of replicating Git data by > [adding more concurrent clone operations](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2351). > - Geo now ships with an initial version of an event log cursor that allows the > secondary track when it needs to update a Git repository. We'll be deprecating the use of > Geo system hooks in the future.

[Object Storage for CI Artifacts](https://docs.gitlab.com/ee/administration/job_artifacts.html#using-object-storage) (self-managed only)

> As companies continue to embrace CI/CD across the organization, their > artifact storage needs naturally increase as well. With GitLab 9.4 you can move > existing [CI artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html) > to [Amazon S3](https://aws.amazon.com/s3/), in order to free local space and enable > artifacts to be saved cost effectively, reliably, and with nearly infinite scalability. > For now this operation has to be run every time you want to move your local artifacts to S3, > but in a future iteration it will be automatically done so all the new artifacts will be saved > on object storage as soon as they're created, without the need of a manual migration.

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

[New Navigation](https://about.gitlab.com/blog/2017/07/17/redesigning-gitlabs-navigation/)

> To make it easier and faster to get around GitLab, we're working on > updating our navigation. Because a new navigation can be a big disruption, > we're releasing the first step as an opt-in configuration with GitLab 9.4. > > To enable the new navigation, click on your profile image in the top right corner and > choose **Turn on new navigation**. > > We have made adjustments to the global top navigation and introduced contextual navigation in the left > menu depending on what page you are currently viewing. > The new UI is still a work in progress and will replace the existing navigation > in the next few months, please see our [blog post](https://about.gitlab.com/blog/2017/07/17/redesigning-gitlabs-navigation/) > about our process and what work still needs to be done. > > We'd love to hear [your feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917).

[Web Application Monitoring](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html)

> As part of GitLab 9.0 we [launched system performance management](https://about.gitlab.com/releases/2017/03/22/gitlab-9-0-released/#environment-monitoring-ce-ees-eep) > integrated with CI/CD deployments, > [monitoring deployed applications](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8935) > on Kubernetes by tracking CPU and Memory utilization. This was a great > first step, and with GitLab 9.4 we are excited to launch Web Application Monitoring with support beyond Kubernetes. > > GitLab will now automatically detect key user experience indicators like throughput, error rate, and latency. Simply connect [Prometheus](https://prometheus.io) to a > [supported load balancer or HTTP server](https://docs.gitlab.com/ee/user/project/integrations/prometheus_library/index.html), > and it will identify and begin tracking these statistics. > > Delivering a great experience is everyone's responsibility, and GitLab is making this easier by closing the performance feedback loop in the tool developers use every day.

[Group-level Secret Variables](https://docs.gitlab.com/ee/ci/variables/#secret-variables)

> Secret variables are really useful when you need a safe place to store > sensitive information. Until now, secret variables were stored at the project level. > However, we know its common for different projects > in the same group to share information on deployment or credentials for accessing external services. > > Group-level Secret Variables remove the need to duplicate variables > from one project to the next: now you can enter these values once, > and each project or subgroup in the group will access them automatically. > It's also really simple to update these values. You just change them > in one place and they'll be automatically modified for all of the projects.

[Variables in Pipeline Schedules](https://docs.gitlab.com/ee/ci/pipelines/schedules.html#making-use-of-scheduled-pipeline-variables)

> In GitLab 9.2 we introduced [Pipeline Schedules](https://about.gitlab.com/releases/2017/05/22/gitlab-9-2-released/#pipeline-schedules) > to automatically run pipelines at a specific interval of time, but most teams also want > to specify different values for specific variables when running the schedule. > > In GitLab 9.4, we've added the ability to define variables when creating or modifying a pipeline schedule: > these values will be added to all the other variables already defined. > Using this feature, you can also redefine existing variables to have a different value only for that specific run, > for example if you want to have a "daily" pipeline running some tests in a different way.

[GitLab Power-Up for Trello](/blog/2017/07/22/gitlab-trello-power-up-launch/)

> Using both Trello and GitLab? Now you can make that experience even better with the new [GitLab Power-Up](https://docs.gitlab.com/ee/integration/trello_power_up.html)! > In Trello, when viewing one of your boards, simply go to `Power-Ups` and scroll > to the `GitLab` Power-Up. After setup, you will be able to attach merge requests > to Trello cards. > > In Trello, you will need to configure your domain, such as `gitlab.com/api/v4` for GitLab.com, > and add your personal token.

[GitLab Slack App for GitLab.com](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html)

> 🚀 GitLab already integrated deeply with Slack (and [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/README.html#gitlab-mattermost), [Microsoft Teams](https://docs.gitlab.com/ee/user/project/integrations/microsoft_teams.html#microsoft-teams-service), and [HipChat](https://docs.gitlab.com/ee/user/project/integrations/hipchat.html#atlassian-hipchat)), > but we didn't have an app in the Slack App Directory yet. Today we do 🎉! That means setting up > Slack integration with your projects on GitLab.com is now much easier. > > You can set it up from your project settings in GitLab (**Settings > Integrations**). Soon > it will be available from the Slack App directory as well. We're working together with > Slack on making sure private instances will > be able to use the same Slack App in the near future. Of course, private instances are able > to integrate with Slack using the manual steps outlined in the > [documentation](https://docs.gitlab.com/ee/user/project/integrations/slack_slash_commands.html).

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

> We are accelerating our efforts with Internationalization. A big thank you > to members of our community who are already contributing additional > languages including Chinese, French, Japanese and Brazillian Portuguese. > A huge thanks to [Huang Tao](https://gitlab.com/htve) for continuously > contributing to the cause! > > In GitLab 9.4 we have added Internationalization support for the Commits page.

Unified Slack Interface

> With this release, we are unifying the issue information shown in Slack in response to a link being pasted, > a [Slack slash command](https://docs.gitlab.com/ee/user/project/integrations/slack_slash_commands.html) > being executed, or a [Slack notification](https://docs.gitlab.com/ee/user/project/integrations/slack.html). > This provides a coherent experience regardless of how an issue is referenced in Slack.

[Group Milestones](https://docs.gitlab.com/ee/user/project/milestones/index.html#creating-a-group-milestone)

> Milestones are fundamental to issue tracking. They are often used to designate a sprint (week 35), > a release (9.4) or a category (Backlog) of issues and merge requests. Often milestones span > multiple projects: you were already able to quickly create milestones in multiple projects > at once in GitLab. To make this experience better, we've now added the ability to create _Group milestones_. > > Group milestones behave exactly like their counterpart _project milestones_, but are created in > the group and from there available to all projects directly belonging to that project. > > To create a group milestone, visit your group and go to **Issues** and then **Milestones**.

[Additional GitLab Service Metrics](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html) (self-managed only)

> With GitLab 9.4 we have added additional instrumentation to our Ruby on Rails code, > providing insight into the HTTP requests, latency, and errors at the Rack middleware layer. We will continue to instrument additional areas of GitLab in subsequent releases.

[Customizable Path for CI/CD Configuration](https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-ci-config-path)

> GitLab defines CI/CD configuration in a YAML file named `.gitlab-ci.yml` > that is located in the root of the repository. > There are cases where you need to specify a different location for the > definition of your pipelines, for example when you > mirror a SVN repository and cannot have files in the root of the project. > > Starting with GitLab 9.4, you can now specify in **Settings > Pipelines** a custom > path that will be used to read CI/CD configuration instead > of the default `.gitlab-ci.yml`. A variable named `$CI_CONFIG_PATH` is available to > jobs in order to access the current config location.

[New Cache Policy for CI/CD Configuration](https://docs.gitlab.com/ee/ci/yaml/#cachepolicy)

> The default behaviour of a caching job is to download the files at the start > of execution, and to re-upload them at the end. > This allows any changes made by the job to be persisted for future runs, > and is known as the pull-push cache policy. > > The default behaviour of a caching step is to restore and archive dependencies of your jobs, allowing speed-up of subsequent runs. > If any change is made to the cached content, it is pushed to the cache server by default, and this behavior is known as the pull-push cache policy. > > If you're not interested in updating the cached files for a specifig job, you can skip the upload step by setting `policy: pull` in the job specification. > Alternatively, if you have a job that unconditionally recreates the cache without reference to its previous contents, you can use `policy: push` > to save a lot of unnecessary load on the cache server. This feature requires GitLab Runner 9.4 or above.

[Extended Docker Configuration for CI/CD](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#extended-docker-configuration-options)

> In GitLab 9.4 we introduce new advanced configuration options for `.gitlab-ci.yml` that allow you more flexibility when defining Docker images > that you want to use for your pipelines. These improvements require also GitLab Runner 9.4 or above. > > You can now specify a custom `entrypoint` for your Docker image, in order to override the default one: here is an example to set > the entrypoint to `/bin/sh`, making the image suitable for GitLab CI jobs without further modifications: > > image: > name: super/sql:experimental > entrypoint: ["/bin/sh"] > {: .language-yaml} > > You can also specify aliases for services to run multiple concurrent instances of the same Docker image, and specify commands directly in the configuration file. > > services: > - name: super/sql:latest > command: ["/usr/bin/super-sql", "run"] > alias: super-sql-1 > - name: super/sql:latest > alias: super-sql-2 > {: .language-yaml}

[Improved Prometheus Monitoring of Kubernetes Deployments](https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html#configuring-prometheus-to-monitor-kubernetes)

> Since the release of [GitLab 9.0](https://about.gitlab.com/releases/2017/03/22/gitlab-9-0-released/#environment-monitoring-ce-ees-eep), the Prometheus server bundled with Omnibus GitLab > has supported monitoring Kubernetes nodes for CPU and Memory metrics. With the release > of 9.4, the Prometheus server will also automatically monitor any > [specifically annotated Pod metrics](https://prometheus.io/docs/operating/configuration/#) > as well.

[Security - Add LDAP SSL Certificate Verification](https://docs.gitlab.com/ee/administration/auth/ldap/index.html#tls-server-authentication) (self-managed only)

> We added support for certificate verification for LDAP over SSL. This option will > be disabled by default for backwards-compatibility until GitLab 10.0. Additionally, > to aid in configuring a secure connection, you can now specify a CA certificate file > and SSL version. Encryption method names `ssl` and `tls` have been deprecated in favor > or `simple_tls` and `start_tls`, respectively.

Upcoming Omnibus Package Signing (self-managed only)

> Starting with our 9.5 release on August 22nd, we will be signing all > new packages going forward. Along with the 9.5.0 package, we will also be providing > signed versions of the latest 9.4 and 9.3 releases. > > Package signing provides additional confidence that the `.deb` and `.rpm` files > used to install GitLab have not been surreptitiously modified.

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

> GitLab 9.4 includes [Mattermost 4.0](https://about.mattermost.com/mattermost-4-0), > [an open source Slack-alternative](https://about.mattermost.com/), with a new look, > new mobile apps, new API and Italian language support. > > This version includes [security updates](http://about.mattermost.com/security-updates/) > and upgrading is recommended.

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

> We're also releasing GitLab Runner 9.4 today! > > ##### Most interesting changes: > > * Improvements in Kubernetes volumes support ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/606) and [merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/625)) > * Support for cache policies in `.gitlab-ci.yml` file ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/621)) > * Extended Docker configuration in `.gitlab-ci.yml` file ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/596)) > * `--all` option added to `unregister` command ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/622)) > * Switch to Go 1.8 ([merge request](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/620)) > > List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/v9.4.0/CHANGELOG.md).

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

> When using a container registry that is external to the Omnibus GitLab package, > there is additional configuration required starting with the 9.4.0 release. > > Previously, only the path to the registry key used for communication between GitLab and the registry (`gitlab_rails['registry_key_path']`) was necessary. > Now along with the path, it is also required to specify the content of the key by setting > `registry['internal_key']` inside of `/etc/gitlab/gitlab.rb`. Documentation for utilizing an external registry will be available soon. > > Other changes: > > 1. NGINX has been updated to the next stable version, 1.12.1 > 1. openSUSE 42.2 is now officially supported

Performance Improvements

> We are continuing to make great strides improving > the performance of GitLab in every release. We're committed to not only > making individual instances of GitLab even faster, > but also to greatly improving the performance of GitLab.com, > an instance that has over 1 million users! > > In GitLab 9.4 we are shipping performance > improvements for issues, projects, milestones, and a lot more! > > For a list of implementations, please check the merge requests for > [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=9.4&label_name%5B%5D=performance) > and > [GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=9.4&label_name%5B%5D=performance).