gitlab-qa 9.0.0 → 9.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fff29a089097412047c17a713152bab09d779b6b81632e2762501c2ea37eeed0
-  data.tar.gz: 74c1d481f56ff0497e14cac6f235b282aa121031be0a77dab0a95bf0b490fdc3
+  metadata.gz: 6e4cbee0fd80c19ab1e9f2de614f85cb9139fa83a7a50e5aa81d6e81eddd8954
+  data.tar.gz: f31346c57dc8b0dd88bad1f528f76357782dd7f5f83216363d97a11cbefffe66
 SHA512:
-  metadata.gz: b6d43ecfbe3359130fc691e1057113da2705f551d0149f5183192451b42c4608dd3daf6760a304c3ef710a0ed03e7a232e21ed6c93006fa873c55a37746f6d10
-  data.tar.gz: 0f4eb1b06e9bcfd11c6782cba8da19c2ac489c4adf5f14b43e6e2be823bc8f71b2be04fa7b5a6eca4c018cf805a04e1794b4a3676f081c999852cbe4ff4a2d4b
+  metadata.gz: d305810dbc78df5704c7aa1f237db5844e9d17ab48c1d5e397d00a140569d8635578b715ab5928f8bf2e3bdf69fca63a72710ed3af3f01cdb733ad8b7676e89a
+  data.tar.gz: 96dfef1fdcc8808d54adb7d9db417905a2b8752e8cf4fdad2c6eb70e8cdf7c0a47e88f453fb2323bf59e2336e5f29db73fbbefb0a9049c291142c687d37b99bf

data/.gitlab/ci/jobs/base.gitlab-ci.yml

@@ -112,8 +112,13 @@ variables:
     - 'echo "Running: bundle exec exe/gitlab-qa ${QA_SCENARIO:=Test::Instance::Image} ${RELEASE:=$DEFAULT_RELEASE} $GITLAB_QA_OPTIONS -- $QA_TESTS $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS"'
     - bundle exec exe/gitlab-qa ${QA_SCENARIO:=Test::Instance::Image} ${RELEASE:=$DEFAULT_RELEASE} $GITLAB_QA_OPTIONS -- $QA_TESTS $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS || test_run_exit_code=$?
     - bundle exec exe/gitlab-qa-report --update-screenshot-path "gitlab-qa-run-*/**/rspec-*.xml"
-    - export GITLAB_QA_ACCESS_TOKEN="$GITLAB_QA_PRODUCTION_ACCESS_TOKEN"
-    - if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true; fi
+    # Back-compatibility until we migrate all GITLAB_QA_PRODUCTION_ACCESS_TOKEN to QA_REPORT_RESULT_TOKEN.
+    # See https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/175#note_1281196581 for context.
+    - export GITLAB_QA_ACCESS_TOKEN="${QA_REPORT_RESULT_TOKEN:-$GITLAB_QA_PRODUCTION_ACCESS_TOKEN}"
+    - |
+      if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then
+        exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true;
+      fi
     - exit $test_run_exit_code
 
 # For jobs that shouldn't report results in issues, e.g., manually run custom jobs
@@ -129,8 +134,13 @@ variables:
 
     - bundle exec exe/gitlab-qa ${QA_SCENARIO:=Test::Instance::Image} ${RELEASE:=$DEFAULT_RELEASE} $GITLAB_QA_OPTIONS_COMBINED -- $QA_TESTS $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS || test_run_exit_code=$?
     - bundle exec exe/gitlab-qa-report --update-screenshot-path "gitlab-qa-run-*/**/rspec-*.xml"
-    - export GITLAB_QA_ACCESS_TOKEN="$GITLAB_QA_PRODUCTION_ACCESS_TOKEN"
-    - if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true; fi
+    # Back-compatibility until we migrate all GITLAB_QA_PRODUCTION_ACCESS_TOKEN to QA_REPORT_RESULT_TOKEN.
+    # See https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/175#note_1281196581 for context.
+    - export GITLAB_QA_ACCESS_TOKEN="${QA_REPORT_RESULT_TOKEN:-$GITLAB_QA_PRODUCTION_ACCESS_TOKEN}"
+    - |
+      if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then
+        exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true;
+      fi
     - exit $test_run_exit_code
 
 # The Test::Omnibus::Update scenarios require the release to be specified twice, which can't be done dynamically using the `variables` parameter
@@ -140,8 +150,13 @@ variables:
     - 'echo "Running: bundle exec exe/gitlab-qa Test::Omnibus::Update ${RELEASE:=$DEFAULT_RELEASE} ${RELEASE:=$DEFAULT_RELEASE} $GITLAB_QA_OPTIONS -- $QA_TESTS $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS"'
     - bundle exec exe/gitlab-qa Test::Omnibus::Update ${RELEASE:=$DEFAULT_RELEASE} ${RELEASE:=$DEFAULT_RELEASE} $GITLAB_QA_OPTIONS -- $QA_TESTS $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS || test_run_exit_code=$?
     - bundle exec exe/gitlab-qa-report --update-screenshot-path "gitlab-qa-run-*/**/rspec-*.xml"
-    - export GITLAB_QA_ACCESS_TOKEN="$GITLAB_QA_PRODUCTION_ACCESS_TOKEN"
-    - if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true; fi
+    # Back-compatibility until we migrate all GITLAB_QA_PRODUCTION_ACCESS_TOKEN to QA_REPORT_RESULT_TOKEN.
+    # See https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/175#note_1281196581 for context.
+    - export GITLAB_QA_ACCESS_TOKEN="${QA_REPORT_RESULT_TOKEN:-$GITLAB_QA_PRODUCTION_ACCESS_TOKEN}"
+    - |
+      if [ "$TOP_UPSTREAM_SOURCE_REF" == $TOP_UPSTREAM_DEFAULT_BRANCH ] || [[ "$TOP_UPSTREAM_SOURCE_JOB" == https://ops.gitlab.net* ]]; then
+        exe/gitlab-qa-report --report-results "gitlab-qa-run-*/**/rspec-*.json" --test-case-project "$QA_TESTCASES_REPORTING_PROJECT" --results-issue-project "$QA_TEST_RESULTS_ISSUES_PROJECT" || true;
+      fi
     - exit $test_run_exit_code
 
 .high-capacity:
@@ -171,7 +186,9 @@ generate_test_session:
     paths:
       - REPORT_ISSUE_URL
   script:
-    - export GITLAB_QA_ACCESS_TOKEN="$GITLAB_QA_PRODUCTION_ACCESS_TOKEN"
+    # Back-compatibility until we migrate all GITLAB_QA_PRODUCTION_ACCESS_TOKEN to QA_TEST_SESSION_TOKEN.
+    # See https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/175#note_1281240424 for context.
+    - export GITLAB_QA_ACCESS_TOKEN="${QA_TEST_SESSION_TOKEN:-$GITLAB_QA_PRODUCTION_ACCESS_TOKEN}"
     - bundle exec exe/gitlab-qa-report --generate-test-session "gitlab-qa-run-*/**/rspec-*.json" --project "$QA_TESTCASE_SESSIONS_PROJECT"
 
 relate_test_failures:
@@ -189,7 +206,9 @@ relate_test_failures:
     # The --dry-run can be set to modify the behavior of `exe/gitlab-qa-report --relate-failure-issue` without releasing a new gem version.
     QA_FAILURES_REPORTER_OPTIONS: ""
   script:
-    - export GITLAB_QA_ACCESS_TOKEN="$GITLAB_QA_PRODUCTION_ACCESS_TOKEN"
+    # Back-compatibility until we migrate all GITLAB_QA_PRODUCTION_ACCESS_TOKEN to QA_REPORT_RESULT_TOKEN.
+    # See https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/issues/175#note_1281196581 for context.
+    - export GITLAB_QA_ACCESS_TOKEN="${QA_REPORT_RESULT_TOKEN:-$GITLAB_QA_PRODUCTION_ACCESS_TOKEN}"
     - bundle exec exe/gitlab-qa-report --relate-failure-issue "gitlab-qa-run-*/**/rspec-*.json" --project "$QA_FAILURES_REPORTING_PROJECT" --max-diff-ratio "$QA_FAILURES_MAX_DIFF_RATIO" $QA_FAILURES_REPORTER_OPTIONS
 
 .notify_slack:

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    gitlab-qa (9.0.0)
+    gitlab-qa (9.1.0)
       activesupport (~> 6.1)
       gitlab (~> 4.18.0)
       http (~> 5.0)

data/docs/release_process.md

@@ -36,6 +36,44 @@ Note: The `gem-release` job uses:
 
 ## Post-release maintenance
 
-Please note that `gitlab-qa` version in `gitlab-org/gitlab` project will be updated automatically by [renovate-gitlab-bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot). However, for live environment pipelines we need to specify the version in `pipeline-common` project manually. Remember to open an MR updating `GITLAB_QA_VERSION` value in [base.gitlab-ci.yml](https://gitlab.com/gitlab-org/quality/pipeline-common/-/blob/master/ci/base.gitlab-ci.yml#L4) shortly after the new version is released.
+Please note that `gitlab-qa` version in `gitlab-org/gitlab` project will be updated automatically by [renovate-gitlab-bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot). However, for live environment pipelines we need to specify the version in [pipeline-common](https://gitlab.com/gitlab-org/quality/pipeline-common) project manually. Remember to open an MR updating `GITLAB_QA_VERSION` value in [base.gitlab-ci.yml](https://gitlab.com/gitlab-org/quality/pipeline-common/-/blob/master/ci/base.gitlab-ci.yml#L4) shortly after the new version is released.
+
+## Flowchart
+
+The flowchart below outlines a high-level overview of the `gitlab-qa` release process, along with post-release maintenance items required
+to update the `gitlab-qa` version for our pipelines.
+
+#### Key:
+- Rectangles represent manual actions
+- Hexagons represent automated actions
+
+```mermaid
+flowchart LR
+    subgraph gitlab-qa
+      A[Update lib/gitlab/qa/version.rb] --> B[Update Gemfile.lock]
+      B --> C[Push branch]
+      C --> D[Open MR with release template]
+      D --> E[Review and merge]
+      E --> F{{Tag created by gem-release job}}
+      F --> G[Update tag release notes]
+    end
+    subgraph gitlab-org/gitlab
+      H{{gitlab-renovate-bot checks for new gitlab-qa version}} --> I{{GitLab Dependency Bot opens MR}} 
+      I --> J[Review and merge] 
+      J --> K{{gitlab-qa version updated}}
+    end
+    subgraph pipeline-common
+      L[Update GITLAB_QA_VERSION in ci/base.gitlab-ci.yml] --> M[Push branch]
+      M --> N[Open MR]
+      N --> O[Review and merge]
+      O --> P[Follow pipeline-common release process]
+    end
+    gitlab-qa --> gitlab-org/gitlab & pipeline-common
+
+    classDef linkNode color:blue,text-decoration:underline;
+    class P linkNode;
+
+    click P "https://gitlab.com/gitlab-org/quality/pipeline-common/-/tree/master#release-process"
+```
 
 [`lib/gitlab/qa/version.rb`]: https://gitlab.com/gitlab-org/gitlab-qa/blob/master/lib/gitlab/qa/version.rb#L3

data/docs/what_tests_can_be_run.md

@@ -55,7 +55,7 @@ All environment variables used by GitLab QA should be defined in [`lib/gitlab/qa
 | `GITLAB_ADMIN_USERNAME` |-  | Admin username to use when adding a license. | No|
 | `GITLAB_ADMIN_PASSWORD` |-  | Admin password to use when adding a license. | No|
 | `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_ACCESS_TOKEN`|-  | A valid personal access token with the `api` scope. This allows tests to use the API without having to create a new personal access token first. It is also used to check what version [deployed environments](https://gitlab.com/gitlab-org/quality/pipeline-common/-/blob/master/ci/dot-com/README.md#projects) are currently running. Existing tokens for each environment 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|
 | `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|
@@ -1027,25 +1027,21 @@ These variables are available at 1Password QA Vault.
 
 ### `Test::Integration::RegistryTLS EE`
 
-It requires GitLab's TLS certificate found on the [`tls_certificates`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/tls_certificates/gitlab/gitlab.test.crt) folder
-
-```shell
-$ export GITLAB_TLS_CERTIFICATE=$(cat /path/to/certificate.crt)
-```
+It uses GitLab's TLS certificate found in the [`tls_certificates`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/tls_certificates/gitlab/gitlab.test.crt) folder.
 
 To run a scenario with an insecure registry enabled use `Test::Integration::Registry EE` instead (it does not require the above certificate).
 
-### Test::Integration::RegistryTLS EE --omnibus-config object_storage
+### `Test::Integration::RegistryTLS EE --omnibus-config object_storage`
 
 This scenario is a composition of two orchestrated scenarios. It tests the container registry (TLS-enabled) integrated with an object storage backend.
 
 An example would be to pass the option `--omnibus-config object_storage_aws` and the registry will be pulling and pushing images using AWS Cloud Storage as a storage backend.
 
 ```shell
-GITLAB_TLS_CERTIFICATE=$(cat /path/to/certificate.crt) gitlab-qa Test::Integration::RegistryTLS EE --omnibus-config object_storage_aws
+gitlab-qa Test::Integration::RegistryTLS EE --omnibus-config object_storage_aws
 ```
 
-### Test::Instance::Image EE --omnibus-config decomposition_single_db
+### `Test::Instance::Image EE --omnibus-config decomposition_single_db`
 
 This scenario is to run tests against a GitLab instance with a [decomposed database](https://gitlab.com/groups/gitlab-org/-/epics/6160) using a single database:
 
@@ -1053,7 +1049,7 @@ This scenario is to run tests against a GitLab instance with a [decomposed datab
 gitlab-qa Test::Instance::Image EE --omnibus-config decomposition_single_db
 ```
 
-### Test::Instance::Image EE --omnibus-config decomposition_multiple_db
+### `Test::Instance::Image EE --omnibus-config decomposition_multiple_db`
 
 This scenario is to run tests against a GitLab instance with a [decomposed database](https://gitlab.com/groups/gitlab-org/-/epics/6160) using multiple databases:
 

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

@@ -4,7 +4,7 @@ module Gitlab
   module QA
     module Component
       class Preprod < Staging
-        ADDRESS = 'https://pre.gitlab.com'
+        ADDRESS = Runtime::Env.preprod_url
       end
     end
   end

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

@@ -4,7 +4,7 @@ module Gitlab
   module QA
     module Component
       class Production < Staging
-        ADDRESS = 'https://gitlab.com'
+        ADDRESS = Runtime::Env.production_url
       end
     end
   end

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

@@ -4,7 +4,7 @@ module Gitlab
   module QA
     module Component
       class Release < Staging
-        ADDRESS = 'https://release.gitlab.net'
+        ADDRESS = Runtime::Env.release_url
       end
     end
   end

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

@@ -8,8 +8,8 @@ module Gitlab
   module QA
     module Component
       class Staging
-        ADDRESS = 'https://staging.gitlab.com'
-        GEO_SECONDARY_ADDRESS = 'https://geo.staging.gitlab.com'
+        ADDRESS = Runtime::Env.staging_url
+        GEO_SECONDARY_ADDRESS = Runtime::Env.geo_staging_url
 
         def self.release
           QA::Release.new(image)

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

@@ -4,8 +4,8 @@ module Gitlab
   module QA
     module Component
       class StagingRef < Staging
-        ADDRESS = 'https://staging-ref.gitlab.com'
-        GEO_SECONDARY_ADDRESS = 'https://geo.staging-ref.gitlab.com'
+        ADDRESS = Runtime::Env.staging_ref_url
+        GEO_SECONDARY_ADDRESS = Runtime::Env.geo_staging_ref_url
       end
     end
   end

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

@@ -373,6 +373,34 @@ module Gitlab
           env_var_value_if_defined('CUSTOMER_PORTAL_URL') || 'https://customers.staging.gitlab.com'
         end
 
+        def geo_staging_url
+          env_var_value_if_defined('GEO_STAGING_URL') || 'https://geo.staging.gitlab.com'
+        end
+
+        def staging_url
+          env_var_value_if_defined('STAGING_URL') || 'https://staging.gitlab.com'
+        end
+
+        def staging_ref_url
+          env_var_value_if_defined('STAGING_REF_URL') || 'https://staging-ref.gitlab.com'
+        end
+
+        def geo_staging_ref_url
+          env_var_value_if_defined('GEO_STAGING_REF_URL') || 'https://geo.staging-ref.gitlab.com'
+        end
+
+        def release_url
+          env_var_value_if_defined('RELEASE_URL') || 'https://release.gitlab.net'
+        end
+
+        def production_url
+          env_var_value_if_defined('PRODUCTION_URL') || 'https://gitlab.com'
+        end
+
+        def preprod_url
+          env_var_value_if_defined('PREPROD_URL') || 'https://pre.gitlab.com'
+        end
+
         def allow_separate_ci_database
           enabled?(env_var_value_if_defined('GITLAB_ALLOW_SEPARATE_CI_DATABASE'), default: false)
         end

data/lib/gitlab/qa/version.rb

@@ -2,6 +2,6 @@
 
 module Gitlab
   module QA
-    VERSION = '9.0.0'
+    VERSION = '9.1.0'
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-qa
 version: !ruby/object:Gem::Version
-  version: 9.0.0
+  version: 9.1.0
 platform: ruby
 authors:
 - GitLab Quality
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2023-02-03 00:00:00.000000000 Z
+date: 2023-02-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: climate_control