gitlab-qa 5.16.0 → 5.17.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bc79855be61afd8dfaef793cb1a6520bde1f07f6c44a18b9fdd605e26ac947c4
-  data.tar.gz: d326f64befb861020097fd55b9772b54d7014509e87c5c13c71e619c11a21a65
+  metadata.gz: a9c4251f7eaa756abc42d5cb76b0b318ec3b14004331d32a92e125135055ecef
+  data.tar.gz: 04bb9549728a2533cfb34b2e5ade00260511fda1d6e4d052769d9682b73b497b
 SHA512:
-  metadata.gz: e497734ed2d4d9d58c2dcdf051eb3a4a6ad02adcfc7954ae54ac83ee912b47ff0d6f8478ea6e272a8a93feb14cdda8d55632fb0f92e97379596a12b67ee25f57
-  data.tar.gz: fc927589ca591708a7b61341acf69d48125812642ce9ca87f0183cf11bcf14c55d6bfa8bb04fe1cf3c4685e1d4da0781bab6af15a942c0675ae149fac8b20704
+  metadata.gz: dfb8a2afb17ac4d47e0c770c8da39a3290d6ac58d6306f3a930d50b08180660c85995ff248b1f50bdd6f8d9fe26b29f8680016b03ff07f85d5600e1bd5c7be90
+  data.tar.gz: a84cd2cef18c8f229826b47236edd8749345de2bfb51be1705109d623b0fefec7b09088f46244df206f85665420fb22dbdc3d8a250e617a8ab45876e95fc99d0

data/docs/what_tests_can_be_run.md

@@ -1,5 +1,6 @@
-# What tests can be run?
 
+# What tests can be run?
+[[_TOC_]]
 ## The two types of QA tests
 
 First of all, the first thing to choose is whether you want to run orchestrated
@@ -28,6 +29,8 @@ For more details on the internals, please read the
 
 ## Supported GitLab environment variables
 
+All environment variables used by GitLab QA should be defined in [`lib/gitlab/qa/runtime/env.rb`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/lib/gitlab/qa/runtime/env.rb).
+
 |        Variable       | Default   | Description           | Required |
 |-----------------------|-----------|-----------------------|----------|
 | `GITLAB_USERNAME`       | `root`  | Username to use when signing into GitLab. | Yes|
@@ -53,7 +56,8 @@ For more details on the internals, please read the
 | `GITLAB_SANDBOX_NAME`   | `gitlab-qa-sandbox` | The sandbox group name the test suite is going to use. | No|
 | `GITLAB_QA_ACCESS_TOKEN`|-  | A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. An existing token that is valid on [`Test::Instance::Staging`](#testinstancestaging) scenario to retrieve the staging can be found in the shared 1Password vault. |No|
 | `GITLAB_QA_ADMIN_ACCESS_TOKEN` |-  | A valid personal access token with the `api` scope from a user with admin access. Used for API access as an admin during tests. | No|
-| `EE_LICESEN` |-  | Enterprise Edition license. | No|
+| `GITLAB_QA_CONTAINER_REGISTRY_ACCESS_TOKEN` | - | A valid personal access token with the `read_registry` scope. Used to [access the container registry on `registry.gitlab.com` when tests run in a CI job that _is not_ triggered via another pipeline](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/364addb83e7b136ff0f9d8719ca9553d290aa9ab/lib/gitlab/qa/release.rb#L152). For example, if you manually run a [new Staging pipeline](https://ops.gitlab.net/gitlab-org/quality/staging/-/pipelines/new), this token will be used. | No |
+| `EE_LICENSE` |-  | Enterprise Edition license. | No|
 | `QA_ARTIFACTS_DIR` |`/tmp/gitlab-qa`| Path to a directory where artifacts (logs and screenshots) for failing tests will be saved. | No|
 | `DOCKER_HOST` |`http://localhost`| Docker host to run tests against. | No|
 | `CHROME_HEADLESS` |-  | When running locally, set to `false` to allow Chrome tests to be visible - watch your tests being run. | No|
@@ -83,8 +87,27 @@ For more details on the internals, please read the
 
 ## Running tests with a feature flag enabled
 
-It is possible to enable a feature flag before running tests. See the [QA
-framework documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/README.md#running-tests-with-a-feature-flag-enabled) for details.
+It is possible to enable or disable a feature flag before running tests.
+To test a Gitlab image with a feature flag enabled, run this command:
+```
+$ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --enable-feature feature_flag_name
+```
+
+To run a test with feature flag disabled, run this command:
+```
+$ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --disable-feature feature_flag_name
+```
+
+You an also test a GitLab image multiple times with different feature flag settings:
+```
+$ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0 --disable-feature feature_flag_name --enable-feature feature_flag_name
+```
+This will first disable `feature_flag_name` flag and run the tests and then enable it and run the tests again.
+
+You can pass any number of feature flag settings. The tests will run once for each setting.
+
+See the [QA framework documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/README.md#running-tests-with-a-feature-flag-enabled)
+for information on running the tests with different feature flag settings from the QA framework.
 
 ## Specifying the GitLab version
 
@@ -545,7 +568,7 @@ in the GitLab CE project).
 
 - `GITLAB_QA_DEV_ACCESS_TOKEN`: A valid personal access token for the
   `gitlab-qa-bot` on `dev.gitlab.org` with the `registry` scope.
-  This is used to pull the QA Docker from the Omnibus GitLab `dev` Container Registry.
+  This is used to pull the QA Docker image from the Omnibus GitLab `dev` Container Registry.
   If the variable isn't present, the QA image from Docker Hub will be used.
   This can be found in the shared 1Password vault.
 
@@ -560,6 +583,41 @@ $ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
 $ gitlab-qa Test::Instance::Staging
 ```
 
+### `Test::Instance::StagingGeo`
+
+This scenario tests that the Geo staging deployment (with [`staging.gitlab.com`](https://staging.gitlab.com) as the primary site and [`geo.staging.gitlab.com`](https://geo.staging.gitlab.com) as the secondary site) works as expected by running tests tagged `:geo` against it. This is done by spinning up a GitLab QA (`gitlab/gitlab-qa`) container and running the `QA::EE::Scenario::Test::Geo` scenario. Note that the Geo setup steps in the `QA::EE::Scenario::Test::Geo` scenario are skipped when testing a live Geo deployment.
+
+**Required user properties:**
+
+- The user must provide OAuth authorization on the secondary site before running Geo tests. This can be done via the authorization modal that appears after logging into the secondary node for the first time.
+
+- Some Geo tests require the user to have Admin access level (for example, the Geo Nodes API tests)
+
+**Required environment variables:**
+
+- `GITLAB_QA_ACCESS_TOKEN`: A valid personal access token with the `api` scope.
+  This is used to retrieve the version that staging is currently running.
+  This can be found in the shared 1Password vault.
+
+**Optional environment variables:**
+
+- `GITLAB_QA_DEV_ACCESS_TOKEN`: A valid personal access token for the
+  `gitlab-qa-bot` on `dev.gitlab.org` with the `registry` scope.
+  This is used to pull the QA Docker image from the Omnibus GitLab `dev` Container Registry.
+  If the variable isn't present, the QA image from Docker Hub will be used.
+  This can be found in the shared 1Password vault.
+
+Example:
+
+```
+$ export GITLAB_QA_ACCESS_TOKEN=your_api_access_token
+$ export GITLAB_QA_DEV_ACCESS_TOKEN=your_dev_registry_access_token
+$ export GITLAB_USERNAME="gitlab-qa"
+$ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
+
+$ gitlab-qa Test::Instance::StagingGeo
+```
+
 ### `Test::Instance::Production`
 
 This scenario functions the same as `Test::Instance::Staging`
@@ -633,6 +691,25 @@ $ export EE_LICENSE=$(cat /path/to/gitlab_license)
 $ gitlab-qa Test::Instance::Airgapped EE -- --tag smoke
 ```
 
+### `Test::Instance::Geo EE|<full image address>:nightly|latest|any_tag http://geo-primary.gitlab http://geo-secondary.gitlab`
+
+This scenario will run tests tagged `:geo` against a live Geo deployment, by spinning up a GitLab QA (`gitlab/gitlab-qa`)
+container and running the `QA::EE::Scenario::Test::Geo` scenario. Note that the Geo setup steps in the `QA::EE::Scenario::Test::Geo` scenario are skipped when testing a live Geo deployment. The URLs for the primary site and secondary site of the live Geo deployment must be provided as command line arguments.
+
+**Required user properties:**
+
+- The user must provide OAuth authorization on the secondary site before running Geo tests. This can be done via the authorization modal that appears after signing into the secondary node for the first time.
+
+- Some Geo tests require the user to have Admin access level (for example, the Geo Nodes API tests)
+
+Example:
+
+```
+$ export GITLAB_USERNAME="gitlab-qa"
+$ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
+
+$ gitlab-qa Test::Instance::Geo EE https://primary.gitlab.com https://secondary.gitlab.com
+```
 ----
 
 [Back to README.md](../README.md)

data/lib/gitlab/qa/component/specs.rb

@@ -27,26 +27,50 @@ module Gitlab
 
           name = "#{release.project_name}-qa-#{SecureRandom.hex(4)}"
 
-          @docker.run(release.qa_image, release.qa_tag, suite, *args) do |command|
-            command << "-t --rm --net=#{network || 'bridge'}"
+          feature_flag_sets = []
 
-            env.merge(Runtime::Env.variables).each do |key, value|
-              command.env(key, value)
-            end
+          # When `args` includes `[..., "--disable-feature", "a", "--enable-feature", "b", ...]`
+          # `feature_flag_sets` will be set to `[["--disable-feature", "a"], ["--enable-feature", "b"]]`
+          # This will result in tests running twice, once with each feature.
+          while (index = args&.index { |x| x =~ /--.*-feature/ })
+            feature_flag_sets << args.slice!(index, 2)
+          end
 
-            command.volume('/var/run/docker.sock', '/var/run/docker.sock')
-            command.volume(File.join(Runtime::Env.host_artifacts_dir, name), File.join(Docker::Volumes::QA_CONTAINER_WORKDIR, 'tmp'))
+          # When `args` do not have either "--disable-feature" or "--enable-feature", we
+          # add [] so that test is run exactly once.
+          feature_flag_sets << [] unless feature_flag_sets.any?
 
-            @volumes.to_h.each do |to, from|
-              command.volume(to, from)
-            end
+          feature_flag_sets.each do |feature_flag_set|
+            @docker.run(release.qa_image, release.qa_tag, suite, *args_with_flags(args, feature_flag_set)) do |command|
+              command << "-t --rm --net=#{network || 'bridge'}"
+
+              env.merge(Runtime::Env.variables).each do |key, value|
+                command.env(key, value)
+              end
+
+              command.volume('/var/run/docker.sock', '/var/run/docker.sock')
+              command.volume(File.join(Runtime::Env.host_artifacts_dir, name), File.join(Docker::Volumes::QA_CONTAINER_WORKDIR, 'tmp'))
+
+              @volumes.to_h.each do |to, from|
+                command.volume(to, from)
+              end
 
-            command.name(name)
+              command.name(name)
+            end
           end
         end
 
         private
 
+        def args_with_flags(args, feature_flag_set)
+          return args if feature_flag_set.empty?
+
+          puts "Running with feature flag: #{feature_flag_set.join(' ')}"
+
+          args_with_f = args.dup
+          args_with_f.insert(1, *feature_flag_set)
+        end
+
         def skip_tests?
           Runtime::Scenario.attributes.include?(:run_tests) && !Runtime::Scenario.run_tests
         end

data/lib/gitlab/qa/runtime/env.rb

@@ -6,6 +6,8 @@ module Gitlab
       module Env
         extend self
 
+        # Variables that are used in tests and are passed through to the docker container that executes the tests.
+        # These variables should be listed in /docs/what_tests_can_be_run.md#supported-gitlab-environment-variables
         ENV_VARIABLES = {
           'QA_REMOTE_GRID' => :remote_grid,
           'QA_REMOTE_GRID_USERNAME' => :remote_grid_username,

data/lib/gitlab/qa/scenario/test/instance/geo.rb

@@ -8,9 +8,6 @@ module Gitlab
 
           class Geo < Scenario::Template
             def perform(release, primary_address, secondary_address, *rspec_args)
-              # Geo requires an EE license
-              Runtime::Env.require_license!
-
               Component::Specs.perform do |specs|
                 specs.suite = 'QA::EE::Scenario::Test::Geo'
                 specs.release = QA::Release.new(release)

data/lib/gitlab/qa/version.rb

@@ -1,5 +1,5 @@
 module Gitlab
   module QA
-    VERSION = '5.16.0'.freeze
+    VERSION = '5.17.0'.freeze
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-qa
 version: !ruby/object:Gem::Version
-  version: 5.16.0
+  version: 5.17.0
 platform: ruby
 authors:
 - Grzegorz Bizon
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2020-07-14 00:00:00.000000000 Z
+date: 2020-07-28 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: climate_control