GitLab.org/GitLab: Release v12.3.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 12.3
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[API activity included in IP address group restriction](https://docs.gitlab.com/ee/user/group/#ip-access-restriction)
> 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.
[IP address restriction supports multiple subnets](https://docs.gitlab.com/ee/user/group/#ip-access-restriction)
> 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.
[Leverage merge request approvals to prevent merging prohibited licenses MVC](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html#security-approvals-in-merge-requests-ultimate)
> 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/compliance/license_compliance/index.html#security-approvals-in-merge-requests).
[Validate domains when performing full DAST active scans](https://docs.gitlab.com/ee/user/application_security/dast/#domain-validation)
> 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.
[SAST scanning without Docker-in-Docker](https://docs.gitlab.com/ee/user/application_security/sast/index.html)
> SAST scans can now optionally be done without using Docker-in-Docker.
>
> This means SAST scanning can be configured to not need elevated
> privileges.
[SAST Spotbugs analyzer updated for Java 11](https://docs.gitlab.com/ee/user/application_security/sast/#analyzer-settings)
> 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.
[Edit vulnerability dismissal reasons](https://docs.gitlab.com/ee/user/application_security/#dismissing-a-vulnerability)
> 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.
[Productivity Analytics](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html)
> 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).
[Global view for group-level cluster deployments/environments](https://docs.gitlab.com/ee/user/clusters/environments.html)
> 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.
[Run Pipeline button for Merge Request Pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/)
> [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.
[Geo natively supports Docker Registry replication](https://docs.gitlab.com/ee/administration/geo/replication/docker_registry.html) (self-managed only)
> 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.
[Geo displays secondary lag when pushing via Git HTTP](https://docs.gitlab.com/ee/administration/geo/index.htmlhow-it-works) (self-managed only)
> 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`.
[Design Management status and discussion counts](https://docs.gitlab.com/ee/user/project/issues/design_management.html)
> In GitLab 12.2 we released the first iteration of Design Management, which allowed uploading designs directly to issues. They were uploaded in a separate tab within issues and 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.
[Design Management notifications](https://docs.gitlab.com/ee/user/project/issues/design_management.html)
> 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.
[API for Merge Request Approval Rules](https://docs.gitlab.com/ee/api/merge_request_approvals.html)
> 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.
[Audit logs for Git Push events (Beta)](https://docs.gitlab.com/ee/administration/audit_events.html)
> 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.
[API to require merge request approval by code owners per branch](https://docs.gitlab.com/ee/api/protected_branches.html#protected-branches-api)
> 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.
['only/except: external_pull_requests' for external repositories](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/#pipelines-for-external-pull-requests)
> 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.
[Status checking for pipeline triggers](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#mirroring-status-from-triggered-pipeline)
> 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.
[Analytics Workspace](https://docs.gitlab.com/ee/user/analytics/index.html)
> 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/plan/value_stream_management/)
[Improve Pages initial setup experience](https://docs.gitlab.com/ee/user/project/pages/)
> 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.
[User-defined CI variables available to docker build with Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#passing-secrets-to-docker-build-beta)
> 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`.
[Show Kubernetes cluster used for deployment](https://docs.gitlab.com/ee/user/project/clusters/#deploying-to-a-kubernetes-cluster)
> 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.
[Knative for group and instance-level clusters](https://docs.gitlab.com/ee/user/clusters/applications.html#knative)
> 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.
[JupyterHub for group-level Kubernetes clusters](https://docs.gitlab.com/ee/user/clusters/applications.html#jupyterhub)
> 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.
[Disable 2FA for selected OAuth providers](https://docs.gitlab.com/ee/integration/omniauth.html#bypassing-two-factor-authentication)
> 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!
[System hooks for project and group member updates](https://docs.gitlab.com/ee/system_hooks/system_hooks)
> 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!
[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only)
> - 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.
[Performance improvements](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=12.3)
> 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)
[S/MIME Email Signing](https://docs.gitlab.com/ee/administration/smime_signing_email.html)
> 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!
Compress Git ref advertisements over HTTP
> 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.
[Keyboard shortcut for next and previous unresolved discussion](https://docs.gitlab.com/ee/user/shortcuts.html#issues-and-merge-requests)
> 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 n and p keyboard
> shortcuts to move to the **n**ext and **p**revious unresolved
> discussions in Merge Requests make it even more convenient to review
> changes.
[Smarter Web IDE default commit options](https://docs.gitlab.com/ee/user/project/web_ide/)
> 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.
[Per-job timeouts for CI/CD pipelines](https://docs.gitlab.com/ee/ci/yaml/#timeout) (self-managed only)
> 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.
[Flexible 'rules' keyword for controlling pipeline behaviors](https://docs.gitlab.com/ee/ci/yaml/#rules)
> `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.
['interruptible' keyword to indicate if a job can be safely canceled](https://docs.gitlab.com/ee/ci/yaml/#interruptible)
> 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/ci/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}
[GitLab Runner 12.3](https://docs.gitlab.com/runner)
> 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).
[Remove container images from CI/CD](https://docs.gitlab.com/ee/user/packages/container_registry/index.html)
> 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.
[API endpoint to list the Docker images/tags of a group](https://docs.gitlab.com/ee/api/container_registry.html#within-a-group)
> 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.
[Web Application Firewall for Kubernetes Ingress](https://docs.gitlab.com/ee/user/clusters/applications.html#web-application-firewall-modsecurity)
> 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.
[Line charts for metrics dashboard](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#defining-custom-dashboards-per-project)
> 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.
[Close issue via slash command in Slack](https://docs.gitlab.com/ee/integration/slash_commands.html)
> 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.
[Quick actions to add/remove Zoom meetings on issues](https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics)
> 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.