Add latest changes from gitlab-org/gitlab@master

4 files changed, 11 insertions, 18 deletions

diff --git a/doc/development/cycle_analytics.md b/doc/development/cycle_analytics.md
index 284645cdae7..90abafb3e03 100644
--- a/doc/development/cycle_analytics.md
+++ b/doc/development/cycle_analytics.md
@@ -77,8 +77,8 @@ end
 
 Some start/end event pairs are not "compatible" with each other. For example:
 
-- "Issue created" to "Merge Request created": The event classes are defined on different  domain models, the `object_type` method is different.
-- "Issue closed" to "Issue created": Issue must be created first before it can be  closed.
+- "Issue created" to "Merge Request created": The event classes are defined on different domain models, the `object_type` method is different.
+- "Issue closed" to "Issue created": Issue must be created first before it can be closed.
 - "Issue closed" to "Issue closed": Duration is always 0.
 
 The `StageEvents` module describes the allowed `start_event` and `end_event` pairings (`PAIRING_RULES` constant). If a new event is added, it needs to be registered in this module.
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index d516a808afd..32c89c28815 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -156,7 +156,7 @@ This is similar to the `.only:variables-canonical-dot-com` + `.except:refs-maste
 CI definitions:
 
 ```yaml
-.if-canonical-gitlab-and-merge-request: &if-canonical-gitlab-and-merge-request
+.if-canonical-gitlab-merge-request: &if-canonical-gitlab-merge-request
   if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_MERGE_REQUEST_IID'
 ```
 
@@ -210,9 +210,7 @@ graph RL;
   M[coverage];
   N[pages];
   O[static-analysis];
-  P["schedule:package-and-qa<br/>(master schedule only)"];
   Q[package-and-qa];
-  R[package-and-qa-manual];
   S["RSpec<br/>(e.g. rspec unit pg9)"]
   T[retrieve-tests-metadata];
 
@@ -259,10 +257,6 @@ subgraph "`review` stage"
 subgraph "`qa` stage"
     Q --> |needs| C;
     Q --> |needs| F;
-    R --> |needs| C;
-    R --> |needs| F;
-    P --> |needs| C;
-    P --> |needs| F;
     review-qa-smoke -.-> |needs and depends on| G;
     review-qa-all -.-> |needs and depends on| G;
     review-performance -.-> |needs and depends on| G;
@@ -271,8 +265,7 @@ subgraph "`qa` stage"
     end
 
 subgraph "`notification` stage"
-    NOTIFICATION1["schedule:package-and-qa:notify-success<br>(on_success)"] -.-> |needs| P;
-    NOTIFICATION2["schedule:package-and-qa:notify-failure<br>(on_failure)"] -.-> |needs| P;
+    NOTIFICATION2["package-and-qa:notify-failure<br>(manual)"] -.-> |needs| Q;
     end
 
 subgraph "`post-test` stage"
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 20b594119ab..85cad3971c3 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -27,11 +27,11 @@ You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/s
 
 ### Testing code in merge requests
 
-#### Using the `package-and-qa-manual` job
+#### Using the `package-and-qa` job
 
 It is possible to run end-to-end tests for a merge request, eventually being run in
 a pipeline in the [`gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/) project,
-by triggering the `package-and-qa-manual` manual action in the `test` stage (not
+by triggering the `package-and-qa` manual action in the `test` stage (not
 available for forks).
 
 **This runs end-to-end tests against a custom Omnibus package built from your
@@ -53,7 +53,7 @@ graph LR
     B2[`Trigger-qa` stage<br>`Trigger:qa-test` job] -.->|2. Triggers a gitlab-qa pipeline and wait for it to be done| A3
 
 subgraph "gitlab-foss/gitlab pipeline"
-    A1[`test` stage<br>`package-and-qa-manual` job]
+    A1[`test` stage<br>`package-and-qa` job]
     end
 
 subgraph "omnibus-gitlab pipeline"
@@ -61,7 +61,7 @@ subgraph "omnibus-gitlab pipeline"
     end
 
 subgraph "gitlab-qa pipeline"
-    A3>QA jobs run] -.->|3. Reports back the pipeline result to the `package-and-qa-manual` job<br>and post the result  on the original commit tested| A1
+    A3>QA jobs run] -.->|3. Reports back the pipeline result to the `package-and-qa` job<br>and post the result  on the original commit tested| A1
     end
 ```
 
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index 554995fa2e2..f1e0de0c792 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -40,7 +40,7 @@ the time it would take to build packages and test everything.
 That is why when someone changes `t.text_field :login` to
 `t.text_field :username` in the _new session_ view we won't know about this
 change until our GitLab QA nightly pipeline fails, or until someone triggers
-`package-and-qa-manual` action in their merge request.
+`package-and-qa` action in their merge request.
 
 Obviously such a change would break all tests. We call this problem a _fragile
 tests problem_.
@@ -171,8 +171,8 @@ and we should prefer the `data-qa-selector` method of definition.
 
 > Introduced in GitLab 12.5
 
-A common occurrence in automated testing is selecting a single "one-of-many" element.  
-In a list of several items, how do you differentiate what you are selecting on?  
+A common occurrence in automated testing is selecting a single "one-of-many" element.
+In a list of several items, how do you differentiate what you are selecting on?
 The most common workaround for this is via text matching.  Instead, a better practice is
 by matching on that specific element by a unique identifier, rather than by text.