features:
# TOP FEATURE
  top:
    - name: "Merge Request Dependencies"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_dependencies.html'
      image_url: '/images/12_4/mr-dependencies.png'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13177'
      categories:
        - 'Source Code Management'
      description: |
        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](/blog/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. 

# PRIMARY FEATURES
  primary:
    - name: "Audit Events API"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/api/audit_events'
      image_url: '/images/12_4/audit-events-api-docs.png'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/121'
      categories:
        - 'Audit Management'
      description: |
        [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.

    - name: "Code Owner Approvals for Protected Branches"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches-approval-by-code-owners-premium'
      image_url: '/images/12_4/protected-branches.png'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13251'
      description: |
        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.

    - name: "Access Control for Pages is now enabled on GitLab.com"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/pages/#access-control'
      image_url: '/images/12_4/gitlab_pages_access.png'
      reporter: ogolowinski
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/25362'
      categories:
        - 'Pages'
      description: |
        Access Control for [Pages](https://about.gitlab.com/product/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).

    - name: "Notifications for Releases"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/profile/notifications.html'
      image_url: '/images/12_4/notification_global_settings.png'
      reporter: ogolowinski
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26001'
      categories:
        - 'Release Orchestration'
      description: |
        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).

    - name: "View Pod Logs from Any Environment"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/kubernetes_pod_logs.html'
      image_url: '/images/12_4/Showpodlogs-opt.gif'
      reporter: dhershkovitch
      stage: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/5769'
      categories:
        - 'Logging'
      description: |
        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.

# SECONDARY FEATURES
  secondary:
    - name: "Use Jaeger in the GitLab UI"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/operations/tracing.html#jaeger-tracing'
      image_url: '/images/12_4/Jaeger-integration.png'
      reporter: dhershkovitch
      stage: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/30525'
      description: |
        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.

    - name: "Admin Override of Artifacts Size per Project/Group"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#maximum-artifacts-size-core-only'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/21688'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Variable Expansion Support for Multi-project Pipelines"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#specifying-a-downstream-pipeline-branch'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/10126'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Private Project Support for Online View of HTML Artifacts"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/pipelines/job_artifacts.html#browsing-artifacts'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/14897'
      categories:
        - 'Continuous Integration'
      description: |
        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-core)
        to work correctly.

    - name: "DAST for the Master Branch"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dast/'
      reporter: matt_wilson
      stage: secure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/5503'
      categories:
        - 'Auto DevOps'
      description: |
        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.

    - name: "Enable \"Cloud Run on GKE\" When Creating a Cluster via GKE Integration"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#cloud-run-on-gke'
      image_url: '/images/12_4/cloud_run_v12_4.png'
      reporter: nagyv.gitlab
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/27502'
      description: |
        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.

    - name: "Check for Existence of Files in Pipelines"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#rulesexists'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/24021'
      categories:
        - 'Continuous Integration'
      description: |
        Adding to the `rules:` syntax [initially introduced in GitLab 12.3](https://about.gitlab.com/blog/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.

    - name: "Generic Alert Endpoint MVC"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/generic_alerts.html'
      image_url: '/images/12_4/alert_endpoint.png'
      reporter: sarahwaldner
      stage: monitor
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13203/'
      categories:
        - 'Incident Management'
      description: |
        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).

    - name: "Native Geo Support for Object Storage Replication"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication'
      reporter: fzimmer
      gitlab_com: false
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/10586'
      description: |
        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/#beta) and is not
        ready yet for production use.

    - name: "Geo Supports Using a Single, Location-aware Git URL"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/location_aware_git_url.html'
      reporter: fzimmer
      gitlab_com: false
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      issue_url: 'https://gitlab.com/groups/gitlab-org/-/epics/2038'
      description: |
        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/).

    - name: "Improved large file handling via Git Partial Clone (alpha)"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/topics/git/partial_clone.html'
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitaly/issues/1553'
      description: |
        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.

    - name: "Git Activity added to Group IP Address Restriction"
      available_in: [ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/#ip-access-restriction-ultimate'
      reporter: jeremy
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/32113'
      categories:
        - 'Groups'
      description: |
        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.

    - name: "Date Picker for Productivity Analytics"
      available_in: [premium, ultimate]
      gitlab_com: true
      documentation_link: 'https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html'
      image_url: '/images/12_4/datepicker.png'
      reporter: valexieva
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13188'
      categories:
        - 'Value Stream Management'
      description: |
        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.

    - name: "Scatterplot for Productivity Analytics"
      available_in: [premium, ultimate]
      gitlab_com: true
      documentation_link: 'https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html'
      image_url: '/images/12_4/scatterPA.png'
      reporter: valexieva
      stage: manage
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13412'
      categories:
        - 'Value Stream Management'
      description: |
        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.

    - name: "Use VPC Native Setting by Default When Creating GKE Cluster in GitLab"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/clusters/#add-new-gke-cluster'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/25925'
      description: |
        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.

    - name: "API for Manually Creating Deployments"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/deployments.html#create-a-deployment'
      reporter: ogolowinski
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/32579'
      categories:
        - 'Continuous Delivery'
      description: |
        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.

    - name: "Restrict Permissions for Manual CI Jobs"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/README.html#protecting-manual-jobs-premium'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/15819'
      categories:
        - 'Continuous Integration'
      description: |
        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/yaml/README.html#protecting-manual-jobs-premium)
        to make it more clear how to get this set up.

    - name: "One-click Install for Group Runner on Kubernetes"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/group/clusters/'
      image_url: '/images/12_4/k8s_group_runner.png'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/29706'
      categories:
        - 'Continuous Integration'
        - 'Groups'
      description: |
        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.

    - name: "Delete Designs in Design Management"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/design_management.html#deleting-designs'
      image_url: '/images/12_4/design-management-delete-design.gif'
      reporter: phikai
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/11089'
      categories:
        - 'Design Management'
      description: |
        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.

    - name: "Design Management System Notes"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issues/design_management.html'
      image_url: '/images/12_4/design-management-system-notes.png'
      reporter: phikai
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/12528'
      categories:
        - 'Design Management'
      description: |
        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.

    - name: "Enrich Environment and Deployment API"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/environments.html'
      reporter: ogolowinski
      stage: release
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/5582'
      categories:
        - 'Review Apps'
      description: |
        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.

    - name: "GitHub Integration Default to Static Status Check Names"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/integrations/github.html#static--dynamic-status-check-names'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/9931'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Improved Geo Upgrade Documentation"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html'
      reporter: fzimmer
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      gitlab_com: false
      issue_url: 'https://gitlab.com/groups/gitlab-org/-/epics/1935'
      description: |
        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.

    - name: "Multi-Select & Move Issue Cards"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/project/issue_board.html#multi-select-issue-cards'
      reporter: gweaver
      stage: plan
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/18954'
      categories:
        - 'Issue Boards'
      description: |
        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.

    - name: "MR links are now shown on Pipeline view"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/ci/pipelines.html#visualizing-pipelines'
      image_url: '/images/12_4/merge_requests_pipeline_view.png'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/26909'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Sort Packages in the Registry UI"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/packages/'
      image_url: '/images/12_4/sort_packages.png'
      reporter: trizzi
      stage: package
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/13536'
      categories:
        - 'Package Registry'
      description: |
        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).

    - name: "Insert jobs at beginning or end of pipeline via include"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/README.html#pre-and-post"
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/31441'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Global View for Instance-level Cluster Deployments/Environments"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/clusters/environments.html'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/14809'
      description: |
        The **Environments** view was [introduced in GitLab
        12.3](https://about.gitlab.com/blog/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.

    - name: "Upgraded Kubernetes NGINX Ingress Application when Installed via Kubernetes Integration"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/clusters/applications.html#ingress'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/28492'
      description: |
        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.

    - name: "S/MIME is now configurable in the GitLab Helm chart"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/charts/installation/secrets.html#smime-certificate'
      reporter: ljlane
      issue_url: 'https://gitlab.com/gitlab-org/charts/gitlab/issues/1533'
      description: |
        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](/blog/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/).

    - name: "API Endpoint for 'Static Status Check Names' in GitHub Integration"
      available_in: [premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/api/services#github-premium'
      reporter: jyavorska
      stage: verify
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/8477'
      categories:
        - 'Continuous Integration'
      description: |
        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.

    - name: "Upgraded Kubernetes Cert-Manager Application When Installed via Kubernetes Integration"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/ee/user/clusters/applications.html#cert-manager'
      reporter: danielgruesso
      stage: configure
      issue_url: 'https://gitlab.com/gitlab-org/gitlab/issues/28033'
      description: |
        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.

    - name: "GitLab Runner 12.4"
      available_in: [core, starter, premium, ultimate]
      documentation_link: 'https://docs.gitlab.com/runner/'
      documentation_text: "Read through the documentation of GitLab Runner"
      stage: verify
      description: |
        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).

# Omnibus and performance (required)
    - name: "Omnibus improvements"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: 'https://docs.gitlab.com/omnibus/'
      reporter: pm1 # required
      description: |
        - 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**.
    
    - name: "Performance improvements"
      available_in: [core, starter, premium, ultimate]
      performance_url: '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'
      reporter: multiple
      description: |
        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)

# EXTRAS (Optional)
# extras:
#  - title: "Hello World"
#    description: | # supports markdown
#     Lorem ipsum dolor sit amet, consectetur adipisicing elit. Consequuntur, beatae!

# MVP
mvp:
  fullname: "Tuomo Ala-Vannesluoma"
  gitlab: tuomoa
  description: |
    Tuomo's contribution to GitLab 12.4 enabled [private project support for
    viewing HTML
    artifacts](#private-project-support-for-online-view-of-html-artifacts), a
    highly requested feature with almost 300 upvotes! This is Tuomo's second MVP,
    their first was [in GitLab
    11.5](https://about.gitlab.com/blog/2018/11/22/gitlab-11-5-released/#mvp)
    where they implemented [Access control for
    Pages](https://about.gitlab.com/blog/2018/11/22/gitlab-11-5-released/#access-control-for-pages).
    Thank you for your contributions and for engaging with us over the last year
    - we truly appreciate it!

# COVER IMAGE LICENCE
cover_img:
  image_url: 'https://unsplash.com/photos/O6N9RV2rzX8'
  licence: Free
  licence_url: 'https://unsplash.com/license'

# CTA BUTTONS (optional)
# Tip: You can add more than one.
cta:
  - title: "Join us for an upcoming event"
    link: '/events/'

# UPGRADE WARNING (optional)
# https://about.gitlab.com/handbook/marketing/blog/release-posts/#important-notes-on-upgrading
upgrade:
  reporter: nagyv.gitlab
  description: |
    - GitLab 12.4 now installs Knative 0.7 as a [GitLab Managed
    App](https://docs.gitlab.com/ee/user/clusters/applications.html#knative).
    Note: GitLab Serverless is still in alpha. If you run into issues with
    previous Knative versions, please reach out to the GitLab support.

    - Starting with GitLab 12.4, the Kubernetes integration will install
    Cert-Manager v0.9.1. If you installed Cert-Manager via the Kubernetes
    integration previously, then you will be on an older version. [Older
    versions will be blocked by Let's
    Encrypt](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
    starting November 1st, 2019. See more info on the
    [Cert-Manager](#cert-manager) deprecation notice.
    GitLab 12.3 upgrades Cert-Manager to v0.9.1 when installing it through the
    Kubernetes integration. If you are using an older version of Cert-Manager
    (installed through the Kubernetes integration) you will need to uninstall
    the old version and install the latest version as [older versions will be
    blocked by Let's
    Encrypt](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
    starting November 1st, 2019. See more info on the
    [Cert-Manager](#cert-manager) deprecation notice.

    - To help with the larger migrations [we have introduced background
    migrations](https://gitlab.com/gitlab-org/gitlab/merge_requests/17993) for
    this release. Background migrations are Sidekiq jobs that will run
    asynchronously. For GitLab.com these migrations took around 36 hours to
    complete, and no side effects were expected nor present. To find the
    approximate time (in hours) it will take to complete these migrations on your instance
    run the following command from a Rails console: `(Project.count.to_f /
    300_000).ceil`. You can check the status of background migrations by running
    this command from a Rails console:
    `Sidekiq::Queue.new('background_migration').size`.

# DEPRECATIONS (optional)
# include as many deprecation blocks as necessary
deprecations:
  - feature_name: "Versions of Cert-Manager prior to 0.8.0 will be blocked by Let's Encrypt starting Nov. 1st"
    due: Nov. 1, 2019
    reporter: danielgruesso
    description: |
      Prior to GitLab 12.4, the Kubernetes integration provided users the option
      to install Cert-Manager v0.5.2 onto their Kubernetes cluster. Let’s
      Encrypt will [block requests from versions of Cert-Manager less than
      0.8.0](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
      starting on November 1st, 2019. To resolve this, users must uninstall
      Cert-Manager then install Cert-Manager again. You should consider [backing
      up](https://docs.cert-manager.io/en/latest/tasks/backup-restore-crds.html)
      any additional configuration prior to upgrading in the event of data loss.
  - feature_name: "Move protected paths configuration from `gitlab.rb` to the GitLab UI"
    due: GitLab 13.0
    reporter: ljlane
    description: |
      The configuration of protected paths has been moved to the GitLab UI so
      that there is a single place to configure all settings related to
      throttling. Previously, user and IP limits were set in the UI, and
      protected paths were set in `/etc/gitlab/gitlab.rb`. Configuring protected
      paths in `gitlab.rb` has been deprecated in GitLab 12.4 and is scheduled
      for removal in GitLab 13.0. For details on how to configure protected
      paths in the UI, and migrating protected path throttles from Omnibus
      GitLab 12.3 (or earlier) to the UI, see the [protected paths
      documentation](https://docs.gitlab.com/ee/user/admin_area/settings/protected_paths.html).
  - feature_name: "Elasticsearch 5.6 will no longer be supported"
    due: January 22, 2020
    reporter: phikai
    description: |
      As we continue to improve and enhance our integration with Elasticsearch,
      support for Elasticsearch 5.6.x will end with the release of GitLab 12.7.
      Elasticsearch 5.6 has also reached its [end of
      life](https://www.elastic.co/support/eol) with the release of
      Elasticsearch 7.x. 
      
      Updated [version
      requirements](https://docs.gitlab.com/ee/integration/elasticsearch.html#version-requirements)
      for GitLab 12.7 will include support for only Elasticsearch 6.x. At this
      time there is no timeline for support of Elasticsearch 7.x with GitLab;
      you can follow [this
      issue](https://gitlab.com/gitlab-org/gitlab/issues/11197) for updates.
      GitLab recommends self-managed customers upgrade to ElasticSearch 6.x.
  - feature_name: "Deprecating support for openSUSE Leap 15.0"
    due: GitLab 12.5
    reporter: ljlane
    description: |
      openSUSE 15.0 reaches end of life at the end of November 2019. Support for
      openSUSE 15.0 will be dropped in GitLab 12.5. [Issue
      4404](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4404) tracks the
      work to build packages for openSUSE Leap 15.1.
