Automatic merge of gitlab-org/gitlab-ce master

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

@@ -15,13 +15,13 @@
     - branches@gitlab-org/gitlab-ce
     - branches@gitlab-org/gitlab-ee
 
-package-and-qa:
-  extends: .package-and-qa-base
+package-and-qa-manual:
+  extends:
+    - .package-and-qa-base
+    - .no-docs-and-no-qa
   when: manual
-  except:
-    - /(^qa[\/-].*|.*-qa$)/
 
-package-and-qa-always:
+package-and-qa:
   extends: .package-and-qa-base
   allow_failure: true
   only:

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

@@ -171,7 +171,9 @@ review-qa-all:
     - gitlab-qa Test::Instance::Any "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}" -- --format RspecJunitFormatter --out tmp/rspec-${CI_JOB_ID}.xml --format html --out tmp/rspec.htm --color --format documentation
 
 parallel-spec-reports:
-  extends: .dedicated-runner
+  extends:
+    - .dedicated-runner
+    - .no-docs
   dependencies:
     - review-qa-all
   image: ruby:2.6-alpine

doc/development/testing_guide/end_to_end/index.md

@@ -45,11 +45,11 @@ Results are reported in the `#qa-staging` Slack channel.
 
 ### Testing code in merge requests
 
-#### Using the `package-and-qa` job
+#### Using the `package-and-qa-manual` 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 action in the `test` stage (not
+by triggering the `package-and-qa-manual` manual action in the `test` stage (not
 available for forks).
 
 **This runs end-to-end tests against a custom Omnibus package built from your
@@ -71,7 +71,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-ce/ee pipeline"
-    A1[`test` stage<br>`package-and-qa` job]
+    A1[`test` stage<br>`package-and-qa-manual` job]
     end
 
 subgraph "omnibus-gitlab pipeline"
@@ -79,7 +79,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` 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-manual` 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` action in their merge request.
+`package-and-qa-manual` action in their merge request.
 
 Obviously such a change would break all tests. We call this problem a _fragile
 tests problem_.

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 action, to test if everything works fine.
+using `package-and-qa-manual` manual action, to test if everything works fine.
 
 ## How can I use it?