Switch search tests to check for advanced search by using the UI instead of parsing the Admin settings via the API
What does this MR do and why?
Prior to this change we were parsing the admin settings using the API to determine if Advanced Search was turned on. However, this approach requires an admin user and isn't viable for running tests in live environments.
This change conducts a search via the UI and looks for the text "Advanced Search enabled" in the search results page.
I've also refactored the tests to reduce redundancy by moving all of the advanced search detection and manipulation to a shared context.
This is part of the work we are doing to allow these advanced search tests to run in live environments. Once this is merged we can then add the GITLAB_QA_ACCESS_TOKEN_1
environment variable to whatever live environment we want to run these tests in (likely: Staging-ref and Staging). Then in a follow-up MR remove the :skip_live_env
tag, and add except: :production
to allow them to run in Staging/Staging-Ref.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Tokens can be found in 1Password vault.
Run the following command from your ../gitlab/qa
directory:
GITLAB_USERNAME="gitlab-qa" GITLAB_PASSWORD=<GITLAB_PASSWORD> GITLAB_QA_USERNAME_1="gitlab-qa-user1" GITLAB_QA_ACCESS_TOKEN_1=<GITLAB_QA_ACCESS_TOKEN_1> GITLAB_QA_ACCESS_TOKEN=<GITLAB_QA_ACCESS_TOKEN> QA_DEBUG=true WEBDRIVER_HEADLESS=true bundle exec bin/qa Test::Instance::All https://staging-ref.gitlab.com -- ./qa/specs/features/ee/api/9_data_stores/elasticsearch/elasticsearch_api_spec.rb --tag elasticsearch
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.