Add latest changes from gitlab-org/gitlab@12-3-auto-deploy-20190916stable-branch-foss-test

4 files changed, 36 insertions, 66 deletions

diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index c00be77ce8c..f6a2f642274 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -7,6 +7,24 @@ as expected across the entire software stack and architecture, including
 integration of all micro-services and components that are supposed to work
 together.
 
+## Branch naming
+
+If your contribution contains **only** changes under the
+[`qa/` folder](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa), you can
+speed up the CI process by following some branch naming conventions. You have
+three choices:
+
+| Branch name           | Valid example                |
+|:----------------------|:-----------------------------|
+| Starting with `qa/`   | `qa/new-oauth-login-test`     |
+| Starting with `qa-`   | `qa-new-oauth-login-test`     |
+| Ending in `-qa`       | `123-new-oauth-login-test-qa` |
+
+If your branch name matches any of the above, it will run only the QA-related
+jobs.
+If it does not, the whole application test suite will run (including QA-related
+jobs).
+
 ## How do we test GitLab?
 
 We use [Omnibus GitLab][omnibus-gitlab] to build GitLab packages and then we
diff --git a/doc/development/testing_guide/end_to_end/style_guide.md b/doc/development/testing_guide/end_to_end/style_guide.md
index 9088e9e9bfb..54ed3f34c89 100644
--- a/doc/development/testing_guide/end_to_end/style_guide.md
+++ b/doc/development/testing_guide/end_to_end/style_guide.md
@@ -101,59 +101,43 @@ end
 
 ## Block argument naming
 
-To have a standard on what we call pages and resources when using the `.perform` method,
-we use the name of the page object in [snake_case](https://en.wikipedia.org/wiki/Snake_case)
-(all lowercase, with words separated by an underscore). See good and bad examples below.
-
-While we prefer to follow the standard in most cases, it is also acceptable to
-use common abbreviations (e.g., mr) or other alternatives, as long as
-the name is not ambiguous. This can include appending `_page` if it helps to
-avoid confusion or make the code more readable. For example, if a page object is
-named `New`, it could be confusing to name the block argument `new` because that
-is used to instantiate objects, so `new_page` would be acceptable.
-
-We chose not to simply use `page` because that would shadow the
-Capybara DSL, potentially leading to confusion and bugs.
+To have a standard on how we call pages when using the `.perform` method, we use the name of page object being called, all lowercased, and separated by underscore, if needed (see good and bad examples below.) This also applies to resources. We chose not to simply use `page` because that would shadow the Capybara DSL, potentially leading to confusion and bugs.
 
 ### Examples
 
 **Good**
 
 ```ruby
+# qa/specs/features/browser_ui/1_manage/project/add_project_member_spec.rb
+
 Page::Project::Settings::Members.perform do |members|
   members.do_something
 end
 ```
 
 ```ruby
+# qa/specs/features/ee/browser_ui/3_create/merge_request/add_batch_comments_in_merge_request_spec.rb
+
 Resource::MergeRequest.fabricate! do |merge_request|
   merge_request.do_something_else
 end
 ```
 
-```ruby
-Resource::MergeRequest.fabricate! do |mr|
-  mr.do_something_else
-end
-```
-
-```ruby
-Page::Project::New.peform do |new_page|
-  new_page.do_something
-end
-```
-
 **Bad**
 
 ```ruby
+# qa/specs/features/browser_ui/1_manage/project/add_project_member_spec.rb
+
 Page::Project::Settings::Members.perform do |project_settings_members_page|
   project_settings_members_page.do_something
 end
 ```
 
 ```ruby
-Page::Project::New.peform do |page|
-  page.do_something
+# qa/specs/features/ee/browser_ui/3_create/merge_request/add_batch_comments_in_merge_request_spec.rb
+
+Resource::MergeRequest.fabricate! do |merge_request_page|
+  merge_request_page.do_something_else
 end
 ```
 
diff --git a/doc/development/testing_guide/img/k9s.png b/doc/development/testing_guide/img/k9s.png
deleted file mode 100644
index c4b222f0b64..00000000000
--- a/doc/development/testing_guide/img/k9s.png
+++ /dev/null
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 8698a1e4c2d..13772cbe015 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -10,30 +10,24 @@ Review Apps are automatically deployed by each pipeline, both in
 
 ```mermaid
 graph TD
-    build-qa-image -->|once the `prepare` stage is done| gitlab:assets:compile
-    gitlab:assets:compile -->|once the `gitlab:assets:compile` job is done| review-build-cng
-    review-build-cng -.->|triggers a CNG-mirror pipeline and wait for it to be done| CNG-mirror
-    CNG-mirror -.->|polls until completed| review-build-cng
-    review-build-cng -->|once the `review-build-cng` job is done| review-deploy
-    review-deploy -->|once the `review-deploy` job is done| review-qa-smoke
+    build-qa-image -.->|once the `prepare` stage is done| gitlab:assets:compile
+    review-build-cng -->|triggers a CNG-mirror pipeline and wait for it to be done| CNG-mirror
+    review-build-cng -.->|once the `test` stage is done| review-deploy
+    review-deploy -.->|once the `review` stage is done| review-qa-smoke
 
 subgraph "1. gitlab-ce/ee `prepare` stage"
     build-qa-image
     end
 
 subgraph "2. gitlab-ce/ee `test` stage"
-    gitlab:assets:compile
+    gitlab:assets:compile -->|plays dependent job once done| review-build-cng
     end
 
-subgraph "3. gitlab-ce/ee `review-prepare` stage"
-    review-build-cng
-    end
-
-subgraph "4. gitlab-ce/ee `review` stage"
+subgraph "3. gitlab-ce/ee `review` stage"
     review-deploy["review-deploy<br><br>Helm deploys the Review App using the Cloud<br/>Native images built by the CNG-mirror pipeline.<br><br>Cloud Native images are deployed to the `review-apps-ce` or `review-apps-ee`<br>Kubernetes (GKE) cluster, in the GCP `gitlab-review-apps` project."]
     end
 
-subgraph "5. gitlab-ce/ee `qa` stage"
+subgraph "4. gitlab-ce/ee `qa` stage"
     review-qa-smoke[review-qa-smoke<br><br>gitlab-qa runs the smoke suite against the Review App.]
     end
 
@@ -183,25 +177,6 @@ secure note named **gitlab-{ce,ee} Review App's root password**.
    `review-qa-raise-e-12chm0-migrations.1-nqwtx`.
 1. Click on the `Container logs` link.
 
-### Diagnosing unhealthy review-app releases
-
-If [Review App Stability](https://gitlab.com/gitlab-org/quality/team-tasks/issues/93) dips this may be a signal
-that the `review-apps-ce/ee` cluster is unhealthy. Leading indicators may be healthcheck failures leading to restarts or majority failure for Review App deployments.
-
-The following items may help diagnose this:
-
-- [Instance group CPU Utilization in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-a/gke-review-apps-ce-preemp-n1-standard-a4c9571c-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_CPU&duration=PT12H) - helpful to identify if nodes are problematic or the entire cluster is trending towards unhealthy
-- [Instance Group size in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-a/gke-review-apps-ce-preemp-n1-standard-a4c9571c-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_SIZE&duration=PT12H) - aids in identifying load spikes on the cluster. Kubernetes will add nodes up to 220 based on total resource requests.
-- `kubectl top nodes --sort-by=cpu` - can identify if node spikes are common or load on specific nodes which may get rebalanced by the Kubernetes scheduler.
-- `kubectl top pods --sort-by=cpu` -
-- [K9s] - K9s is a powerful command line dashboard which allows you to filter by labels. This can help identify trends with apps exceeding the [review-app resource requests](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/review_apps/base-config.yaml). Kubernetes will schedule pods to nodes based on resource requests and allow for CPU usage up to the limits.
-  - In K9s you can sort or add filters by typing the `/` character
-    - `-lrelease=<review-app-slug>` - filters down to all pods for a release. This aids in determining what is having issues in a single deployment
-    - `-lapp=<app>` - filters down to all pods for a specific app. This aids in determining resource usage by app.
-  - You can scroll to a Kubernetes resource and hit `d`(describe), `s`(shell), `l`(logs) for a deeper inspection
-
-![K9s](img/k9s.png)
-
 ### Troubleshoot a pending `dns-gitlab-review-app-external-dns` Deployment
 
 #### Finding the problem
@@ -291,12 +266,6 @@ find a way to limit it to only us.**
 ## Other resources
 
 - [Review Apps integration for CE/EE (presentation)](https://docs.google.com/presentation/d/1QPLr6FO4LduROU8pQIPkX1yfGvD13GEJIBOenqoKxR8/edit?usp=sharing)
-- [Stability issues](https://gitlab.com/gitlab-org/quality/team-tasks/issues/212)
-
-### Helpful command line tools
-
-- [K9s] - enables CLI dashboard across pods and enabling filtering by labels
-- [Stern](https://github.com/wercker/stern) - enables cross pod log tailing based on label/field selectors
 
 [charts-1068]: https://gitlab.com/gitlab-org/charts/gitlab/issues/1068
 [gitlab-pipeline]: https://gitlab.com/gitlab-org/gitlab-ce/pipelines/44362587
@@ -316,7 +285,6 @@ find a way to limit it to only us.**
 [gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml
 [gitlab-k8s-integration]: ../../user/project/clusters/index.md
 [password-bug]: https://gitlab.com/gitlab-org/gitlab-ce/issues/53621
-[K9s]: https://github.com/derailed/k9s
 
 ---