SDK Internal Pipeline (Phoenix)

Phoenix is the standard pipeline for SDK build and deployments with GitLab. This document details the setup and migration steps.

Setup

Configure GitLab Project

SDK projects should be stored under the team that owns them (e.g., q2e/development/my-team/my-project). GitLab settings can be inherited from a higher level, so consider configuring at the folder level for multiple projects.

As a maintainer, add the Phoenix CI reference and required variables:

Settings > CI/CD > General pipelines > CI/CD configuration file:

CI-SDK.gitlab-ci.yml@q2e/development/phoenix/phoenix-ci

Settings > CI/CD > Variables:

Variable

Configuration

APP_EMAIL

Team email address (e.g., myteam@q2.com). Visibility: Visible, Flags: None

APP_OWNER

Team name (e.g., My Team). Visibility: Visible, Flags: None

Add Repository Configuration

Create a values.yaml file in your repo with your service name:

service:
  name: [SERVICE_NAME]

Service Naming Convention

The typical convention is {name}-{project}. Examples:

  • populate-vault-qsdk - populate-vault owned by qsdk

  • fi5002-sdk-rege-optin-fi5002 - fi5002-sdk-rege-optin for fi5002

service.name is used to build the Nomad job name. If migrating an existing service, match your existing service name so new and old HCLs align.

To find an existing service name:

  1. From CDM, click Start a new service

  2. Locate an image for your existing project beginning with sdk/

  3. Remove the sdk/ prefix - the result is your service.name

Build and Deploy

Follow the standard Phoenix flow:

  1. Create an MR from your branch into develop and merge. Phoenix will create a pipeline and build your image.

  2. Once the pipeline finishes, manually trigger the Promote to Staging stage to push the image to A9Y.

  3. Follow the standard CDM flow to deploy the image into dev or stg.

  4. To promote to production, manually trigger the Promote to Production stage in the pipeline.