Replace 'access_data.yml' configuration with CC gem

As described in our ADR-003 Migration Path, we are transitioning away from the access_data.yml file.

What’s happening?

  • The GitLab Rails backend will now use configurations generated by gitlab-cloud-connector gem in legacy format. Plan is to use gitlab-cloud-connector as SSoT.

  • This is behind a feature flag use_cloud_connector_available_services_generator

  • A CI/CD job will compare old vs. new configurations and fail if they don’t match.

    Fialed job:

    Differences found between access_data.yml and gitlab_cloud_connector Gem configuration:
     - services.agent_quick_actions: {"backend"=>"gitlab-ai-gateway", "bundled_with"=>. 
{"_irrelevant"=>{"unit_primitives"=>["event", "amazon_q_create_oauth_app", 
"amazon_q_create_onboarding_grant_code", "agent_quick_actions"]}}}

Rollout issue

What’s next?

  • We will wait until the end of this week (13th December), to be extra safe and be able to flip the feature flag back in case of any issues) and then proceed with the full removal of access_data.yml
  • Once this deprecation is complete, we’ll deprecate the CustomersDot cloud_connector.yml file next.

Documentation

Documentation will be updated soon to cover this transition, rollout, and file changes required for new unit primitives. It's WIP.

How to add new Unit Primitives during the transition?

Since there are many moving parts and stage groups frequently add or modify configurations, we need to ensure that all configurations are up-to-date during the rollout/transition period. We need to make sure that when we flip the feature flag we avoid accidentally using obsolete data in both directions.

To address this, a CI/CD job has been set up to fail if the two configurations are not identical.

If this is urgent, and you can't wait for a full rollout, the only way to add new unit primitives/services without breaking the CI/CD job is to follow these steps:

  1. Add missing unit primitive first in gitlab-cloud-connector/config/unit_primitives
    • Backward compatibility: In order to support backward compatibility with the old legacy service structure, we maintain the mappings between unit primitive, and soon-to-be-deprecated service abstraction.
      • If the unit primitive is a stand-alone feature (1-1 mapping), no further changes are needed, the service with the same name will be generated (no work required)
      • If the unit primitive is delivered as part of an existing service (e.g duo_chat), service has multiple unit primitives, add the unit primitive to the desired service in config/services folder.
  2. Bump the library version.
  3. Create MR in Gitlab Rails
Edited by Nikola Milojevic