Skip to content

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

  1. 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
  1. 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>
  1. 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.

Edited by Valerie Burton

Merge request reports

Loading