Add latest changes from gitlab-org/gitlab@master

4 files changed, 44 insertions, 7 deletions

diff --git a/doc/architecture/blueprints/runner_scaling/index.md b/doc/architecture/blueprints/runner_scaling/index.md
index 7fa39a3cfdb..174fe191cc7 100644
--- a/doc/architecture/blueprints/runner_scaling/index.md
+++ b/doc/architecture/blueprints/runner_scaling/index.md
@@ -44,7 +44,7 @@ and the documentation for it has been removed from the official page. This
 means that the original reason to use Docker Machine is no longer valid too.
 
 To keep supporting our customers and the wider community we need to design a
-new mechanism for GitLab Runner autoscaling. It not only needs to support
+new mechanism for GitLab Runner auto-scaling. It not only needs to support
 auto-scaling, but it also needs to do that in the way to enable us to build on
 top of it to improve efficiency, reliability and availability.
 
@@ -144,7 +144,7 @@ on a single machine bring. It is difficult to predict that, so ideally we
 should build a PoC that will help us to better understand what we can expect
 from this.
 
-To run this experiement we most likely we will need to build an experimental
+To run this experiment we most likely we will need to build an experimental
 plugin, that not only allows us to schedule running multiple builds on a single
 machine, but also has a set of comprehensive metrics built into it, to make it
 easier to understand how it performs.
@@ -204,7 +204,7 @@ document, define requirements and score the solution accordingly. This will
 allow us to choose a solution that will work best for us and the wider
 community.
 
-### Plugin system design principles
+### Design principles
 
 Our goal is to design a GitLab Runner plugin system interface that is flexible
 and simple for the wider community to consume. As we cannot build plugins for
@@ -215,7 +215,16 @@ To achieve this goal, we will follow a few critical design principles. These
 principles will guide our development process for the new plugin system
 abstraction.
 
-General high-level principles:
+#### General high-level principles
+
+1. Design the new auto-scaling architecture aiming for having more choices and
+   flexibility in the future, instead of imposing new constraints.
+1. Design the new auto-scaling architecture to experiment with running multiple
+   jobs in parallel, on a single machine.
+1. Design the new provisioning architecture to replace Docker Machine in a way
+   that the wider community can easily build on top of the new abstractions.
+
+#### Principles for the new plugin system
 
 1. Make the entry barrier for writing a new plugin low.
 1. Developing a new plugin should be simple and require only basic knowledge of
@@ -227,7 +236,7 @@ General high-level principles:
 1. Invest in a flexible solution, avoid one-way-door decisions, foster iteration.
 1. When in doubts err on the side of making things more simple for the wider community.
 
-A few most important technical details:
+#### The most important technical details
 
 1. Favor gRPC communication between a plugin and GitLab Runner.
 1. Make it possible to version communication interface and support many versions.
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index df3b26d59af..af402713f6e 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -513,7 +513,7 @@ Feature.remove(:feature_flag_name)
 
 - Any change behind a feature flag **disabled** by default **should not** have a changelog entry.
   - **Exception:** database migrations **should** have a changelog entry.
-- Any change related to a feature flag itself (flag removal, default-on setting) **should** have a changelog entry.
+- Any change related to a feature flag itself (flag removal, default-on setting) **should** have [a changelog entry](../changelog.md).
   Use the flowchart to determine the changelog entry type.
 
   ```mermaid
diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
index ef3e0624395..7fb95769fc2 100644
--- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
+++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
@@ -141,6 +141,34 @@ docker stop gitlab-gitaly-cluster praefect postgres gitaly3 gitaly2 gitaly1
 docker rm gitlab-gitaly-cluster praefect postgres gitaly3 gitaly2 gitaly1
 ```
 
+## Tests that require a runner
+
+To execute tests that use a runner without errors, while creating the GitLab Docker instance the `--hostname` parameter in the Docker `run` command should be given a specific interface IP address or a non-loopback hostname accessible from the runner container. Having `localhost` (or `127.0.0.1`) as the GitLab hostname won't work (unless the GitLab Runner is created with the Docker network as `host`)
+
+Examples of tests which require a runner:
+
+- `qa/qa/specs/features/ee/browser_ui/13_secure/create_merge_request_with_secure_spec.rb`
+- `qa/qa/specs/features/browser_ui/4_verify/runner/register_runner_spec.rb`
+
+Example:
+
+```shell
+docker run \ 
+  --detach \
+  --hostname interface_ip_address \
+  --publish 80:80 \
+  --name gitlab \
+  --restart always \
+  --volume ~/ee_volume/config:/etc/gitlab \
+  --volume ~/ee_volume/logs:/var/log/gitlab \
+  --volume ~/ee_volume/data:/var/opt/gitlab \
+  --shm-size 256m \
+  gitlab/gitlab-ee:latest
+```
+
+Where `interface_ip_address` is your local network's interface IP, which you can find with the `ifconfig` command.
+The same would apply to GDK running with the instance address as `localhost` too.
+
 ## Guide to run and debug Monitor tests
 
 ### How to set up
diff --git a/doc/install/aws/gitlab_hybrid_on_aws.md b/doc/install/aws/gitlab_hybrid_on_aws.md
index 23074090208..2c40efd5909 100644
--- a/doc/install/aws/gitlab_hybrid_on_aws.md
+++ b/doc/install/aws/gitlab_hybrid_on_aws.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Provision GitLab Cloud Native Hybrid on AWS EKS **(FREE SELF)**
 
-GitLab "Cloud Native Hybrid" is a hybrid of the cloud native technology Kubernetes (EKS) and EC2. While as much of the GitLab application as possible runs in Kubernetes or on AWS services (PaaS), the GitLab service Gitaly must still be run on Ec2. Gitaly is a layer designed to overcome limitations of the Git binaries in a horizontally scaled architecture. You can read more here about why Gitaly was built and why the limitations of Git mean that it must currently run on instance compute in [Git Characteristics That Make Horizontal Scaling Difficult](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-characteristics-that-make-horizontal-scaling-difficult).
+GitLab "Cloud Native Hybrid" is a hybrid of the cloud native technology Kubernetes (EKS) and EC2. While as much of the GitLab application as possible runs in Kubernetes or on AWS services (PaaS), the GitLab service Gitaly must still be run on EC2. Gitaly is a layer designed to overcome limitations of the Git binaries in a horizontally scaled architecture. You can read more here about why Gitaly was built and why the limitations of Git mean that it must currently run on instance compute in [Git Characteristics That Make Horizontal Scaling Difficult](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#git-characteristics-that-make-horizontal-scaling-difficult).
 
 Amazon provides a managed Kubernetes service offering known as [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/).