gitlab-qa 8.12.0 → 8.13.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bee7c1ce41e9ceeeb14546a8983a5c3f90b3da4f6a3f32505bc77c08f0e484a9
-  data.tar.gz: dd74a1afa61040fc2110c0f3f63a381f8b1da4f07fb82b4629cdc979378ec67d
+  metadata.gz: eff4fd2e6e9b9ab05a26c87b04de43cc2724ff6bbfcdfa55309f6ea4dd6ca22f
+  data.tar.gz: f7c23ec439a8d5bbbcffac5942f9af3bd11761df457d6bd5316dcc2accb14d2e
 SHA512:
-  metadata.gz: d22ff4d7fa0452bac353fcd80a68f8c2bd1598f0515483c4f0a749c6ab3f225bd4d763cf17ce21f7c1a446530d254ace11a2a5c5d6a581e985572c58ce07da80
-  data.tar.gz: b0fe8a3cfbefcd39f971eab382171df61691d920303f8f89ab4b3a04bcb5b7ac4ff4586bb08196dbe7f1ba2f0e98ea8ce1deca4822407d22b80891e6dc306eaf
+  metadata.gz: a796e6144671878b4940c6cd529abe4bff1f2b38fe06914c069c4291932d27c2b7527603a625d5a6631f42131e87d48bd63773b7abc62a55628f006863f3acab
+  data.tar.gz: eab90710e729b81e2ba9716462327bf770289c17c197f7743b79fb88023c6711e84751f1bb02fd62414f2ff1ec327b0e318eac060fba28f3ebaade42ee0b5847

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    gitlab-qa (8.12.0)
+    gitlab-qa (8.13.1)
       activesupport (~> 6.1)
       gitlab (~> 4.18.0)
       http (~> 5.0)
@@ -37,7 +37,7 @@ GEM
       colored2 (~> 3.1)
     crack (0.4.5)
       rexml
-    danger (9.0.0)
+    danger (9.1.0)
       claide (~> 1.0)
       claide-plugins (>= 0.9.2)
       colored2 (~> 3.1)
@@ -148,11 +148,11 @@ GEM
       method_source (~> 1.0)
     public_suffix (5.0.0)
     racc (1.6.0)
-    rack (3.0.0)
+    rack (3.0.1)
     rainbow (3.1.1)
     rake (13.0.6)
     rchardet (1.8.0)
-    regexp_parser (2.6.0)
+    regexp_parser (2.6.1)
     reverse_markdown (2.1.1)
       nokogiri
     rexml (3.2.5)
@@ -230,7 +230,7 @@ GEM
     webrick (1.7.0)
     yard (0.9.28)
       webrick (~> 1.7.0)
-    zeitwerk (2.6.1)
+    zeitwerk (2.6.6)
 
 PLATFORMS
   ruby
@@ -247,4 +247,4 @@ DEPENDENCIES
   webmock (= 3.7.0)
 
 BUNDLED WITH
-   2.3.9
+   2.3.24

data/docs/what_tests_can_be_run.md

@@ -79,9 +79,9 @@ All environment variables used by GitLab QA should be defined in [`lib/gitlab/qa
 | `QA_SLOW_CONNECTION_THROUGHPUT_KBPS` | `32` | The maximum throughput (in kbps) of the simulated slow connection. | No|
 | `QA_SKIP_PULL` | `false` | Set to `true` to skip pulling docker images (e.g., to use one you built locally). | No|
 | `QA_GENERATE_ALLURE_REPORT` | `false` | When running on CI, set to `true` to generate allure reports | No|
-| `QA_EXPORT_TEST_METRICS` | `true` | When running on CI, set to `true` to export test metrics to influxdb | No|
-| `QA_INFLUXDB_URL` |- | Influxdb url for test metrics reporting | No|
-| `QA_INFLUXDB_TOKEN` |- | Influxdb token for test metrics reporting | No|
+| `QA_EXPORT_TEST_METRICS` | `true` | When running on CI, set to `true` to export test metrics to InfluxDB | No|
+| `QA_INFLUXDB_URL` |- | InfluxDB URL for test metrics reporting | No|
+| `QA_INFLUXDB_TOKEN` |- | InfluxDB token for test metrics reporting | No|
 | `QA_RUN_TYPE` |- | QA run type like `staging-full`, `canary`, `production` etc. Used in test metrics reporting | No|
 | `QA_VALIDATE_RESOURCE_REUSE` | `false` | Set to `true` to [validate resource reuse](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/resources.html#reusable-resources) after a test suite | No |
 | `QA_USE_PUBLIC_IP_API` | `false` | When performing Instance tests against a remote/pre-existing instance, use an API to detect the public API for requests coming from gitlab-qa.  Used by tests that exercise IP-address restrictions and similar
@@ -100,26 +100,31 @@ All environment variables used by GitLab QA should be defined in [`lib/gitlab/qa
 | `GITLAB_INITIAL_ROOT_PASSWORD` | `5iveL!fe` | Initial root password for Omnibus installations | No|
 | `COLORIZED_LOGS` | `false` | Colors GitLab QA and test logs to improve readability | No|
 | `QA_DOCKER_ADD_HOSTS` |- | Comma separated list of hosts to add to /etc/hosts in docker container | No|
+| `FIPS` |- | Set to `1` or `true` to indicate that the test is running under FIPS mode | No|
 
 ## [Supported Remote Grid environment variables](./running_against_remote_grid.md)
 
 ## Running tests with a feature flag enabled
 
 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:
-```
+To test a GitLab image with a feature flag enabled, run this command:
+
+```shell
 $ 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:
-```
+
+```shell
 $ 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:
-```
+You can also test a GitLab image multiple times with different feature flag settings:
+
+```shell
 $ 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.
@@ -149,13 +154,13 @@ by providing the full image name, or an abbreviation followed by the image tag.
 For example, to test GitLab version `12.4.0-ee`, the image tag is [`12.4.0-ee.0`](https://hub.docker.com/layers/gitlab/gitlab-ee/12.4.0-ee.0/images/sha256-65df19d8abbb0debdccb64bfe96871563806098cd84da0b818ae8cfdd928b9aa)
 and so you could run the tests with the command:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0
 ```
 
 Or with the command:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image EE:12.4.0-ee.0
 ```
 
@@ -163,7 +168,7 @@ If you only provide the abbreviation, it will run the tests against the latest n
 
 For example, the following command would use the image named `gitlab/gitlab-ee:nightly`
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image EE
 ```
 
@@ -176,7 +181,7 @@ To run EE tests, the `EE_LICENSE` environment variable needs to be set:
 By default, `gitlab-qa` infers the QA image to use based on the GitLab image.
 For instance, if you run the following:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image gitlab/gitlab-ee:12.4.0-ee.0
 ```
 
@@ -188,19 +193,19 @@ In some cases, you'll want to use a specific QA image instead of letting
 when you're doing local debugging/testing and you want to control the QA image
 name, or in the CI where the QA image might be built by a project (e.g.
 `gitlab-org/gitlab`, and the GitLab image might be built by another project
-(e.g. `gitlab-org/omnibus-gitlab-mirror`).
+(e.g. `gitlab-org/omnibus-gitlab-mirror`)).
 
 To specify the QA image to use, pass the `--qa-image QA_IMAGE` option,
 as follows:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image --qa-image registry.gitlab.com/gitlab-org/gitlab/gitlab-ee-qa:branch-name EE
 ```
 
 Additionally, setting the `$QA_IMAGE` environment variable achieve the same result,
 without needing to pass the `--qa-image` option:
 
-```
+```shell
 $ export QA_IMAGE="registry.gitlab.com/gitlab-org/gitlab/gitlab-ee-qa:branch-name"
 $ gitlab-qa Test::Instance::Image EE
 ```
@@ -259,7 +264,7 @@ GitLab project).
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Image CE
 ```
 
@@ -275,7 +280,7 @@ This spins up a GitLab Docker container based on the given edition or image:
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Omnibus::Image CE
 ```
 
@@ -291,7 +296,7 @@ This tests that:
 
 Example:
 
-```
+```shell
 # Update from gitlab/gitlab-ce:latest to gitlab/gitlab-ce:nightly
 $ gitlab-qa Test::Omnibus::Update CE
 
@@ -314,14 +319,35 @@ This tests that:
 
 Example:
 
-```
-# Ugrade from gitlab/gitlab-ce:nightly to gitlab/gitlab-ee:nightly
+```shell
+# Upgrade from gitlab/gitlab-ce:nightly to gitlab/gitlab-ee:nightly
 $ gitlab-qa Test::Omnibus::Upgrade CE
 
-# Ugrade from gitlab/gitlab-ce:my-custom-tag to gitlab/gitlab-ee:my-custom-tag
+# Upgrade from gitlab/gitlab-ce:my-custom-tag to gitlab/gitlab-ee:my-custom-tag
 $ gitlab-qa Test::Omnibus::Upgrade gitlab/gitlab-ce:my-custom-tag
 ```
 
+### `Test::Omnibus::UpdateFromPrevious <full image address> <current_version> <major|minor>`
+
+Scenario verifies upgrade from previous (major|minor) version to current release.
+
+- Deploys previous (major|minor) version and runs Smoke test suite
+  to populate data in database before upgrade
+- Generates upgrade path following current GitLab recommendations
+  from ['gitlab-com/support/toolbox/upgrade-path'](https://gitlab.com/gitlab-com/support/toolbox/upgrade-path/-/raw/main/upgrade-path.yml) project
+- Gradually upgrades GitLab instances to `<current_version>`
+  associated with provided `<full image address>` and runs tests against it
+
+Example:
+
+```shell
+# Minor upgrade - will perform upgrade 15.5.x -> gitlab-ee:dev-tag
+$ gitlab-qa Test::Omnibus::UpdateFromPrevious gitlab-ee:dev-tag 15.6.0-pre minor
+
+# Major upgrade - will perform upgrades 14.10.x -> 15.0.x -> 15.4.x -> gitlab-ee:dev-tag (15.6.0-pre)
+$ gitlab-qa Test::Omnibus::UpdateFromPrevious gitlab-ee:dev-tag 15.6.0-pre major
+```
+
 ### `Test::Integration::Geo EE|<full image address>`
 
 This tests that two GitLab Geo instances work as expected.
@@ -342,7 +368,7 @@ EE project).
 
 Example:
 
-```
+```shell
 $ export EE_LICENSE=$(cat /path/to/Geo.gitlab_license)
 $ gitlab-qa Test::Integration::Geo EE
 ```
@@ -364,7 +390,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::GitalyCluster EE
 ```
 
@@ -372,7 +398,7 @@ $ gitlab-qa Test::Integration::GitalyCluster EE
 
 This tests that a GitLab Instance works as expected with [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) enabled.
 
-The scenario configures the instance by setting up these instructions [here](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/pages.md) through enabling `gitlab_pages['enable'] = true;`, setting up an external url and the adding of the GitLab Pages hostname and GitLab Instance IP into the `etc/hostfile` on the container that runs the specs so it can access the page on the GitLab container.
+The scenario configures the instance by setting up these instructions [here](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/pages.md) through enabling `gitlab_pages['enable'] = true;`, setting up an external URL and the adding of the GitLab Pages hostname and GitLab Instance IP into the `etc/hostfile` on the container that runs the specs, so it can access the page on the GitLab container.
 
 To run tests against the GitLab container, a GitLab QA (`gitlab/gitlab-qa`)
 container is spun up and tests are run from it by running the
@@ -380,7 +406,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::GitlabPages EE
 ```
 
@@ -409,7 +435,7 @@ In EE, both the GitLab standard and LDAP credentials are needed:
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::LDAPNoTLS CE
 
 # For EE
@@ -423,10 +449,11 @@ $ gitlab-qa Test::Integration::LDAPNoTLS EE
 ### `Test::Integration::LDAPTLS CE|EE|<full image address>`
 
 This tests that a TLS enabled GitLab instance works as expected with an external TLS enabled LDAP server.
-The self signed TLS certificate used for the Gitlab instance and the private key is located at: [`gitlab-org/gitlab-qa@tls_certificates/gitlab`][test-integration-ldap-tls-certs]
+The self-signed TLS certificate used for the GitLab instance and the private key is located at: [`gitlab-org/gitlab-qa@tls_certificates/gitlab`][test-integration-ldap-tls-certs]
 
-The certificate was generated with openssl using this command:
-```
+The certificate was generated with OpenSSL using this command:
+
+```shell
 openssl req -x509 -newkey rsa:4096 -keyout gitlab.test.key -out gitlab.test.crt -days 3650 -nodes -subj "/C=US/ST=CA/L=San Francisco/O=GitLab/OU=Org/CN=gitlab.test"
 ```
 
@@ -450,7 +477,7 @@ In EE, both the GitLab standard and LDAP credentials are needed:
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::LDAPTLS CE
 
 # For EE
@@ -477,7 +504,7 @@ container is spun up and tests are run from it by running the
 [`gitlab-org/gitlab@qa/qa/scenario/test/integration/ldap_no_server.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/scenario/test/integration/ldap_no_server.rb)
 in the GitLab project).
 
-In GiLab project, both the GitLab standard and LDAP credentials are needed:
+In GitLab project, both the GitLab standard and LDAP credentials are needed:
 
 1. The first is used to login as an Admin to enter in the GitLab license.
 2. The second is used to conduct LDAP-related tasks
@@ -488,7 +515,7 @@ In GiLab project, both the GitLab standard and LDAP credentials are needed:
 
 Example:
 
-```
+```shell
 $ export EE_LICENSE=$(cat /path/to/GitLab.gitlab_license)
 
 $ gitlab-qa Test::Integration::LDAPNoServer EE
@@ -513,7 +540,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ export EE_LICENSE=$(cat /path/to/Geo.gitlab_license)
 
 $ gitlab-qa Test::Integration::GroupSAML EE
@@ -539,7 +566,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::InstanceSAML CE
 
 # For EE
@@ -565,7 +592,7 @@ in the GitLab project).
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::Mattermost CE
 
 # For EE
@@ -584,7 +611,7 @@ To run Packages tests, you may [configure Omnibus](configuring_omnibus.md) to us
 
 Example:
 
-```
+```shell
 $ export EE_LICENSE=$(cat /path/to/Geo.gitlab_license)
 
 $ gitlab-qa Test::Instance::Image EE --omnibus-config packages
@@ -616,7 +643,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::Praefect EE
 ```
 
@@ -635,7 +662,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::SMTP CE
 ```
 
@@ -660,7 +687,7 @@ These values can be found in the shared GitLab QA 1Password vault.
 
 Example:
 
-```
+```shell
 $ export JIRA_ADMIN_USERNAME=<jira_admin_username>
 $ export JIRA_ADMIN_PASSWORD=<jira_admin_password>
 
@@ -680,7 +707,7 @@ container is spun up and tests are run from it by running the
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Integration::Integrations EE
 ```
 
@@ -693,11 +720,11 @@ To run tests against the GitLab instance, a GitLab QA (`gitlab/gitlab-qa`)
 container is spun up and tests are run from it by running the
 `Test::Instance` scenario (located under
 [`gitlab-org/gitlab/qa/qa/scenario/test/instance.rb`][test-instance] in the
-in the GitLab project).
+GitLab project).
 
 Example:
 
-```
+```shell
 $ export GITLAB_USERNAME=your_username
 $ export GITLAB_PASSWORD=your_password
 
@@ -720,7 +747,7 @@ To run tests against the GitLab instance, a GitLab QA (`gitlab/gitlab-qa`)
 container is spun up and tests are run from it by running the
 `Test::Instance` scenario (located under
 [`gitlab-org/gitlab/qa/qa/scenario/test/instance.rb`][test-instance] in the
-in the GitLab project).
+GitLab project).
 
 **Required environment variables:**
 
@@ -760,7 +787,7 @@ in the GitLab project).
 
 An example of how to run the smoke tests:
 
-```
+```shell
 $ export GITLAB_QA_USER_AGENT="<value from 1Password>"
 $ export GITLAB_QA_ACCESS_TOKEN="<value from 1Password>"
 $ export GITLAB_QA_DEV_ACCESS_TOKEN="<value from 1Password>"
@@ -784,7 +811,7 @@ To run tests against the GitLab instance, a GitLab QA (`gitlab/gitlab-qa`)
 container is spun up and tests are run from it by running the
 `Test::Instance` scenario (located under
 [`gitlab-org/gitlab/qa/qa/scenario/test/instance.rb`][test-instance] in the
-in the GitLab project).
+GitLab project).
 
 **Required environment variables:**
 
@@ -802,7 +829,7 @@ in the GitLab project).
 
 Example:
 
-```
+```shell
 $ 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"
@@ -837,7 +864,7 @@ This scenario tests that the Geo staging deployment (with [`staging.gitlab.com`]
 
 Example:
 
-```
+```shell
 $ 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"
@@ -852,7 +879,7 @@ This scenario tests that the Geo staging deployment (with [`staging-ref.gitlab.c
 
 Scenario requirements are the same as [`Test::Instance::StagingGeo`](#testinstancestaginggeo) described above.
 
-```
+```shell
 $ 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"
@@ -902,7 +929,7 @@ to the canary fleet.
 
 An example of how to run the smoke tests:
 
-```
+```shell
 $ export GITLAB_QA_USER_AGENT="<value from 1Password>"
 $ export GITLAB_QA_ACCESS_TOKEN="<value from 1Password>"
 $ export GITLAB_QA_DEV_ACCESS_TOKEN="<value from 1Password>"
@@ -939,11 +966,11 @@ To run tests against the GitLab instance, a GitLab QA (`gitlab/gitlab-qa`)
 container is spun up and tests are run from it by running the
 `Test::Instance::Smoke` scenario (located under
 [`gitlab-org/gitlab/qa/qa/scenario/test/smoke.rb`][smoke-instance] in the
-in the GitLab project).
+GitLab project).
 
 Example:
 
-```
+```shell
 $ gitlab-qa Test::Instance::Smoke ee:<tag> https://staging.gitlab.com
 ```
 
@@ -959,7 +986,7 @@ These tests verify features related to multiple repository storages.
 
 Example:
 
-```
+```shell
 $ export QA_ADDITIONAL_REPOSITORY_STORAGE=secondary
 
 $ gitlab-qa Test::Instance::RepositoryStorage
@@ -973,7 +1000,7 @@ in a shared internal network.
 
 Example:
 
-```
+```shell
 # For EE
 $ export EE_LICENSE=$(cat /path/to/gitlab_license)
 
@@ -1000,7 +1027,8 @@ 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)
 ```
 
@@ -1010,27 +1038,27 @@ To run a scenario with an insecure registry enabled use `Test::Integration::Regi
 
 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.
+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.
 
- ```
- GITLAB_TLS_CERTIFICATE=$(cat /path/to/certificate.crt) gitlab-qa Test::Integration::RegistryTLS EE --omnibus-config object_storage_aws
- ```
+```shell
+GITLAB_TLS_CERTIFICATE=$(cat /path/to/certificate.crt) gitlab-qa Test::Integration::RegistryTLS EE --omnibus-config object_storage_aws
+```
 
 ### 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:
 
- ```ruby
+```ruby
 gitlab-qa Test::Instance::Image EE --omnibus-config decomposition_single_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:
 
- ```ruby
+```ruby
 gitlab-qa Test::Instance::Image EE --omnibus-config decomposition_multiple_db
- ```
+```
 
 ### `Test::Instance::Geo EE|<full image address>:nightly|latest|any_tag http://geo-primary.gitlab http://geo-secondary.gitlab`
 
@@ -1039,13 +1067,13 @@ container and running the `QA::EE::Scenario::Test::Geo` scenario. Note that the
 
 **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.
+- 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 in to 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:
 
-```
+```shell
 $ export GITLAB_USERNAME="gitlab-qa"
 $ export GITLAB_PASSWORD="$GITLAB_QA_PASSWORD"
 
@@ -1056,10 +1084,10 @@ $ gitlab-qa Test::Instance::Geo EE https://primary.gitlab.com https://secondary.
 
 This scenario will run a limited number of tests that are tagged with `:chaos`.
 
-These tests are designed to verify that our systems can gracefully handle scenarios which may occur if 
-networking or connectivity type issues occur in various Gitlab components. 
-They make use of [toxiproxy(https://github.com/Shopify/toxiproxy)] to act as a proxy allowing us to introduce 
-connectivity issues, via the [toxiproxy ruby client](https://github.com/Shopify/toxiproxy-ruby) in an E2E spec. 
+These tests are designed to verify that our systems can gracefully handle scenarios which may occur if
+networking or connectivity type issues occur in various Gitlab components.
+They make use of [toxiproxy](https://github.com/Shopify/toxiproxy) to act as a proxy allowing us to introduce
+connectivity issues, via the [toxiproxy ruby client](https://github.com/Shopify/toxiproxy-ruby) in an E2E spec.
 
 Sample Test:
 
@@ -1075,9 +1103,10 @@ Sample Test:
 
 Example:
 
-```
+```ruby
 $ gitlab-qa Test::Instance::Chaos
 ```
+
 ----
 
 [Back to README.md](../README.md)

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

@@ -56,7 +56,14 @@ module Gitlab
           end
 
           def tag
-            official? ? "v#{version}" : revision
+            if official?
+              # Because RCs are considered to be pre-releases, that come before
+              # regular releases we can't check if version < 15.6.0, hence
+              # using this weird not-gonna-happen-patch-release hack.
+              Gem::Version.new(version) > Gem::Version.new('15.5.99') ? version : "v#{version}"
+            else
+              revision
+            end
           end
 
           private

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

@@ -137,7 +137,8 @@ module Gitlab
           'SMOKE_ONLY' => :smoke_only,
           'NO_ADMIN' => :no_admin,
           'CHROME_DISABLE_DEV_SHM' => :chrome_disable_dev_shm,
-          'COLORIZED_LOGS' => :colorized_logs
+          'COLORIZED_LOGS' => :colorized_logs,
+          'FIPS' => :fips
         }.freeze
 
         ENV_VARIABLES.each do |env_name, method_name|

data/lib/gitlab/qa/scenario/test/integration/gitaly_cluster.rb

@@ -191,7 +191,7 @@ module Gitlab
                     'job_name' => 'praefect',
                     'static_configs' => [
                       'targets' => [
-                        '#{@praefect_addr}:#{@praefect_port}'
+                        '#{@praefect_node_name}.#{@network}:9652'
                       ]
                     ]
                   },

data/lib/gitlab/qa/version.rb

@@ -2,6 +2,6 @@
 
 module Gitlab
   module QA
-    VERSION = '8.12.0'
+    VERSION = '8.13.1'
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-qa
 version: !ruby/object:Gem::Version
-  version: 8.12.0
+  version: 8.13.1
 platform: ruby
 authors:
 - GitLab Quality
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2022-11-17 00:00:00.000000000 Z
+date: 2022-11-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: climate_control