ContextQMD
Back to Gitlabhq

GitLab Silent Mode

doc/administration/silent_mode/_index.md

18.11.211.8 KB
Original Source

{{< details >}}

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed

{{< /details >}}

{{< history >}}

{{< /history >}}

Silent Mode allows you to silence outbound communication, such as emails, from GitLab. Silent Mode is not intended to be used on environments which are in-use.

When to use Silent Mode

Silent Mode is designed for specific testing and validation scenarios and should not be used as a general-purpose feature for production environments.

Silent Mode is designed for the following scenarios:

  • Testing Geo site promotion: When validating disaster recovery procedures by promoting a secondary Geo site while the primary site remains active.
    • For example, you have a secondary Geo site as part of your disaster recovery solution. You want to regularly test promoting it to become a primary Geo site, as a best practice to ensure your disaster recovery plan actually works. But you don't want to actually perform an entire failover because the primary site lives in a region which provides the lowest latency to your users. And you don't want to take downtime during every regular test. So, you let the primary site remain up, while you promote the secondary site. You start smoke testing the promoted site. But, the promoted site starts emailing users, the push mirrors push changes to external Git repositories, etc. This is where Silent Mode comes in. You can enable it as part of site promotion, to avoid this issue.
  • Validating GitLab backups: When testing backup restoration on a separate testing instance to ensure backups are functional. Silent Mode can be used to avoid sending invalid emails to users.
  • Staging environment testing: When you need to test GitLab functionality without triggering outbound communications that could affect users or external systems. Particularly if you seeded your staging environment with production data.

Silent Mode is not designed for:

  • Production environments: Silent Mode intentionally breaks many GitLab features. Silent Mode can cause unexpected errors, particularly in new features. Silent Mode must err on the side of caution by blocking new communications by default.

Turn on Silent Mode

Prerequisites:

  • You must have administrator access.

There are multiple ways to turn on Silent Mode:

  • Web UI

    1. In the upper-right corner, select Admin.
    2. In the left sidebar, select Settings > General.
    3. Expand Silent Mode, and turn on the Enable Silent Mode toggle.
    4. Changes are saved immediately.

  • API:

    shell
    curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?silent_mode_enabled=true"

  • Rails console:

    ruby
    ::Gitlab::CurrentSettings.update!(silent_mode_enabled: true)

It may take up to a minute to take effect. Issue 405433 proposes removing this delay.

Turn off Silent Mode

Prerequisites:

  • You must have administrator access.

There are multiple ways to disable Silent Mode:

  • Web UI

    1. In the upper-right corner, select Admin.
    2. In the left sidebar, select Settings > General.
    3. Expand Silent Mode, and turn off the Enable Silent Mode toggle.
    4. Changes are saved immediately.

  • API:

    shell
    curl --request PUT --header "PRIVATE-TOKEN:$ADMIN_TOKEN" "<gitlab-url>/api/v4/application/settings?silent_mode_enabled=false"

  • Rails console:

    ruby
    ::Gitlab::CurrentSettings.update!(silent_mode_enabled: false)

It may take up to a minute to take effect. Issue 405433 proposes removing this delay.

Behavior of GitLab features in Silent Mode

This section documents the current behavior of GitLab when Silent Mode is enabled. The work for the first iteration of Silent Mode is tracked by Epic 9826.

When Silent Mode is enabled, a banner is displayed at the top of the page for all users stating the setting is enabled and All outbound communications are blocked.

Outbound communications that are silenced

Outbound communications from the following features are silenced by Silent Mode.

FeatureNotes
GitLab DuoGitLab Duo features cannot contact external language model providers.
Project and group webhooksTriggering webhook tests via the UI results in HTTP status 500 responses.
System hooks
Remote mirrorsPushes to remote mirrors are skipped. Pulls from remote mirrors is skipped.
Executable integrationsThe integrations are not executed.
Service DeskIncoming emails still raise issues, but the users who sent the emails to Service Desk are not notified of issue creation or comments on their issues.
Outbound emailsAt the moment when an email should be sent by GitLab, it is instead dropped. It is not queued anywhere.
Outbound HTTP requestsMany HTTP requests are blocked where features are not blocked or skipped explicitly. These may produce errors with the class SilentModeBlockedError. If a particular error is problematic for testing during Silent Mode, consult GitLab Support. In general, the caller should exit when Silent Mode is enabled, rather than attempt to make the HTTP request. Any exceptions must align with the intended uses for Silent Mode.

Outbound communications that are not silenced

Outbound communications from the following features are not silenced by Silent Mode.

FeatureNotes
Dependency proxyPulling images that are not cached will fetch from the source as usual. Consider pull rate limits.
File hooks
Server hooks
Advanced searchIf two GitLab instances are using the same advanced search instance, then they can both modify Search data. This is a split-brain scenario which can occur for example after promoting a secondary Geo site while the primary Geo site is live.
ClickHouse callsClickHouse requests are not silenced because they are considered internal to a site.
SnowplowA proposal exists in issue 409661 to silence these requests.
Deprecated Kubernetes ConnectionsThere is a proposal to silence these requests.
Container registry webhooksThere is a proposal to silence these requests.