Development Pipelines

Arda’s development pipelines automate the transformation of source code into deployable artifacts and their promotion through environments. Pipelines are implemented as GitHub Actions workflows defined in each component repository.

Pipeline Responsibilities

Stage	Responsibility
Build	Compile Kotlin sources, run unit tests, package JARs
Publish	Push Docker images and Helm charts to artifact repositories
Deploy	Install/upgrade Helm chart in a target Kubernetes environment
Verify	Run API integration tests against the deployed component

Deployment Mechanism

Components are deployed as Helm charts to the Kubernetes (EKS) cluster in the target Environment. The helm-deploy-pipeline-action GitHub Action is the standard deployment tool. It:

1. Reads CloudFormation outputs from the target Infrastructure and Partition (read-cloudformation-values.cmd)
2. Resolves runtime configuration values (API Gateway URLs, database endpoints, Cognito parameters) into Helm values
3. Executes helm upgrade --install with the resolved values

Reading CloudFormation Outputs

read-cloudformation-values.cmd maps CloudFormation export names to Helm value paths:

readExport path.to.key.extras.some.myKey ${PURPOSE}-API-MyKey

Configuration values flow into the Component via:

• application.conf / module-specific .conf files
• configmap.yaml in the Helm chart template
• lintValues in build.gradle.kts for local lint validation

Local Deployment

To deploy locally to a Kubernetes cluster for development and testing:

./gradlew clean helmInstallToLocal

This resolves configuration from application-test.conf and installs the chart into the local cluster.

Known Pipeline Behaviors

addRoleObserver Mock Cascade Failure

When a new method is added to a widely-mocked interface and is called during object construction (init block), it causes widespread test failures across unrelated modules. Fix pattern: locate all mockk<ServiceType>() usages across the codebase and add explicit stubs for the new method. This is a mechanical multi-file change requiring no logic changes.

API Test Flakiness on First Run

The first API test run against a freshly deployed local Kubernetes pod may fail due to pod startup timing. Retry after a 5-second delay before investigating genuine failures.

Upload Tests Require Infrastructure

Upload-related API tests depend on S3/LocalStack infrastructure that may not be present in all CI environments. Pass --ignore Upload when checking API test results in environments without S3.

Environment Promotion

The current promotion path is:

1. Developer builds and tests locally
2. CI pipeline deploys to Alpha002-dev on merge to the main branch
3. Manual promotion to Alpha002-stage for pre-release validation
4. Production deployment requires explicit operator action