features:
  top:
    - name: "Web Application Firewall for Kubernetes Ingress"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#web-application-firewall-modsecurity"
      video: "https://www.youtube.com/embed/o8-CU6TEH2w"
      reporter: stkerr
      stage: "defend"
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/25398"
      description: | # supports markdown
        GitLab now adds the `modsecurity` Web Application Firewall (WAF)
        plug-in to your cluster when you install the Ingress app in your Kubernetes
        cluster.

        The WAF is able to determine whether or not HTTP or HTTPS traffic
        to your app contains malicious code, such as SQL injection, cross-site scripting,
        or trojans. The WAF is pre-configured with a powerful set of rules, the OWASP ModSecurity Core Rules (CRS), to detect many different types of attacks out-of-the-box.

        The [documentation](https://docs.gitlab.com/ee/user/clusters/applications.html#web-application-firewall-modsecurity) describes how to view the WAF logs so
        you can see what type of malicious traffic your app is subjected to
        when it is running in production.

  primary:
    - name: 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_3/productivity_analytics.png'
      reporter: valexieva
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12079"
      description: |
        Currently there are relatively few sources of data and analytics, which can help engineering leaders understand their team, project, and group productivity. As Peter Drucker has once said, "What's measured improves". Subscribing to this view, we are releasing our first iteration of Productivity Analytics in order to help engineering leaders uncover patterns and best practices to improve overall productivity.
        The focus of this release is on the time it takes to merge MRs depending on their size. Users can make use of our existing filters and drill down to a specific author or label in a group for a specific date range.
        As we go forward and iterate on productivity analytics, we will add additional data points in order to help identify dependencies which may be contributing to increased active development and/or wait times.

        Note that in this initial release of Productivity Analytics, we have not backfilled the historical data for the newly derived metrics to ensure that this background process does not adversely impact the upgrade from 12.2 to 12.3. You're welcome to follow the issue, where we are working on that [here](https://gitlab.com/gitlab-org/gitlab/issues/32229).

    - name: "Global view for group-level cluster deployments/environments"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/environments.html"
      image_url: "/images/12_3/cluster-environments.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/13392"
      description: |
        Provisioning a group-level cluster is a great way for operators to provide an application
        development platform for developers. Scaling cluster resources can be challenging and
        requires a global view of resource usage. The new "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: "Leverage merge request approvals to prevent merging prohibited licenses MVC"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/license_compliance/#security-approvals-in-merge-requests-ultimate" # required
      image_url: '/images/12_3/merge-request-license-approval.png'
      reporter: NicoleSchwartz
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/13067"
      description: |
        If you have strict License Compliance restrictions, you may set the License Compliance feature to disallow a merge when a blacklisted license is found in a merge request. This prevents the new introduction of licenses which you have expressly prohibited. Currently you can set the approvers for the License-Check group in project settings then require the check by following the directions outlined [in the documentation](https://docs.gitlab.com/ee/user/application_security/license_compliance/#security-approvals-in-merge-requests-ultimate).

  secondary:
    - name: "Analytics Workspace"
      available_in: [core, starter, premium, ultimate]
      documentation_link: https://docs.gitlab.com/ee/user/analytics/index.html
      image_url: '/images/12_3/analytics_workspace.png'
      reporter: valexieva
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12077"
      description: |
        Engineering and product teams can span multiple GitLab groups and projects, yet most of our analytics have traditionally been developed at the project level. This is why we created a workspace where users can aggregate insights across groups, subgroups, and projects.
        The Analytics workspace will make it easier for teams and leaders to analyze and manage team metrics. The workspace will be available in Core.  However, in some cases, specific features will be available to Enterprise Edition customers. As we move to the Analysis workspace, we will ensure that existing project-level analytics functionality is available to Community Edition users when moved to the new workspace.
        In GitLab 12.3, we are releasing the first iteration of group and project level Productivity Analytics and group-level Cycle Analytics. In subsequent releases, we will enable the selection of multiple groups and subgroups; porting all analytics features for an instance.  We would love your feedback and input on the strategy for [Analytics/Value Stream Management](https://about.gitlab.com/direction/manage/value_stream_management/)

    - name: "Design Management status and discussion counts"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/design_management.html"
      image_url: "/images/12_3/design-management-status-discussions.gif"
      reporter: phikai
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12705"
      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 the activity in each version of Designs wasn't clear to the user. Now, when designs are uploaded, status icons are added in each version to let you know if it's a new design or a change to an existing design.
        We also added discussion counts on designs to better inform users of conversations happening. We're excited about these additions to Design Management to help improve the collaboration and conversation inside of GitLab for design and engineering teams.

    - name: "Design Management notifications"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/issues/design_management.html"
      image_url: "/images/12_3/design-management-todos.png"
      reporter: phikai
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12527"
      description: |
        In GitLab 12.2 we released our initial iteration of Design Management. An important part of continuing to evolve is to ensure users are properly notified about these activities.
        Conversations in designs will now create To-Do's for mentioned users and send notifications based on their preferences. This helps to ensure that important feedback isn't missed and can be actioned. In a future release, we'll add those [conversations to the main discussion tab](https://gitlab.com/gitlab-org/gitlab/issues/11851) for an easier conversation flow.

    - name: "Compress Git ref advertisements over HTTP"
      available_in: [core, starter, premium, ultimate]
      image_url: "/images/12_3/ref-compression.png"
      reporter: jramsay
      stage: create
      issue_url: 'https://gitlab.com/gitlab-org/gitaly/issues/1733'
      description: |
        When fetching changes to a Git repository, the Git server advertises a
        list of all the branches and tags in the repository. This is called
        ref advertisement and can be many megabytes for large projects.

        In GitLab 12.3, when fetching over HTTP, the ref advertisement will be
        compressed for supported clients reducing the amount of data being
        transferred and making fetch operations faster.

        On an average weekday, GitLab.com serves about 850GB of ref
        advertisements over HTTP. After enabling ref compression, bytes
        transferred has decreased by approximately 70 percent.

    - name: "API for Merge Request Approval Rules"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/merge_request_approvals.html"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/11877"
      description: |
        Approval Rules for Merge Requests allow you to communicate who should
        participate in code reviews by specifying the eligible approvers and
        the minimum number of approvals for each. Approval rules are shown in
        the merge request widget so the next reviewer can easily be spotted.

        In GitLab 12.3, support for Approval Rules has been added to the API
        for Projects and Merge Requests.

    - name: "Audit logs for Git Push events (Beta)"
      available_in: [starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/audit_events.html"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/1411"
      description: |
        Git history can be rewritten to change commits, authors and timestamps,
        which makes it possible to craft clear and useful history for future
        developers. For audit, this is a problem.

        In GitLab 12.3, Git push events that add commits, rewrite history or
        otherwise modify the repository can be added to the audit log. Audit
        logs for push events are disabled by default to prevent performance
        degradation on GitLab instances with very high Git write traffic.

        In an upcoming release, Audit Logs for Git push events will be enabled
        by default. Follow [#7865](https://gitlab.com/gitlab-org/gitlab/issues/7865) for updates.

    - name: "Keyboard shortcut for next and previous unresolved discussion"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/shortcuts.html#issues-and-merge-requests"
      image_url: "/images/12_3/mr-next-unresolved.png"
      reporter: jramsay
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/59590"
      description: |
        Reviewing, discussing and resolving feedback is the basis of code
        review in GitLab. The **Jump to next unresolved discussion** button
        makes it easy to quickly jump from discussion to discussion.

        In GitLab 12.3, the new <kbd>n</kbd> and <kbd>p</kbd> keyboard
        shortcuts to move to the **n**ext and **p**revious unresolved
        discussions in Merge Requests make it even more convenient to review
        changes.

    - name: "Smarter Web IDE default commit options"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/web_ide/"
      image_url: "/images/12_3/webide-default-commit-options.png"
      reporter: phikai
      stage: create
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/51470"
      description: |
        Previously the Web IDE defaulted to **Commit to current branch** when making a commit. This made it easy for those with permissions to accidentally push changes to master or other protected branches. Now when making changes in the Web IDE, the default commit options are smarter to prevent making changes to the wrong branch.
        Smarter commit options prevent accidental pushes to master and protected branches for users with write access. When the user has no write access, additional details are provided as to why options are unavailable. Additionally, the new commit options also support commits to a non-default branch with or without an existing Merge Request.

    - name: "API to require merge request approval by code owners per branch"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/protected_branches.html#protected-branches-api"
      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. But not all merge requests
        target stable branches, and not all stable branches need the
        same controls.

        In GitLab 12.3, it is possible to require code owners' approval for specific
        branches (through the API) to prevent directly pushing changes to files
        with code owners, or merging changes without the code owners' approval.

        Note: This feature is only available via the API in GitLab 12.3. In GitLab 12.4
        it will be available through the Protected Branch settings. Follow issue
        [#13251](https://gitlab.com/gitlab-org/gitlab/issues/13251) for updates.

    - name: "Per-job timeouts for CI/CD pipelines"
      available_in: [core, starter, premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#timeout"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/14887"
      description: |
        Different jobs have different execution characteristics and may need different timeouts
        to be set on a per-job basis. Timeouts can be configured by adding the `timeout:` keyword to your job in `.gitlab-ci.yml`, along with a number to indicate the number of minutes to wait before the job fails.
        
        Thanks to [Michal Siwek](https://gitlab.com/skycocker) for the contribution.

    - name: "Flexible 'rules' keyword for controlling pipeline behaviors"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#rules"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/27863"
      description: |
        `Only/except` rules in pipelines can have a lot of implicit behaviors, and
        as more and more are added to your pipelines, it can become very difficult to
        understand if a given job is going to run or not in different situations. We are
        introducing a new `rules:` syntax that will make it much easier to implement and
        understand complex rules. This syntax is optional and can exist in the same pipeline,
        but not the same jobs, as the current `only/except` approach.

    - name: "'interruptible' keyword to indicate if a job can be safely canceled"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/yaml/#interruptible"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/32022"
      description: |
        The new `interruptible` keyword can be used to indicate whether or not a job should be canceled
        if made redundant by a newer run of the same job. The keyword defaults to `false`, so it should
        be used to specify jobs that are safe to stop. This value will only be used if the [automatic cancellation of redundant pipelines](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#auto-cancel-pending-pipelines)
        feature is enabled.

        This helps avoid duplication of unnecessary jobs across your pipelines, reducing
        costs and making your pipelines more efficient.

        Due to a [bug in the Runner](https://gitlab.com/gitlab-org/gitlab-runner/issues/3376), some executors do not stop in-progress jobs when cancelled. This is planned to be fixed in 12.4.
        {: .alert .alert-info}

    - name: "'only/except: external_pull_requests' for external repositories"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/#pipelines-for-external-pull-requests"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/65139"
      description: |
        GitLab CI has an "external repos" capability intended to allow customers to use external repos for source
        control and GitLab for CI/CD. Until now, however, the `CI_PIPELINE_SOURCE` always showed `push` because it
        was based on the pull mirror rather than the source external repo or webhook. This prevented GitLab
        us from correctly supporting `only/except: merge_requests`-style options. In the 12.3 release
        we've resolved this limitation.

    - name: "Status checking for pipeline triggers"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#mirroring-status-from-triggered-pipeline"
      reporter: jyavorska
      stage: verify
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/11238/"
      description: |
        We've recently improved the way cross-project pipelines can trigger
        each other, but one thing still missing was having the triggering pipeline
        wait or confirm success of the triggered pipeline. It was possible using
        API polling, but in this release we've introduced the `depends` and `wait`
        strategies where this can be handled automatically for you. If you are triggering
        a pipeline you want to `depend` on, it will wait for the pipeline to complete
        and will verify it succeeds before finishing the triggering job. If you choose
        `wait`, it will wait for it to finish but proceed regardless of pass/fail status.

    - name: "Remove container images from CI/CD"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/container_registry.html"
      image_url: "/images/12_3/delete_images.png"
      reporter: trizzi
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/40096/"
      description: |
        The GitLab Container Registry allows users to leverage GitLab CI/CD to build and push images/tags to their project. Changes to the Container Registry are made by a service account called "CI Registry User" that is invoked from `.gitlab-ci.yml` with the predefined environment variable `CI_REGISTRY_USER`. Previously, this service account could push new tags to the registry, but it lacked permissions to untag images. This prevented branch-specific images from being removed, resulting in additional storage costs and creating difficulty when navigating the registry user interface due to the large number of additional, unneeded tags.

        In 12.3 we have expanded the permissions of `CI_REGISTRY_USER` to allow for untagging of images so you can clean up branch-specific tags as part of your regular CI/CD workflow and use GitLab CI/CD to automate your cleanup scripts. This issue is part of a larger epic to [lower the cost of the Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/434) by improving storage management.

    - name: "API endpoint to list the Docker images/tags of a group"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/api/container_registry.html#within-a-group"
      reporter: trizzi
      stage: package
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/26866"
      description: |
        The GitLab Container Registry allows users to build and push Docker images/tags to their project from the command line, CI/CD, or from an API. However, until GitLab 12.3 we did not offer any visibility into images/tags at the group level, a popular request from users.

        We have added two API endpoints that will give visibility into which images and tags exist at the group level. This is the first step in helping improve visibility and discoverability for the Container Registry. Next, we'll leverage the API to create a [group-level browser](https://gitlab.com/gitlab-org/gitlab-ce/issues/49336) as part of the Container Registry user interface.

    - name: "Validate domains when performing full DAST active scans"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/dast/#domain-validation"
      reporter: stkerr
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/11301"
      description: |
        You can now ensure DAST only performs active scans against
        domains which are intentionally configured for DAST scanning.

        This helps to ensure that DAST active scans are not
        unintentionally run against domains which could be serving content
        or being used in a production capacity.

        There is no change to passive DAST scans, since passive scanning
        does not potentially negatively impact scanned sites.

    - name: "SAST scanning without Docker-in-Docker"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/sast/index.html"
      reporter: stkerr
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/10796"
      description: |
          SAST scans can now optionally be done without using Docker-in-Docker.

          This means SAST scanning can be configured to not need elevated
          privileges.

    - name: "SAST Spotbugs analyzer updated for Java 11"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/sast/#analyzer-settings"
      reporter: stkerr
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/9998"
      description: |
        The SAST SpotBugs analyzer has been updated to allow scanning of code
        written with Java 11.

        You can enable this by setting the `SAST_JAVA_VERSION` environment
        variable in your project.

    - name: "Edit vulnerability dismissal reasons"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/application_security/#dismissing-a-vulnerability"
      image_url: "/images/12_3/dismissal-comment.gif"
      reporter: stkerr
      stage: secure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/11721"
      description: |
        Vulnerability dismissal reasons can now be edited and deleted.

        This allows you to add and update context for a vulnerability as you
        learn more over time.

    - name: "Run Pipeline button for Merge Request Pipelines"
      available_in: [premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/ci/merge_request_pipelines/"
      reporter: ogolowinski
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/65940"
      description: |
        [Pipelines for merge requests](https://docs.gitlab.com/ee/ci/merge_request_pipelines/) recently introduced a
        new way to run a pipeline in the context of a merge request, but the only
        way to trigger a new run of one of these pipelines was through a push. In this release we've added a button
        to start a new pipeline, making it much easier to retry a failed pipeline.

    - name: "Improve Pages initial setup experience"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/pages/"
      image_url: "/images/12_3/load_time_banner.png"
      reporter: ogolowinski
      stage: release
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/65304"
      description: |
       To improve the Pages user experience, we added a banner that notifies users of the possible initial setup time. We understand it can be frustrating to see the "Congratulations" message without the page being available. The banner helps make it more clear what to expect.

    - name: "User-defined CI variables available to docker build with Auto DevOps"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/topics/autodevops/#passing-secrets-to-docker-build-beta/"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/25514"
      description: |
        CI variables allow you to tailor how processes are run to build your application as part of your CI pipeline. Starting in GitLab 12.3, you can extend the availability of user-defined CI variables to the `docker build` step in Auto DevOps. The data is made available as a new `build secret` value.

        List one or more variables using the `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`
        variable and it will be made available to use in `docker build`.

    - name: "Show Kubernetes cluster used for deployment"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/clusters/#deploying-to-a-kubernetes-cluster"
      image_url: "/images/12_3/jobs-cluster.png"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/25682/"
      description: |
        The jobs detail page now displays the name of the Kubernetes cluster that was used for the
        given deployment. Project owners and maintainers are presented with a link on the cluster name
        which will link directly to the cluster details page.

    - name: "Knative for group and instance-level clusters"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#knative"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/29180"
      description: |
        Group and instance-level clusters now support the installation of [Knative](https://knative.dev/),
        the Kubernetes-based platform to deploy and manage serverless workloads. This will allow multiple projects
        to make use of [GitLab Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/)
        features leveraging a single cluster.

    - name: "JupyterHub for group-level Kubernetes clusters"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/clusters/applications.html#jupyterhub"
      reporter: danielgruesso
      stage: configure
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/51989"
      description: |
        Group-level clusters now support the installation of [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/),
        a multi-user service for easily launching notebooks as well as creating
        [runbooks](https://docs.gitlab.com/ee/user/project/clusters/runbooks/) for operators. This extends the availability
        of JupyterHub to both project-level and group-level clusters.

    - name: "Line charts for metrics dashboard"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#defining-custom-dashboards-per-project"
      image_url: "/images/12_3/Metrics_Line_chart.png"
      reporter: dhershkovitch
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/65412"
      description: |
        When it comes to visualizing metrics, oftentimes users would like to choose different types of visualization for specific metrics (e.g., line chart for CPU, area chart for disk space). To help achieve this, we added line charts as a part of our effort to enhance our dashboard offering around monitoring.

    - name: "Close issue via slash command in Slack"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/integration/slash_commands.html"
      image_url: "/images/12_3/close_issue_slash_command.png"
      reporter: sarahwaldner
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab-ce/issues/64830"
      description: |
        Chat tools are required during fire-fights to resolve modern IT incidents. This tool needs to be closely integrated
        with the systems you are managing and the tools where you will actually perform remediation. As much as possible, you
        want to minimize context and tool switching while you're working to restore services and update your external stakeholders.

        In 12.3, we have added an additional slash command to the suite of commands we offer with our ChatOps product based on Slack.
        Issues can now be closed from Slack without needing to switch tools, just locate the issue in question, and manually close it.
        You can close it from where you are working.

    - name: "Quick actions to add/remove Zoom meetings on issues"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics" # required
      image_url: "/images/12_3/quick-actions-zoom-meeting.png"
      reporter: sarahwaldner
      stage: monitor
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/31103"
      description: |
        Synchronous collaboration is a critical part of any fire-fight.
        We are streamlining the number of steps it takes to spin up a conference bridge
        and engage all required parties by embedding this functionality, using Zoom, directly
        in an issue.

        Once a user has started a Zoom meeting, they can attach it to an issue using a quick action
        and inputting the Zoom meeting URL (e.g. `/zoom https://gitlab.zoom.us/s/123456`). A button will appear at the top of the issue giving users
        direct access to the conference bridge. When the incident has resolved, the Zoom meeting can be
        removed using `/remove_zoom`.

        This feature is generally available on GitLab.com and feature flagged for use on self-managed instances. If you are interested in taking advantage of this feature for your self-managed instance of GitLab, operators can enable the `issue_zoom_integration` feature flag. In next month's release of GitLab 12.4 we plan to [remove the feature flag](https://gitlab.com/gitlab-org/gitlab/issues/32133) and make the Zoom Issue integration generally available for all self-managed users. 

    - name: "Geo natively supports Docker Registry replication"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/ee/administration/geo/replication/docker_registry.html" # webpage or documentation - required
      reporter: fzimmer
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/2870"
      description: |
        Geo natively supports replicating a [Docker Registry](https://docs.docker.com/registry/)
        between primary and secondary Geo nodes. This allows Geo users to use a Docker Registry on a close-by secondary node. This approach is storage-agnostic and can be used
        for object storage, such as S3, or local storage.

        When using distributed object storage (e.g. S3) for a Docker Registry, the primary
        and secondary Geo nodes can use the same storage type. This approach does not rely on Geo's native replication ability.


    - name: "Geo displays secondary lag when pushing via Git HTTP"
      available_in: [premium, ultimate]
      gitlab_com: false
      documentation_link: "https://docs.gitlab.com/ee/administration/geo/replication/#how-it-works"
      reporter: fzimmer
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/9195"
      description: |
        Fetching large amounts of data can take a long time for users in remote locations.
        Replicating repositories with Geo reduces the time it takes to clone and fetch large repositories
        by creating read-only secondary nodes near remote user. Because secondary nodes lag behind
        the primary node, GitLab now provides an estimate of replication lag whenever `git push` is used over HTTP. This raises the visibility of using a Geo node and allows users to detect increases in replication lag and report them to systems administrators.

        Because of protocol limitations, this message is not available when using `git pull`.

    - name: "API activity included in IP address group restriction"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/#ip-access-restriction-ultimate-only"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12874"
      description: |
        GitLab 12.0 saw the introduction of [restricting a group's activity by IP address](https://gitlab.com/gitlab-org/gitlab/issues/1985). We've iterated on this feature to also include API activity, where incoming requests will be rejected if they do not adhere to the group's restriction. This solves an important problem for compliance-minded enterprises with an extended approach to access control, covering both UI and API activity.

    - name: "Disable 2FA for selected OAuth providers"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/integration/omniauth.html#bypassing-two-factor-authentication"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/issues/56059"
      description: |
        Organizations using enforced [two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) and an [identity provider also using 2FA](https://docs.gitlab.com/ee/integration/omniauth.html#supported-providers) may find the requirement to authenticate twice frustrating. Thanks to a community contribution, you're now able to bypass 2FA for selected OAuth identity providers in GitLab. For those using providers that handle 2FA, this makes logging into GitLab a friendlier and easier experience.

        Thanks to [dodocat](https://gitlab.com/dodocat) for the contribution!

    - name: "System hooks for project and group member updates"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/system_hooks/system_hooks"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12252"
      description: |
        System hooks allow for powerful automation by triggering requests when a variety of events in GitLab take place. Thanks to a community contribution, project and group membership changes are now supported in system hooks. This is a terrific addition for those who are looking to build additional levels of oversight and automation over membership changes.

        Thanks to [Brandon Williams](https://gitlab.com/rocketeerbkw) for the contribution!

    - name: "IP address restriction supports multiple subnets"
      available_in: [ultimate]
      documentation_link: "https://docs.gitlab.com/ee/user/group/#ip-access-restriction-ultimate-only"
      reporter: jeremy
      stage: manage
      issue_url: "https://gitlab.com/gitlab-org/gitlab/issues/12873"
      description: |
        Iterating on [restricting group activity by IP address](https://gitlab.com/gitlab-org/gitlab/issues/1985), GitLab 12.3 introduces the ability to specify multiple IP subnets. For geographically distributed organizations, this helps this feature shine; instead of specifying a single (and overly permissive) range, large organizations can now restrict incoming traffic to their specific needs.

    - name: "S/MIME Email Signing"
      available_in: [core, starter, premium, ultimate]
      documentation_link: "https://docs.gitlab.com/ee/administration/smime_signing_email.html"
      reporter: gweaver
      stage: plan
      issue_url: "https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30644"
      description: |
        Notification emails sent by GitLab can now be signed with S/MIME for improved security on the instance level.

        Thanks Siemens, [@bufferoverflow](https://gitlab.com/bufferoverflow), and [@dlouzan](https://gitlab.com/dlouzan) for the contribution!

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

        * [Add initial best practice documentation](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1509)
        * [Update PowerShell ErrorActionPreference documentation](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1535)
        * [Invalid service errors now specify the exact service](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1531)
        * [Use PowerShell-core compatible commands for directory creation](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1563)
        * [Fix exiting with zero exit code when cmdlets fail](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1558)
        * [Enable support for long paths](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1524)
        * [Expose variable containing the 'short token' value](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1571)
        * [Set default PATH for helper image](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1573)

        List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v12.3.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: ljlane
      stage: enablement
      stage_url: '/handbook/engineering/development/enablement/'
      description: |
        - SSL authentication to external Postgres servers is now supported by [specifying the certificate in `gitlab.rb`](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4296).
        - GitLab 12.3 includes [Mattermost 5.14](https://mattermost.com/blog/mattermost-5-14-accessibility-improvements-enhanced-jira-integration-ldap-group-sync-upgrade-and-more/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes keyboard accessibility improvements, enhanced Jira integration, and more. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.

    - 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.3 # Link to the merged MRs in the corresponding milestone
      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.3 are:

        - [Speed up listing issues and merge requests through the API by removing N+1 query](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31938)
        - [Faster deletion of associated events when destroying parent object](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/32751)
        - [Ported GetCommitSignatures RPC from Ruby to Go](https://gitlab.com/gitlab-org/gitaly/issues/1604)
        - [Ported GitLab Shell authorization checks from Ruby to Go](https://gitlab.com/gitlab-org/gitlab-shell/issues/181)

mvp:
  fullname: "Cédric Tabin"
  gitlab:  ctabin
  description: |
    Cédric's contribution to GitLab 12.3 adds a new [CI job keyword allowing interruptible builds](#interruptible-keyword-to-indicate-if-a-job-can-be-safely-canceled). They worked for more than 9 months contributing this feature and working with our review teams to get it across the line.

    Thanks so much to Cédric for their tireless effort on this contribution!

cover_img:
  image_url: "https://unsplash.com/photos/09cFSDQgl64"
  licence: Free
  licence_url: "https://unsplash.com/license"

cta:
  - title: "Join us for an upcoming event" # default
    link: '/events/'

deprecations:
  - feature_name: "Users with manually configured `.gitlab-ci.yml` using Secure features should be aware of deprecations in GitLab 12.3"
    due: GitLab 12.3
    reporter: NicoleSchwartz
    description: |
      If you have manually configured your `.gitlab-ci.yml` configuration file to use
      `DEP_SCAN_DISABLE_REMOTE_CHECKS` or
      `DS_DISABLE_REMOTE_CHECKS`
      flag variables, you need to remove this as it is no longer supported.

      If you utilize [vendored templates](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#including-the-provided-template), your configuration will be kept up to date with variable and argument changes.

      As announced in [GitLab Release 12.0 post](/blog/2019/06/22/gitlab-12-0-released/#deprecated-variables-and-argument-for-manual-configurations-of-%60.gitlab-ci.yml%60-when-using-secure-features)

  - feature_name: "gitlab-monitor tool renamed to gitlab-exporter"
    due: September 22, 2019
    reporter: dhershkovitch
    description: |
      To prevent confusion with the broader GitLab Monitor feature set, the gitlab-monitor tool has been renamed to gitlab-exporter. [gitlab-exporter](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_exporter.html) is a Prometheus web exporter that gives administrators insight into their GitLab instance, whereas the GitLab [Monitor](/stages-devops-lifecycle/monitor/) features enable monitoring of applications built using GitLab. If you're using Omnibus, you'll have to [update your `gitlab.rb` file](https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html#123).

  - feature_name: "Update public projects and subgroups in private groups to private visibility"
    due: Nov. 22, 2019
    reporter: jeremy
    description: |
      [In GitLab 10.0](https://gitlab.com/gitlab-org/gitlab-foss/issues/31273/), we introduced a change to clarify the visibility setting of public projects and subgroups in a private group. Since the most restrictive visibility setting applied, attempting to set a project or subgroup to public within a private group resulted in the visibility change being rejected.

      To prevent errors with existing projects and subgroups with public visibility, all public projects and subgroups in private groups [will be updated](https://gitlab.com/gitlab-org/gitlab/issues/22406) from public to private in GitLab 12.5.

      If you'd like a less restrictive visibility setting on a particular project or subgroup, you can simply move it out of the private group.
