CI/CD Workflows for Unibeam Services¶

2025-12-172025-12-17

This repository contains GitHub Actions workflows for building and deploying Unibeam services. The workflows are designed to handle multiple services simultaneously or a specific service based on the input provided.

TOC¶

Workflows Overview
Workflow Steps
Prerequisites
Secrets and Variables

Workflows Overview¶

1. `main.yaml`: Main CI/CD Workflow for All Services¶

Builds and deploys all services in the list.
Supports matrix builds to handle multiple repositories in parallel.
Deploys updates to the appropriate ArgoCD branch based on the target cluster and environment.

2. `service.yaml`: CI/CD Workflow for Specific Service¶

Targets a specific service for build and deploy.
Useful for testing or updating a single service without triggering builds for all others.

Usage¶

Inputs for Both Workflows¶

Input Name	Description	Default Value	Options	Required
`target`	Maven Profile for the build	`docker-unibeam`	N/A	✅
`cluster`	Target cluster for deployment	`dev-us`	`dev-us`, `demo`	✅
`source_revision`	Source branch of the service repositories	`master`	Any valid branch name	✅
`environment`	Target environment for deployment	`dev`, `demo`, `indosat-prod`, `il-prod`	`dev`, `mtn-poc`, `telefonica-poc`	✅

Additional Input for `service.yaml`¶

Input Name	Description	Default Value	Options	Required
`service`	The service to be built and deployed	`dashboard-service`	`dashboard-service`, `sms-service`, `sia-api`, `sim-service`, `scheduled-jobs`, `mno-service`, `audit-service`	✅

Workflow Steps¶

`main.yaml`¶

This workflow handles building and deploying all services in parallel.

Build Phase:
Iterates through a list of repositories using a matrix strategy.
For each repository:
- Checks out the code.
- Configures the environment, including AWS and Maven.
- Builds and pushes a Docker image using Maven's jib plugin.
- Collects the built service names and image tags.
Deploy Phase:
Checks out the ArgoCD repository.
Updates the values.yaml files for all services with the new image tags.
Commits and pushes changes to the appropriate ArgoCD branch.

`service.yaml`¶

This workflow builds and deploys a specific service.

Build Phase:
Checks out the target service repository.
Configures the environment, including AWS and Maven.
Builds and pushes the Docker image for the specified service.
Outputs the service name and image tag.
Deploy Phase:
Checks out the ArgoCD repository.
Updates the values.yaml file for the target service with the new image tag.
Commits and pushes changes to the appropriate ArgoCD branch.

Prerequisites¶

Secrets and Variables¶

Secret/Variable Name	Description
`CICD_APP_ID`	GitHub App ID for accessing private repositories
`CICD_APP_PRIVATE_KEY`	Private key for the GitHub App
`APP_ID`	GitHub App ID for ArgoCD repository access
`APP_PRIVATE_KEY`	Private key for the GitHub App for ArgoCD access
`AWS_REGION`	aws region for env
`CLUSTER`	env name service-application path in argo root
`BRANCH`	argocd branch to fetch from
`PROFILE`	Maven docker profile

Example Usage¶

Main Workflow (`main.yaml`)¶

Trigger the workflow manually in the GitHub UI and provide the following inputs: - target: Specify the Maven profile for the build (default: docker-unibeam). - cluster: Select the deployment cluster (e.g., dev-us). - source_revision: Choose the source branch (default: master). - environment: Set the deployment environment (default: dev).

The workflow will: - Build Docker images for all services. - Deploy updates to the ArgoCD repository for the specified cluster and environment.

Specific Service Workflow (`service.yaml`)¶

Trigger the workflow manually in the GitHub UI and provide the following inputs: - target: Specify the Maven profile for the build (default: docker-unibeam). - cluster: Select the deployment cluster (e.g., dev-us). - source_revision: Choose the source branch (default: master). - service: Select the service to build and deploy (e.g., dashboard-service). - environment: Set the deployment environment (default: dev).

The workflow will: - Build the Docker image for the selected service. - Deploy updates to the ArgoCD repository for the specified cluster and environment.

ArgoCD Repo¶

CICD Flow¶

graph LR
    A[ARGOCD_REPO] -->|Application definition| B[HELM_VALUES]
    B -->|kubernetes-repo| C[HELM_Directory]

ArgoCD repo contains application definitions for argo (infra, apps) components
Branch name is the EKS cluster name represented in AWS
Every POC ENV should have it own Public Subnet and Private Subnet
- This is because some env's have IPSEC tunnel with SMSC termination
- routing separation so that only env_poc related pod can access the IPSEC encryption domain end point (SMSC)
- Public subnet since it needs ALB/NLB
- ALB is used for (dashboard, SIA-API, MNO)
- NLB SIM-Service TCP 9506 for applet connectivity since its not possible to have DNS in java applets
  - The sim-service eipalloc (aws account public ip allocation) - this ip should be in the account before service provision
```
    service:
      type: LoadBalancer
      port: 9506
      eipallocations: eipalloc-051bfcc9868a99eb6
      loadBalancerIP: {}
```
- ENV_POC should have it own workers nodes with label env_name: true
- With Helm deployments nodeSelector arg can be controlled via argocd definition like this:
```
      helm:
        valueFiles:
          - $values/infra-applications/mtn-poc/redis/values.yaml
        values: |
          nodeSelector:
            mtn: "true"
```
  Merging of Values: Inline values (in values) take precedence over valueFiles. If the external values.yaml already specifies a nodeSelector, the inline values here will override it.
ArgoCD uses deployment key in repo settings

CLI¶

Connecting via CLI when sso is enabled:

argocd login --sso argocd.poc.tinyrt.com