May 2026 · Part 2 of 5: Mapping the New CI/CD Infrastructure
In the legacy configuration, the orchestration lifecycle was completely dependent on external service providers. Source code hosting, pipeline execution, and container image storage were centralized within a single third-party infrastructure layer.
Under this model, engineering visibility was limited to the target Kubernetes cluster layer. Upstream infrastructure degradation—such as runner queue latency, container registry packet loss, or unacknowledged webhook drops—halted the delivery pipeline. Direct system diagnostics were blocked due to the lack of underlying host access, leaving engineering dependent on external status indicator boards.
The refactored state decouples compilation and deployment dependencies from external hosting providers. Source tracking shifts to Codeberg, while execution and artifact management transition to internal network boundaries.
The runtime runner, network paths, and container registry reside within the same Google Cloud Platform (GCP) regional IAM boundary. Cryptographic strings transition directly from Codeberg organizational definitions into cluster-native Kubernetes secrets, eliminating intermediary routing services. System anomalies are diagnosed directly through cluster log aggregators, removing dependency on third-party support ticket queues.
The underlying compute architecture partitions processing workloads across three distinct Google Kubernetes Engine (GKE) node pools to enforce scheduling isolation and control monthly operational expenditures.
| Node Pool Namespace | Virtual Machine Type | Preemption Model (Spot) | Autoscaling Limits (Min / Max) | Operational Workspace Purpose | Estimated Cost (Monthly) |
|---|---|---|---|---|---|
ci-spot-pool | e2-highcpu-8 (8 vCPU / 8 GB) | Enforced (Yes) | 0 / 3 | Execution of CI runner daemons | ~$3.00 |
staging-spot-pool | e2-standard-2 (2 vCPU / 8 GB) | Enforced (Yes) | 0 / 2 | Staging environment workloads | ~$7.00 |
production-pool-8gb | e2-standard-2 (2 vCPU / 8 GB) | Standard (No) | 2 / 4 | Production-grade cluster layer | ~$48.00 |
The execution engine runs as an isolated pod containing two tightly coupled, co-scheduled service layers. Resource constraints are explicitly defined to optimize memory allocations and prevent host-level node resource exhaustion.
runner): Configured with 1 vCPU and 1.5 GiB of memory. Functions as the command processor, polling the upstream Codeberg API for queued job specifications, managing workflow state transitions, and executing step dispatch coordination.dind): Configured with 6 vCPUs and 6 GiB of memory. Operates an isolated Docker-in-Docker daemon tasked with executing intensive file I/O operations, image compilation layers, and remote registry asset delivery (push actions).The runner pod manifest enforces specific runtime placement boundaries via strict Kubernetes scheduling instructions:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/gke-nodepool
operator: In
values:
- ci-spot-pool
tolerations:
- key: "ci-workload"
operator: "Exists"
effect: "NoSchedule"
The execution limit is capped at a maximum of two concurrent pipeline instances. Expanding concurrency parameters beyond this threshold on highly volatile spot compute instances increases the mathematical probability of node preemption events mid-transaction.
The execution pipeline maps to a directed acyclic graph (DAG) divided into three distinct execution barriers. Automated deployment phases trigger immediately upon code delivery to the target repository tracking branch.
The total duration from delivery notification to staging cluster update spans between 12 and 15 minutes. This execution speed is maintained by leveraging heavily multicore spot instances configured to minimize platform overhead costs.
| Phase Layer | Functional Target Step | Estimated Processing Window |
|---|---|---|
| Phase 1: Validation | lint-backend | ~3 min |
| Phase 1: Validation | test-backend (8 parallel workers) | ~7 min |
| Phase 1: Validation | test-frontend | ~2 min |
| Phase 2: Compilation | build-backend | ~3 min |
| Phase 2: Compilation | build-frontend-staging | ~2 min |
| Phase 3: Delivery | deploy-staging | ~3 min |