Run the scheduled QA only when it's a schedule

To eliminate branch pipeline

.gitlab/ci/qa.gitlab-ci.yml

 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
-.if-canonical-gitlab-and-merge-request: &if-canonical-gitlab-and-merge-request
+.if-canonical-gitlab-schedule: &if-canonical-gitlab-schedule
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_PIPELINE_SOURCE == "schedule"'
+
+# Make sure to update all the similar conditions in other CI config files if you modify these conditions
+.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'
 
 # Make sure to update all the similar patterns in other CI config files if you modify these patterns
@@ -68,19 +72,19 @@ qa:selectors-foss:
 package-and-qa:
   extends: .package-and-qa-base
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *qa-patterns
       when: on_success
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-patterns
       when: manual
   needs: ["build-qa-image", "gitlab:assets:compile pull-cache"]
   allow_failure: true
 
 schedule:package-and-qa:
-  extends:
-    - .package-and-qa-base
-    - .default-only
-    - .only:variables_refs-canonical-dot-com-schedules
+  extends: .package-and-qa-base
+  rules:
+    - <<: *if-canonical-gitlab-schedule
+      when: on_success
   needs: ["build-qa-image", "gitlab:assets:compile pull-cache"]
   allow_failure: true

.gitlab/ci/review.gitlab-ci.yml

 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
-.if-canonical-gitlab: &if-canonical-gitlab
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/'
+.if-canonical-gitlab-schedule: &if-canonical-gitlab-schedule
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_PIPELINE_SOURCE == "schedule"'
 
 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
-.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'
 
 # Make sure to update all the similar patterns in other CI config files if you modify these patterns
@@ -44,9 +44,11 @@ build-qa-image:
   extends: .review-docker
   stage: prepare
   rules:
-    - <<: *if-canonical-gitlab
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: on_success
+    - <<: *if-canonical-gitlab-schedule
+      when: on_success
   script:
     - '[[ ! -d "ee/" ]] || export GITLAB_EDITION="ee"'
     - export QA_MASTER_IMAGE="${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab/gitlab-${GITLAB_EDITION}-qa:master"
@@ -157,7 +159,7 @@ schedule:review-build-cng:
 review-deploy:
   extends: .review-deploy-base
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: on_success
 
@@ -184,7 +186,7 @@ review-stop-failed-deployment:
   extends: .base-review-stop
   stage: prepare
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: on_success
   script:
@@ -194,7 +196,7 @@ review-stop:
   extends: .base-review-stop
   stage: review
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: manual
   allow_failure: true
@@ -235,7 +237,7 @@ review-stop:
 review-qa-smoke:
   extends: .review-qa-base
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: on_success
   script:
@@ -244,7 +246,7 @@ review-qa-smoke:
 review-qa-all:
   extends: .review-qa-base
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: manual
   parallel: 5
@@ -276,7 +278,7 @@ review-qa-all:
 review-performance:
   extends: .review-performance-base
   rules:
-    - <<: *if-canonical-gitlab-and-merge-request
+    - <<: *if-canonical-gitlab-merge-request
       changes: *code-qa-patterns
       when: on_success
   needs: ["review-deploy"]

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'
 ```
 
@@ -212,7 +212,6 @@ graph RL;
   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,8 +258,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;

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
 ```
 

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.
 

qa/README.md

@@ -30,7 +30,7 @@ and corresponding views / partials / selectors in CE / EE.
 
 Whenever `qa:selectors` job fails in your merge request, you are supposed to
 fix [page objects](../doc/development/testing_guide/end_to_end/page_objects.md). You should also trigger end-to-end tests
-using `package-and-qa-manual` manual action, to test if everything works fine.
+using `package-and-qa` manual action, to test if everything works fine.
 
 ## How can I use it?