GitLab.org/GitLab: Release v12.4.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.4
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Git Activity added to Group IP Address Restriction](https://docs.gitlab.com/ee/user/group/#ip-access-restriction-ultimate):
> GitLab 12.0 saw the introduction of [restricting a group's activity by
> IP address](https://gitlab.com/gitlab-org/gitlab/issues/1985). In GitLab
> 12.3, we included API activity in the access restriction. In GitLab
> 12.4 we're extending this further to include Git actions via SSH.
>
> The resulting feature now provides extensive coverage, rejecting UI,
> API, and Git activity if they do not adhere to the group's IP address
> restriction. For compliance-minded organizations, especially those on
> GitLab.com, this provides an comprehensive and important security layer.
Groups[DAST for the Master Branch](https://docs.gitlab.com/ee/user/application_security/dast/):
> We are pleased to announce that DAST scans can now run against a project's
> default branch inside a dedicated review app. Previously, DAST only ran
> against feature branches. This enhancement allows the creation of a DAST
> results baseline on the default branch against which MRs are compared.
> With this, you can pinpoint the exact branch where new security issues
> are introduced.
Auto DevOps[View Pod Logs from Any Environment](https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html):
> Previously, GitLab logs were primarily accessed via the Environments page.
> This made it difficult to easily switch between logs from different environments
> for troubleshooting purposes. It also prohibited direct access of logs without
> first accessing a specific Environment.
>
> Now, with GitLab 12.4, we've enabled the ability to view any logs from
> any environment or pod. From the environments page, you'll see two
> buttons to view any pod logs from your Kubernetes clusters. Going forward
> we'll continue to improve how you can access your logs including creating
> a Logging link directly in your Operations menu.
Logging[Use Jaeger in the GitLab UI](https://docs.gitlab.com/ee/operations/tracing.html#jaeger-tracing)
> Tracing provides insight into the performance and health of a deployed
> application by tracking each function or microservice which handles a
> given request.
>
> Jaeger is an open source, end-to-end distributed tracing system used for
> monitoring and troubleshooting microservices-based distributed systems.
>
> With GitLab 12.4, users that are using Jaeger can access it and view the
> performance and health of their deployed application without
> leaving the GitLab UI.
[Generic Alert Endpoint MVC](https://docs.gitlab.com/ee/operations/incident_management/integrations.html):
> People make use of a variety of different tools to monitor their
> application environments. These tools send critical,
> time-sensitive alerts when an incident arises and action needs to be
> taken. Now, GitLab's Incident Management capabilities include a generic
> REST endpoint where you can send alerts, regardless of the tool that
> generated them. When GitLab receives a POST to the endpoint, it will
> automatically create an incident issue. The payload is included in the
> issue description and commonly used fields are automatically parsed.
> This allows you to use GitLab issues as a central place for incident
> response leveraging inputs from your other tools.
>
> Please check out a short video that highlights the [Generic Alert
> Endpoint MVC](https://www.youtube.com/embed/tfouNm_225c).
Incident Management[Audit Events API](https://docs.gitlab.com/ee/api/audit_events) (self-managed only):
> [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html)
> are a powerful way to better understand activity inside GitLab.
> Organizations may rely on audit events to ensure that user activity
> adheres to policies; for enterprises operating under regulatory
> scrutiny, this can be of critical importance.
>
> To make audit events easier to use for automation, we're
> introducing an API for instance-level audit events. Using the Audit
> Events API, administrators can obtain events programmatically and better
> enable your own powerful alerting and monitoring that meets your
> organization's specific needs.
Audit Management[Native Geo Support for Object Storage Replication](https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication) (self-managed only)
> In GitLab 12.4, Geo natively supports replicating data in object
> storage such as LFS objects, job artifacts, and uploads. Previously, Geo
> could be configured to work with object storage; however, the
> replication of the content was always left to the object storage
> provider. This imposed limitations when users relied on local storage
> appliances that do not support any replication logic.
>
> Native Geo support allows data to be replicated across different object storage
> providers in different regions (e.g. Amazon in Europe and Microsoft in
> the United States). Geo users can also use local storage, for example
> via MinIO, and use Geo to replicate data to secondary nodes.
>
> Native Geo support for object storage replication is currently a [beta
> feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta) and is not
> ready yet for production use.
[Geo Supports Using a Single, Location-aware Git URL](https://docs.gitlab.com/ee/administration/geo/replication/location_aware_git_url.html) (self-managed only)
> Geo now supports providing users with a single remote URL that
> automatically uses the Geo node closest to them. This means users don’t
> need to update their Git configuration to take advantage of closer Geo
> nodes as they move. In fact, end users won't even have to know that they
> are using a local Geo node when initially cloning a project. For systems
> administrators, it removes the need to maintain different Git
> configurations for users in different locations. This is possible
> because, Git push requests can be automatically redirected (HTTP) or
> proxied (SSH) from secondary nodes to the primary node.
>
> Geo can be configured to use different services, such as [AWS
> Route53](https://aws.amazon.com/route53/) or
> [Cloudflare](https://www.cloudflare.com/).
[Date Picker for Productivity Analytics](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html):
> Until now, users were not able to select a specific date range for their
> metrics in cycle analytics and productivity analytics. This meant that
> they cannot drill down or report into productivity during a specific
> sprint or a custom date range since we only provided preset periods such
> as 7, 30, 60, 90 days. With the release of this feature, users will be
> able to visualize how their data looks over any time frame and
> the periods that actually matter to them.
Value Stream Management[Scatterplot for Productivity Analytics](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html):
> Previously, users were not able to easily visualize and measure
> velocity over time. In order to enable them to do that, we are adding
> scatterplots to Productivity Analytics, where users can select 'Time to
> Merge' or any other merge request related metric in order to spot
> relevant trends or outliers. Users can also zoom in on a particular date
> range in order to research and analyze specific data sets.
Value Stream Management[Improved Geo Upgrade Documentation](https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html) (self-managed only)
> As part of our effort to [simplify the Geo upgrade
> process](https://gitlab.com/groups/gitlab-org/-/epics/1450), we reworked
> large parts of the Geo upgrade documentation. GitLab Geo can be deployed
> in different configurations and depending on the configuration Geo
> upgrades require different steps. At this moment, upgrading Geo is still
> highly manual and can involve many individual steps. To improve this in
> an iterative way, we focused first on [improving the Geo upgrade
> documentation](https://gitlab.com/groups/gitlab-org/-/epics/1935)
> itself. This ensures that the documentation is up-to-date and covers all
> use cases.
>
> We rewrote the [general update
> steps](https://gitlab.com/gitlab-org/gitlab/issues/12773), [archived old
> update steps](https://gitlab.com/gitlab-org/gitlab/issues/11881),
> [updated zero-downtime upgrade instructions for simple
> deployments](https://gitlab.com/gitlab-org/gitlab/issues/14000) and
> investigated [many other parts of the
> documentation](https://gitlab.com/groups/gitlab-org/-/epics/1935).
>
> We are also working on instructions for zero-downtime updates of [a
> multi-node, high-availability Geo
> cluster](https://gitlab.com/gitlab-org/gitlab/issues/7602); however,
> these instructions require more testing before we release them.
>
> Following this work, we will work on better automation, improved
> testing, and making certain upgrade procedures more robust.
[Global View for Instance-level Cluster Deployments/Environments](https://docs.gitlab.com/ee/user/clusters/environments.html)
> The **Environments** view was [introduced in GitLab
> 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#global-view-for-group-level-cluster-deploymentsenvironments)
> for group-level clusters. The **Environments** section of the cluster
> page provides an overview of all the projects that are making use of the
> Kubernetes cluster, including the deployments/environments that have
> been provisioned and the number of pods used by each environment. Now
> in 12.4 the "Environments" view is available for instance-level
> clusters. Navigate to your instance **Kubernetes** page and click on the
> **Environments** tab. For group-level clusters, the cluster
> "Environments" view has been extended to instance-level clusters.
>
> The “Environments” section of the cluster page provides an overview of
> all the projects that are making use of the Kubernetes cluster,
> including the deployments/environments that have been provisioned and
> the numbers of pods used by each environment.
[Merge Request Dependencies](https://docs.gitlab.com/ee/user/project/merge_requests/dependencies.html):
> Developers often work together to achieve a larger goal through
> many small changes. These changes need to be merged in a specific
> sequence to work as intended, but keeping track of these dependencies
> can be confusing and error prone.
>
> Merge Request Dependencies allow dependencies to be defined in merge
> requests, to prevent changes from being merged in the wrong order. This
> also increases the visibility of dependencies during code review to help
> the reviewer understand the full scope of the proposed changes. This
> feature was introduced in
> [12.2](/releases/2019/08/22/gitlab-12-2-released/#cross-project-merge-request-dependencies)
> but in 12.4 it has been improved to also support Merge Request
> Dependencies within the same project.
Source Code Management[Code Owner Approvals for Protected Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#protected-branches-approval-by-code-owners-premium)
> Using merge request approvals to restrict how code is pushed to
> protected branches is helpful for promoting code quality and
> implementing compliance controls. However, not all merge requests target
> stable branches, and not all stable branches need the same controls.
>
> In GitLab 12.4, it is possible to require Code Owner approval for
> specific branches to prevent directly pushing changes to files or
> merging changes without a code owner's approval.
>
> If code owner approval was required using the previous Project
> setting, this has been applied to your existing Protected Branches.
[Delete Designs in Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html#deleting-designs):
> Sometimes mistakes happen or design goals change and the ability to
> remove a design from a revision can be important. With deletions in
> Design Management users can select one or more designs and remove them
> from the latest version. This enables the latest version of the design
> to represent the true state of ideas.
Design Management[Design Management System Notes](https://docs.gitlab.com/ee/user/project/issues/design_management.html):
> In GitLab 12.2 we released the first iteration of Design Management,
> which allowed uploading designs directly to issues. They were uploaded
> in a separate tab within issues and their activity wasn't logged, making
> it harder to identify whether there were designs added the issues. From
> GitLab 12.4 on, when designs are uploaded, new system notes are output
> to the issue's thread to inform the participants. In a future release,
> we'll bring [status and discussion
> count](https://gitlab.com/gitlab-org/gitlab/issues/12705) indications to
> the designs to further inform users on design's activity.
Design Management[Variable Expansion Support for Multi-project Pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#specifying-a-downstream-pipeline-branch):
> When using a multi-project pipeline flow, where one pipeline triggers
> another, it's often helpful to be able to store a dynamic value in a
> variable upstream that you can reference in the downstream pipeline. For
> example, if a pipeline is running on a branch and you want
> the `$CI_COMMIT_REF_NAME` on that branch accessible throughout all of the
> downstream pipelines.
>
> Previously, the variable didn't expand so calling a variable downstream
> via the `trigger` keyword failed with a `no ref name` error. Getting
> this workflow to work required spawning a separate job whose only
> purpose was to execute a cURL command to kick off the next pipeline
> passing in the variable state. In addition to requiring extra set up and
> extra resources to run this workaround loses the ability to visualize
> the relationship between pipelines in the UI.
>
> Now GitLab will expand variables used inside of the `branch`
> property of the `trigger` keyword, simplifying your pipeline design and
> adding more flexibility around how your pipelines trigger each other in
> multi-project scenarios.
Continuous Integration[Restrict Permissions for Manual CI Jobs](https://docs.gitlab.com/ee/ci/jobs/job_control.html#protect-manual-jobs):
> Teams often need to create manual jobs to handle things like
> deployments, soft approvals, or other gates, but in GitLab it's not
> obvious how to restrict these permissions to prevent just anyone from
> completing the action.
>
> This was actually already possible in GitLab today, but wasn't clearly
> documented. In this release we've significantly improved the
> [documentation for protecting manual
> jobs](https://docs.gitlab.com/ee/ci/jobs/job_control.html#protect-manual-jobs)
> to make it more clear how to get this set up.
Continuous Integration[GitHub Integration Default to Static Status Check Names](https://docs.gitlab.com/ee/user/project/integrations/github.html#static--dynamic-status-check-names):
> We have changed the default setting for our GitHub integration to use
> [static status check
> names](https://docs.gitlab.com/ee/user/project/integrations/github.html#static--dynamic-status-check-names)
> by default on new projects. With static status check names enabled on
> the integration page, your GitLab instance host name is going to be
> appended to a status check name, whereas in case of dynamic status check
> names, a branch name is going to be appended. This is a more sensible
> initial setting that will ensure that [requiring status
> checks](https://help.github.com/en/articles/about-required-status-checks)
> works out of the box for users using GitLab CI/CD with a GitHub
> repository.
Continuous Integration[API Endpoint for 'Static Status Check Names' in GitHub Integration](https://docs.gitlab.com/ee/api/services#github-premium):
> It is now possible to configure the static status check names in the
> GitHub integration via the API, making it much easier to change this
> setting on large numbers of projects.
Continuous Integration[Sort Packages in the Registry UI](https://docs.gitlab.com/ee/user/packages/):
> The GitLab Package Registry allows users to build, publish and share
> [npm](https://docs.gitlab.com/ee/user/packages/npm_registry/),
> [Maven](https://docs.gitlab.com/ee/user/packages/maven_repository/) and
> (coming soon)
> [Conan](https://docs.gitlab.com/ee/user/packages/conan_repository/)
> packages. GitLab provides a user interface that displays package
> metadata and helps users to find their project or group's packages.
> However, until recently, users had to manually scroll through their list
> of packages to find the package they were looking for.
>
> In GitLab 12.4, we are happy to introduce sorting to the Package
> Registry user interface to improve navigation and discoverability! Now
> you can sort packages at the project and group level by `created date`,
> `name`, `version`, and `type`. In the coming milestones, we are working
> on [adding last commit and
> branch](https://gitlab.com/gitlab-org/gitlab/issues/33596) and will be
> [redesigning the user interface to include all relevant
> metadata](https://gitlab.com/gitlab-org/gitlab/issues/31639).
Package Registry[Access Control for Pages is now enabled on GitLab.com](https://docs.gitlab.com/ee/administration/pages/#access-control):
> Access Control for [Pages](https://about.gitlab.com/stages-devops-lifecycle/pages/)
> allows an authorized administrator to restrict access to a Pages site or
> make it available to the public. Now, content published by your private
> projects can require sign in to protect the contents of the published site,
> making it easier to publish and control access to internal documentation.
>
> Please check out a short video that highlights [Access Control for
> Pages](https://www.youtube.com/embed/tSPAr5mQYc8).
Pages[Notifications for Releases](https://docs.gitlab.com/ee/user/profile/notifications.html):
> You can now subscribe to updates about new releases in a project, so
> that you will be notified about new versions, even for projects you are
> not part of. This can be used to stay up to date on new releases from
> projects that you depend on, without having to check-in manually.
>
> Please check out a short video that highlights [Notifications for
> Releases](https://www.youtube.com/embed/qyeNkGgqmH4).
Release Orchestration[Enable "Cloud Run on GKE" When Creating a Cluster via GKE Integration](https://docs.gitlab.com/ee/user/project/clusters/#cloud-run-on-gke)
> When creating a Kubernetes cluster via GitLab's GKE integration, users
> can now optionally enable "Cloud Run on GKE" with a single click. GKE
> will automatically provision the cluster with Knative serving, Istio,
> and HTTP load balancing. When installed, users can continue to take
> advantage of the features offered by [GitLab
> Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
> to deploy Knative services with minimal configuration.
>
> Note: Cloud Run for GKE has recently been rebranded as "Cloud Run for
> Anthos". We plan to update the name of this feature with Google's
> updated branding in next month's release.
[Check for Existence of Files in Pipelines](https://docs.gitlab.com/ee/ci/yaml/#rulesexists):
> Adding to the `rules:` syntax [initially introduced in GitLab 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#flexible-rules-keyword-for-controlling-pipeline-behaviors),
> the new `rules:exists` rule is able to accept an array of paths and will
> match if any of these paths exist as files in the repository.
> This is useful in cases where you want to run a CI job only if a certain
> file exists. For example, only run the `tests` pipeline when the file
> `tests.yml` exists. Use of this rule can help speed up pipelines by
> skipping stages with no match.
Continuous Integration[Use VPC Native Setting by Default When Creating GKE Cluster in GitLab](https://docs.gitlab.com/ee/user/project/clusters/#add-new-gke-cluster)
> Google Kubernetes Engine provides the ability to create
> [VPC-native](https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips)
> clusters, which rely on Alias IPs and provide integrated VPC support for
> container networking, resulting in a more scalable, secure, and simple
> system that is suited for demanding enterprise deployments and use
> cases.
>
> Starting with GitLab 12.4, GitLab's GKE integration will enable this
> option by default when creating a GKE cluster.
[API for Manually Creating Deployments](https://docs.gitlab.com/ee/api/deployments.html#create-a-deployment):
> We have added API functionality that will allow for creating
> deployments. This also changes deployments so that the associated CI
> build is optional. This is needed to lay the foundation to support
> external environments and deployments to GitLab.
Continuous Delivery[Enrich Environment and Deployment API](https://docs.gitlab.com/ee/api/environments.html):
> We have added API functionality that will return the `state` and `last
> deployment` attributes of environments. An example use of that
> information is to write a script to delete unused environments.
Review Apps[Upgraded Kubernetes NGINX Ingress Application when Installed via Kubernetes Integration](https://docs.gitlab.com/ee/user/clusters/applications.html#ingress)
> Keeping your Kubernetes-deployed apps running on the latest version
> ensures you have the newest features as well as up-to-date security.
> GitLab 12.4 allows you to use the latest NGINX Ingress application when
> [installing it](https://docs.gitlab.com/ee/user/clusters/applications.html#installing-applications)
> using GitLab Managed Apps. To upgrade an existing version,
> [uninstall](https://docs.gitlab.com/ee/user/clusters/applications.html#uninstalling-applications)
> and reinstall the Ingress application using GitLab.
[S/MIME is now configurable in the GitLab Helm chart](https://docs.gitlab.com/charts/installation/secrets.html#smime-certificate) (self-managed only)
> Sending emails with an S/MIME signature improves security by reducing
> the surface area for phishing, man-in-the-middle, and other attacks.
> While the ability to sign notification emails with S/MIME was [added to
> Omnibus in
> 12.3](/releases/2019/09/22/gitlab-12-3-released/#smime-email-signing), it
> wasn't possible to configure S/MIME when installing GitLab on
> Kubernetes. Now, in 12.4, S/MIME parameters for GitLab email
> notifications can be configured as a global setting for the [GitLab helm
> chart](https://docs.gitlab.com/charts/).
[Upgraded Kubernetes Cert-Manager Application When Installed via Kubernetes Integration](https://docs.gitlab.com/ee/user/clusters/applications.html#cert-manager)
> Keeping security certificates for your Kubernetes-deployed apps updated
> ensures your applications are securely served without interruption.
> Starting with GitLab 12.4 you can now upgrade your Cert-Manager
> application using the GitLab Kubernetes integration. To upgrade to the
> latest GitLab-supported version, navigate to the cluster page from
> **Operations > Kubernetes**, then uninstall and reinstall Cert-Manager.
[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)
> - GitLab 12.4 includes Mattermost 5.15, an [open source
> Slack-alternative](https://mattermost.com/). This version of Mattermost
> is focused on [quality
> improvements](https://docs.mattermost.com/administration/changelog.html#release-v5-15-quality-release).
> - OpenSSL has been updated to version 1.1.1d, which fixes a number of
> CVEs. For information about the changes introduced in this minor
> release, visit the [OpenSSL
> website](https://www.openssl.org/news/cl111.txt).
> - An option has been added to skip database backups during an upgrade.
> Database backups can extend the time required to complete an upgrade,
> and in some cases, you may want to skip this step so that the upgrade
> finishes quicker. For details on how to skip automatic database
> backups during upgrades, see the [Omnibus upgrade
> documentation](https://docs.gitlab.com/omnibus/update/#updating-methods).
> If you skip the automatic backups, **make sure you create your own
> before upgrading**.
[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=12.4)
> We continue to improve the performance of GitLab with every release
> for GitLab instances of every size.
>
> Some of the improvements in GitLab 12.4 are:
>
> - [Limit the number of commits on commentable items to 5,000](https://gitlab.com/gitlab-org/gitlab/merge_requests/18111)
> - [Ensure cache headers for avatars are set correctly when using object storage and proxied downloads](https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/428)
> - [Speed up Jira DVCS API for Jira Server](https://gitlab.com/gitlab-org/gitlab/merge_requests/18329)
> - [Prevent certain email autoresponders from adding comments to issues](https://gitlab.com/gitlab-org/gitlab/merge_requests/18118)
> - [Restrict scope for Snippet Searches](https://gitlab.com/gitlab-org/gitlab/merge_requests/17625)
> - [Limit the search count query for Snippets](https://gitlab.com/gitlab-org/gitlab/merge_requests/17585)
> - [Add Trigram Index on Snippet Content](https://gitlab.com/gitlab-org/gitlab/merge_requests/17806)
> - [Improve load time for markdown renderer significantly](https://gitlab.com/gitlab-org/gitlab/merge_requests/16824)
[Multi-Select & Move Issue Cards](https://docs.gitlab.com/ee/user/project/issue_board.html#multi-select-issue-cards):
> Sometimes, it's the little things that matter. Whether you're kicking
> off your next sprint or you just like to pass the time dragging and
> dropping on Issue Boards, you'll be happy to know that you can now
> multi-select issue cards via `Cmd` + `click` on a Mac or `Ctrl` +
> `click` on Windows to move them all at once to a different list.
Boards[Improved large file handling via Git Partial Clone (alpha)](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
> Storing large binary files in Git has typically been discouraged to
> prevent the repository growing too large, making cloning and fetching
> changes very slow. Solutions like Git LFS have provided a workaround
> by storing large files outside the Git repository, and downloading
> large files on demand.
>
> In GitLab 12.4, we are adding experimental support for Partial Clone,
> which allows large files to be excluded when cloning a repository and
> fetching updates. This removes the need to choose which files should
> be stored in Git and which files should be stored outside the
> repository using Git LFS. Partial Clone support is disabled by
> default, but can be enabled per project, and requires at least Git
> 2.22.0.
>
> In comparison with Git LFS, instead of requiring large files to be
> specially handled when authoring the commit, Partial Clone allows
> developers, CI runners, or any other Git client to specify which files
> they want to download. This removes the need to teach people which
> files should go in Git LFS, avoids the problems of trying to rewrite
> history to migrate large files to Git LFS, and bypasses the
> frustrations caused by someone accidentally pushing an large file to
> the Git repository when it should have gone to Git LFS. Simply, large
> files should just work.
[Admin Override of Artifacts Size per Project/Group](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#maximum-artifacts-size) (self-managed only):
> Currently, the artifacts size is set to 100MB by default but some
> projects need the ability to go over these limits, subject to the
> discretion of the administrator. To enable this, we've added an option
> in group and project settings to override the global artifacts size
> limit, similar to how the repository size limit can be customized.
Continuous Integration[Private Project Support for Online View of HTML Artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts):
> Viewing HTML artifacts in a browser window is a key efficiency
> workflow. Because of how frequently this task is performed, being able
> to quickly go from browsing your artifacts to opening and reviewing them
> is important. Without an online view, you need to download the artifact
> and spin up a webserver locally to view the report. Doing this for every
> HTML artifact for all of your builds can become an intrusive time-sink
> that interrupts the flow of work with continual context-switching.
>
> Previously, it was possible to view HTML artifacts in a browser window
> using GitLab Pages instead of downloading them locally, but this
> capability was limited to public projects only. This was a problem for
> many businesses and organizations that use GitLab predominantly with
> private projects - an online view was simply not available to them. Now
> thanks to a wonderful community contribution from [Tuomo
> Ala-Vannesluoma](https://gitlab.com/tuomoa), we have added support for
> online view of HTML artifacts to private projects
> as well. Note that this requires enabling [access control for GitLab
> Pages](https://docs.gitlab.com/ee/user/project/pages/introduction.html#gitlab-pages-access-control)
> to work correctly.
Continuous Integration[One-click Install for Group Runner on Kubernetes](https://docs.gitlab.com/ee/user/group/clusters/):
> It's now easier than ever to create a shared Runner at the group level
> if you're using GitLab with Kubernetes. The ability to one-click install
> a Runner at the project level has been available for a while, but group
> Runners still needed to be installed manually. Now, you can simply click
> a button and GitLab will install a shared group Runner for you.
Continuous Integration, Groups[MR links are now shown on Pipeline view](https://docs.gitlab.com/ee/ci/pipelines/index.html#visualize-pipelines):
> When viewing a pipeline, it can be helpful to be able to navigate to the
> merge request(s) associated with that pipeline. We've added links
> directly to the related merge requests to make this simpler and more
> efficient.
Continuous Integration[Insert jobs at beginning or end of pipeline via include](https://docs.gitlab.com/ee/ci/yaml/#stage-pre):
> A common use case for includes is to add a job at the beginning or end
> of a pipeline. However, as the author of a shared include, you don't
> necessarily know what the first or last stages will be called. This
> makes it difficult and error prone to try to write a job that runs at
> the start or end of a pipeline.
>
> In GitLab 12.4, `.pre` and `.post` pipeline stages that
> are guaranteed to run at the beginning or end of a pipeline to make this
> easier are available.
Continuous Integration[GitLab Runner 12.4](https://docs.gitlab.com/runner/)
> We're also releasing GitLab Runner 12.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.
>
> #### Changes include:
>
> * [Extend custom executor configuration](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1583).
> * [Use `certutil` to create a certificate chain for Git](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1581).
> * [Bump used Go version to 1.10.8](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1617).
> * [Update Kubernetes client library to 11.0](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1615).
> * [Add timeout when waiting for the build to finish](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1609).
>
> The list of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v12.4.0/CHANGELOG.md).