Commit 2d81033a authored by Evan Read's avatar Evan Read

Merge branch 'jv-workhorse-sidechannel-docs' into 'master'

Improve Workhorse sidechannel documentation

See merge request gitlab-org/gitlab!73838
parents 5fdbe46a 7af7d07d
...@@ -256,8 +256,8 @@ For very active repositories with a large number of references and files, you ca ...@@ -256,8 +256,8 @@ For very active repositories with a large number of references and files, you ca
- Consider using the [Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache) instead of a - Consider using the [Gitaly pack-objects cache](../../administration/gitaly/configure_gitaly.md#pack-objects-cache) instead of a
pre-clone step. This is easier to set up and it benefits all repositories on your GitLab server, unlike the pre-clone step that pre-clone step. This is easier to set up and it benefits all repositories on your GitLab server, unlike the pre-clone step that
must be configured per-repository. The pack-objects cache also automatically works for forks. For `gitlab-org/gitlab` development must be configured per-repository. The pack-objects cache also automatically works for forks. On GitLab.com, where the pack-objects cache is
on GitLab.com, we stopped using a pre-clone step. enabled on all Gitaly servers, we found that we no longer need a pre-clone step for `gitlab-org/gitlab` development.
- Optimize your CI/CD jobs by seeding repository data in a pre-clone step with the - Optimize your CI/CD jobs by seeding repository data in a pre-clone step with the
[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) of GitLab Runner. See our [`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) of GitLab Runner. See our
[development documentation](../../development/pipelines.md#pre-clone-step) for an overview of how we used to implement this approach on [development documentation](../../development/pipelines.md#pre-clone-step) for an overview of how we used to implement this approach on
......
...@@ -311,7 +311,7 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo ...@@ -311,7 +311,7 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
- Connections between Workhorse and Gitaly use the Gitaly `backchannel` protocol by default. If you deployed a gRPC proxy between Workhorse and Gitaly, - Connections between Workhorse and Gitaly use the Gitaly `backchannel` protocol by default. If you deployed a gRPC proxy between Workhorse and Gitaly,
Workhorse can no longer connect. As a workaround, [disable the temporary `workhorse_use_sidechannel`](../administration/feature_flags.md#enable-or-disable-the-feature) Workhorse can no longer connect. As a workaround, [disable the temporary `workhorse_use_sidechannel`](../administration/feature_flags.md#enable-or-disable-the-feature)
feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy. feature flag. If you need a proxy between Workhorse and Gitaly, use a TCP proxy. If you have feedback about this change, please go to [this issue](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1301).
### 14.4.0 ### 14.4.0
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment