gitlab-qa 14.18.0 → 14.19.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2aca04edea5cc1cf803513ed9d4bab1ed4d73ce2126e244e1d166ddce1c8cf1c
-  data.tar.gz: 5e5a38423e70530828c6a86a368c6825d5247808d799fcf38c195992d1a25bb7
+  metadata.gz: 3d5b82d626da25ea72196cade9499553040e8fb3dadc5b1afbbceef06ba1abb1
+  data.tar.gz: 3a16cb5354eebd63a097a1f64269d4ad5cc6b4995069fb0ad30e38fd6b418758
 SHA512:
-  metadata.gz: 87668dd869f1100e6a78df1273934026960903a5de2fd36c53c54be61783a61cdc798d0baa908e82d5e9b6dcf9100e147fdf3d1343afe476b2c9e042f74b7d57
-  data.tar.gz: e47a1c57792a1f697eec41709ffdaef17c27284b9b3c918648d850dee3d968c63783b5e3c1cd87e1b15c832c6df92a2d32f0e2f796db14fd36f03a59e369fd57
+  metadata.gz: 3fef225828d82dafce07623c0fda78ce2b40676c20415e0246133e6ca5a71111f0a9d0b8353ee10ac845613dab94d0d2d0e499826dcf9f29d36d9725e3b17ddf
+  data.tar.gz: e80f04f59c0863114455bf2e8daf7806e9f3fd1d4d21c3900de4d500678c55075f022ae09d265e15fa444c18ceb7ea4c03071c10438f9d403e145db6e7aa28b4

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    gitlab-qa (14.18.0)
+    gitlab-qa (14.19.0)
       activesupport (>= 6.1, < 7.2)
       gitlab (~> 4.19)
       http (~> 5.0)

data/docs/architecture.md

@@ -1,8 +1,8 @@
 # GitLab QA architecture
 
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vTBlBcIBFFnQOd9xGQ7-2rij96mP2-ajNd9sQILhSI2D7x-q_8oMuO_GFG8-BWRoQZkVHWdQZTdXF8c/pub?w=855&amp;h=2426">
+![GitLab QA architecture diagram](https://docs.google.com/drawings/d/e/2PACX-1vTBlBcIBFFnQOd9xGQ7-2rij96mP2-ajNd9sQILhSI2D7x-q_8oMuO_GFG8-BWRoQZkVHWdQZTdXF8c/pub?w=855&amp;h=2426)
 
-_[edit diagram (for GitLab team members only)](https://docs.google.com/drawings/d/12mTCF7BU-xaxxS9MmIjkSYnf31RN4wgkkHcXTmS0NoA/edit)_
+_[Edit diagram (for GitLab team members only)](https://docs.google.com/drawings/d/12mTCF7BU-xaxxS9MmIjkSYnf31RN4wgkkHcXTmS0NoA/edit)_
 
 ----
 

data/docs/developer/style_guide.md

@@ -26,4 +26,4 @@ We have a `lefthook.yml` checked in but it is ignored until Lefthook is installe
    bundle exec lefthook run pre-push
    ```
 
-For a detailed guide on left hook configuration see https://github.com/evilmartians/lefthook/blob/master/docs/configuration.md
+For a detailed guide on left hook configuration see <https://github.com/evilmartians/lefthook/blob/master/docs/configuration.md>

data/docs/release_process.md

@@ -4,13 +4,13 @@
 
 We follow [Semantic Versioning](https://semver.org).  In short, this means that the new version should reflect the types of changes that are about to be released.
 
-*summary from semver.org*
-
-MAJOR.MINOR.PATCH
-
-- MAJOR version when you make incompatible API changes,
-- MINOR version when you add functionality in a backwards compatible manner, and
-- PATCH version when you make backwards compatible bug fixes.
+> _Summary from semver.org_
+>
+> MAJOR.MINOR.PATCH
+>
+> - MAJOR version when you make incompatible API changes,
+> - MINOR version when you add functionality in a backward compatible manner
+> - PATCH version when you make backward compatible bug fixes.
 
 ## When we release
 
@@ -27,7 +27,7 @@ when we make a change - no matter the size of the change.
 - Merge the merge request.
 - The new version should automatically be tagged and pushed to Rubygems by the `gem-release` job in the merge commit pipeline.
 - Update the release notes for the newly created tag (https://gitlab.com/gitlab-org/gitlab-qa/-/tags):
-  * **Release notes**: Copy the release notes from the merge request.
+  - **Release notes**: Copy the release notes from the merge request.
 
 Note: The `gem-release` job uses:
 
@@ -43,7 +43,8 @@ Please note that `gitlab-qa` version in `gitlab-org/gitlab` project will be upda
 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:
+### Key
+
 - Rectangles represent manual actions
 - Hexagons represent automated actions
 

data/docs/run_qa_against_gdk.md

@@ -5,6 +5,7 @@ make a few changes to your `gdk/gitlab/config/gitlab.yml` file.
 
 1. Retrieve your current local IP with `ifconfig`, e.g. `192.168.0.12`.
 2. In your gdk directory, create file `gdk.yml`. Within `gdk.yml` add:
+
     ```yaml
     ---
     gdk:
@@ -16,6 +17,7 @@ make a few changes to your `gdk/gitlab/config/gitlab.yml` file.
     webpack:
         host: 192.168.0.12
     ```
+
 3. Run `gdk reconfigure`
     - This should update `localhost` in your `gitlab/config/gitlab.yml`.
         and `gdk/Procfile` as well as `gdk/openssh/sshd_config` to the provided IP address.
@@ -27,7 +29,7 @@ make a few changes to your `gdk/gitlab/config/gitlab.yml` file.
    - If reconfigure is successful, you should now be able to browse to `http://192.168.0.12:3000` instead of `http://localhost:3000`
 7. Run the QA scenario as follows:
 
-  ```
+  ```shell
   $ gitlab-qa Test::Instance::Any CE http://192.168.0.12:3000 -- qa/specs/features/browser_ui/1_manage/login/log_in_spec.rb
 
   # Or if you want to run your local `gitlab-qa/exe/gitlab-qa`:
@@ -55,37 +57,37 @@ GitLab QA expects the default initial password to be used in tests; see all defa
 If you have changed your root password, you must set the `GITLAB_INITIAL_ROOT_PASSWORD` environment
 variable.
 
-```
-export GITLAB_INITIAL_ROOT_PASSWORD="<GDK root password>"
-```
+  ```shell
+  export GITLAB_INITIAL_ROOT_PASSWORD="<GDK root password>"
+  ```
 
 **Note**: If you encounter the following error, you can resolve it by unsetting the Docker host environment variable using the command `unset DOCKER_HOST`:
 
-```
-ERROR: error during connect: get "http://docker.local:2375/v1.24/images/json": dial tcp: lookup docker.local: no such host
-```
+  ```shell
+  ERROR: error during connect: get "http://docker.local:2375/v1.24/images/json": dial tcp: lookup docker.local: no such host
+  ```
 
-### Running EE tests
+## Running EE tests
 
 When running EE tests you'll need to have a license available. GitLab engineers can [request a license](https://about.gitlab.com/handbook/developer-onboarding/#working-on-gitlab-ee).
 
 Once you have the license file you can export it as an environment variable and then `gitlab-qa` can use it. If you do so it will be installed automatically by the QA framework.
 
-```
-export EE_LICENSE=$(cat /path/to/gitlab_license)
-```
+  ```shell
+  export EE_LICENSE=$(cat /path/to/gitlab_license)
+  ```
 
 ## Run Geo QA tests against your Geo GDK setup
 
 Run from the `gdk-ee/gitlab/qa` directory with GDK primary and secondary running:
 
-```
-# Run in the background
-$ bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --primary-name primary --secondary-name secondary --without-setup
+  ```shell
+  # Run in the background
+  $ bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --primary-name primary --secondary-name secondary --without-setup
 
-# Run in visible Chrome browser
-$ WEBDRIVER_HEADLESS=0 bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --primary-name primary --secondary-name secondary --without-setup
-```
+  # Run in visible Chrome browser
+  $ WEBDRIVER_HEADLESS=0 bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --primary-name primary --secondary-name secondary --without-setup
+  ```
 
 ### QA Tool support on macOS
 
@@ -149,42 +151,44 @@ development machine that maps the VHOST to `localhost:port`, changing to the por
 You first need to map the hostnames to the local ip:
 
 Edit the `/etc/hosts` file
-```
-127.0.0.1 gitlab-primary.geo gitlab-secondary.geo
-```
+
+  ```plaintext
+  127.0.0.1 gitlab-primary.geo gitlab-secondary.geo
+  ```
+
 We are going to use [caddyserver](https://caddyserver.com/) in this example. You can install caddy with `brew install caddy`.
 
 After booting-up your containers, list the assigned ports:
 
-```bash
-$ docker ps
+  ```shell
+  $ docker ps
 
-CONTAINER ID        IMAGE                      COMMAND             CREATED             STATUS                                     PORTS                                    NAMES
-d28cc97870b4        gitlab/gitlab-ee:nightly   "/assets/wrapper"   1 second ago        Up Less than a second (health: starting)   22/tcp, 443/tcp, 0.0.0.0:32775->80/tcp   gitlab-secondary
-41f86bb951c5        gitlab/gitlab-ee:nightly   "/assets/wrapper"   2 minutes ago       Up 2 minutes (healthy)                     22/tcp, 443/tcp, 0.0.0.0:32774->80/tcp   gitlab-primary
-```
+  CONTAINER ID        IMAGE                      COMMAND             CREATED             STATUS                                     PORTS                                    NAMES
+  d28cc97870b4        gitlab/gitlab-ee:nightly   "/assets/wrapper"   1 second ago        Up Less than a second (health: starting)   22/tcp, 443/tcp, 0.0.0.0:32775->80/tcp   gitlab-secondary
+  41f86bb951c5        gitlab/gitlab-ee:nightly   "/assets/wrapper"   2 minutes ago       Up 2 minutes (healthy)                     22/tcp, 443/tcp, 0.0.0.0:32774->80/tcp   gitlab-primary
+  ```
 
 Create a Caddyfile, mapping the VHOSTs with the `localhost:port` combination:
 
-```
-http://gitlab-primary.geo {
-  proxy / localhost:32774 {
-    transparent
+  ```plaintext
+  http://gitlab-primary.geo {
+    proxy / localhost:32774 {
+      transparent
+    }
   }
-}
 
-http://gitlab-secondary.geo {
-  proxy / localhost:32775 {
-    transparent
+  http://gitlab-secondary.geo {
+    proxy / localhost:32775 {
+      transparent
+    }
   }
-}
-```
+  ```
 
 And run caddy:
 
-```bash
-caddy -conf Caddyfile
-```
+  ```shell
+  caddy -conf Caddyfile
+  ```
 
 You should be able to use your navigator and point it to `http://gitlab-primary.geo` or `http://gitlab-secondary.geo`.
 

data/docs/running_against_remote_grid.md

@@ -2,7 +2,7 @@
 
 The QA tests have the ability to be run against a local or remote grid.
 
-I.e, if you have a Selenium server set up at http://localhost:4444 or if you have a SauceLabs / BrowserStack account.
+I.e, if you have a Selenium server set up at <http://localhost:4444> or if you have a SauceLabs / BrowserStack account.
 
 ## Variables
 
@@ -70,10 +70,10 @@ To start the tunnel, copy the run command in **Sauce Labs > Tunnels** and run it
 
 It is highly recommended to use `GITLAB_QA_ACCESS_TOKEN` to speed up tests and reduce flakiness.
 
-
 ### Run a test in a desktop browser
 
 While tunnel is running, to test against a local instance in a desktop browser, run:
+
 ```shell
 $ QA_BROWSER="safari" \
   QA_REMOTE_GRID="ondemand.saucelabs.com:80" \

data/docs/{specifics_for_macos_m1_m2.md → troubleshooting.md}

@@ -1,10 +1,12 @@
-# Specifics for Mac OS with M1, M2 processors & Docker Desktop
+# Troubleshooting
 
-You might encounter the following errors when running tests locally, using Gitlab QA, on Mac OS with M1 or M2 processors.  These errors usually stem from using Docker images that are based on Linux/AMD64 platforms.
+## Mac OS with ARM processors & Docker Desktop
+
+You might encounter the following errors when running tests locally, using Gitlab QA, on Mac OS with `ARM` processors.  These errors usually stem from using Docker images that are based on Linux/AMD64 platforms.
 
 - `MADV_DONTNEED` does not work (memset will be used instead)
 
-    ```
+    ```shell
     <jemalloc>: MADV_DONTNEED does not work (memset will be used instead)
     <jemalloc>: (This is the expected behaviour if you are running under QEMU)
     bundler: failed to load command: bin/qa (bin/qa)
@@ -16,14 +18,14 @@ You might encounter the following errors when running tests locally, using Gitla
 
 - `QA::Support::Repeater::WaitExceededError`
 
-    ```
+    ```shell
     QA::Support::Repeater::WaitExceededError:
         Page did not fully load. This could be due to an unending async request or loading icon.
     ```
 
 - `Selenium::WebDriver::Error::UnknownError`
 
-    ```
+    ```shell
     Selenium::WebDriver::Error::UnknownError:
         unknown error: session deleted because of page crash
         from tab crashed
@@ -33,6 +35,7 @@ You might encounter the following errors when running tests locally, using Gitla
 To resolve these issues:
 
 1. Do not use `/dev/shm` shared memory. Set `CHROME_DISABLE_DEV_SHM` environment variable to `true`.
+
     ```shell
     $ export CHROME_DISABLE_DEV_SHM=true
     # Disable Chrome shared memory

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

@@ -104,7 +104,8 @@ module Gitlab
             'AIGW_LOGGING__LEVEL' => 'debug',
             'AIGW_LOGGING__TO_FILE' => "..#{LOG_DIR}/modelgateway_debug.log",
             'AIGW_SELF_SIGNED_JWT__SIGNING_KEY' => TEST_SIGNING_KEY,
-            'AIGW_SELF_SIGNED_JWT__VALIDATION_KEY' => TEST_VALIDATION_KEY
+            'AIGW_SELF_SIGNED_JWT__VALIDATION_KEY' => TEST_VALIDATION_KEY,
+            'CLOUD_CONNECTOR_SERVICE_NAME' => 'gitlab-ai-gateway'
           }
         end
       end

data/lib/gitlab/qa/version.rb

@@ -2,6 +2,6 @@
 
 module Gitlab
   module QA
-    VERSION = '14.18.0'
+    VERSION = '14.19.0'
   end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: gitlab-qa
 version: !ruby/object:Gem::Version
-  version: 14.18.0
+  version: 14.19.0
 platform: ruby
 authors:
 - GitLab Quality
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2024-10-22 00:00:00.000000000 Z
+date: 2024-10-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: climate_control
@@ -365,15 +365,13 @@ files:
 - docs/developer/http_mocking.md
 - docs/developer/ssl.md
 - docs/developer/style_guide.md
-- docs/environment_setup/users.md
 - docs/how_it_works.md
 - docs/omnibus_configurations/license_mode.md
 - docs/release_process.md
 - docs/run_qa_against_gdk.md
 - docs/running_against_remote_grid.md
-- docs/specifics_for_macos_m1_m2.md
 - docs/trainings.md
-- docs/waits.md
+- docs/troubleshooting.md
 - docs/what_tests_can_be_run.md
 - exe/gitlab-qa
 - fixtures/cvs/vulnerabilities_template.erb

data/docs/environment_setup/users.md

@@ -1,9 +0,0 @@
-# Environment Setup | Users
-
-Most tests ([orchestrated and instance-level](../docs/what_tests_can_be_run.md#the-two-types-of-qa-tests)) [run as the default `root` user](https://gitlab.com/gitlab-org/gitlab/-/blob/3f247bf0d6d24b479b7f169f9c14068968d9672a/qa/qa/runtime/user.rb#L16). However, some require additional users. If the test framework has administrator access to the test environment it can create users itself. If administrator access is not available you will need to create users before being able to run certain tests.
-
-## Disable email verification
-
-If [email verification](https://docs.gitlab.com/ee/security/email_verification.html) is enabled on the test environment (via the `require_email_verification` feature flag), a user cannot log in under certain conditions (e.g., logging in the first time from a new location) unless they enter a verification code that is sent to their email address.
-
-To disable email verification you can disable the `require_email_verification` feature flag, which will disable email verification for all users on the instance. Alternatively, you can skip verification for individual users by enabling the `skip_require_email_verification` feature flag for that user.

data/docs/waits.md

@@ -1,24 +0,0 @@
-Waits
----
-
-All Capybara Node Finders utilize a waiting mechanism.
-
-Per the [Capybara API](https://www.rubydoc.info/github/jnicklas/capybara/Capybara/Node/Finders:find) -
-
-> If the driver is capable of executing JavaScript, `find` will wait for a set amount of time and continuously retry finding the element until either the element is found or the time expires. The length of time find will wait is controlled through `Capybara.default_max_wait_time` and defaults to `2` seconds. `find` takes the same options as all.
-
-Ideally the [GitLab QA Framework](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa) should implement its own explicit waiting to avoid hard sleeps but currently that is [not the case](https://gitlab.com/gitlab-org/gitlab-qa/issues/280).
-
-## Hard Sleeps
-
-**[qa/qa/page/base.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/qa/page/base.rb#L16)**
-
-```
-def wait(max: 60, time: 0.1, reload: true)
-  ...
-end
-```
-
-- `max`    : Specifies the max amount of *seconds* to wait until the block given is satisfied
-- `time`   : The interval/poll time to sleep *in seconds*. If this time reaches `max`, the wait returns `false`
-- `reload` : If the wait is not satiated, the test will sleep then reload the page if `:reload` is set to `true`