Use CloudConnector::Tokens in AIGW headers
What does this MR do and why?
Use CloudConnector::Tokens to produce Cloud Connector tokens for AI gateway requests. This is a new façade we introduced to abstract away Cloud Connector token minting over all supported deployment types and use cases. It also internally wraps away a legacy path (AvailableServices#access_token) we are looking to remove in future MRs, and which is still activated by default.
This change is internal only, not user-facing, and behind the cloud_connector_new_token_path FF.
Rollout issue: #558081 (closed)
Notes
I addressed a number of test failures by reducing test dependencies on implementation details of Cloud Connector. We have many tests that re-verify certain AI-related header fields are included in AI gateway requests (including those generated by Cloud Connector), which makes unit test setup extremely complicated and brittle in face of refactors like these.
Instead, we should stub at interface boundaries, in this case: Gitlab::AiGateway.headers. We do not need to test this N-times over across all our AI code. We should instead verify that we pass the expected inputs and rely on unit tests for this method to do what it should.
References
- Step 1 of Refactor AiGateway.headers to accept unit_primi... (#546578 - closed)
- Part of 5.2 Migrate access_token by feature or use case (&17999 - closed)
How to set up and validate locally
- Set up some form of Duo locally
- Enable the
cloud_connector_new_token_pathFF - Send a code suggestions request (e.g. via the Duo Healthcheck UI)
- It should still work as intended
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #546578 (closed)