Generate Service Access Token Directly in Duo Setup
What does this MR do and why?
Resolves gitlab#454579 (closed)
Orchestrated tests within the ai-gateway
jobs occasionally fail to generate a service access token due to rate limiting applied to the /api/v1/seat_links
endpoint in CustomersDot Staging.
In GitlabSubscriptions::ActivateService
, sync_service_token
is called on once the license is saved, which eventually calls on the Sidekiq worker SyncSeatLinkRequestWorker
. If the seat link request to CustomersDot fails here, the job will not be able to call on perform_cloud_connector_sync
to generate the service access token. Without this token, the tests cannot interact with AI features.
To help bypass this rate limit, this MR adds a direct call to ::CloudConnector::SyncServiceTokenWorker.perform_async(license_id: License.current.id)
to generate the access token directly, rather than rely on the token generation that is coupled within the seat link process. This is similar to manually running the sync_service_token_worker
cron job which occurs daily.
How to set up and validate locally
- If you are running an ARM based machine, run the following first:
docker pull --platform linux/x86_64 gitlab/gitlab-ee:nightly
docker pull --platform linux/x86_64 gitlab/gitlab-ee-qa:nightly
- Export the following ENV vars to your terminal
export GITLAB_LICENSE_MODE=test
export QA_EE_ACTIVATION_CODE=<located in 1Password under Staging Generated EE_LICENSE and ACTIVATION_CODE entry>
export CHROME_DISABLE_DEV_SHM=true
export QA_SKIP_PULL=true
export GITLAB_QA_ADMIN_ACCESS_TOKEN=<TOKEN_VALUE located in admin_access_token_seed.rb>
- Run the following command:
./exe/gitlab-qa Test::Integration::AiGateway EE
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
Commits include Changelog:
trailer -
I have evaluated the MR acceptance checklist for this MR.