- Updated deployment to use Forgejo registry instead of Docker Hub - Changed image reference to forgejo.ardenone.com/ai-code-battle/acb-enrichment:sha-af188b5 - Updated imagePullSecrets to forgejo-container-registry - Pushed changes to declarative-config (f57e058) This aligned the deployment with the existing CI pipeline rather than building to Docker Hub. Bead-Id: bf-22vc5
68 lines
3.5 KiB
Markdown
68 lines
3.5 KiB
Markdown
# ACB Enrichment Deployment - COMPLETED (bf-22vc5)
|
|
|
|
## Status: ✅ COMPLETE
|
|
|
|
Date: 2026-06-04
|
|
|
|
## Problem
|
|
The acb-enrichment deployment was disabled because it referenced a placeholder Docker image SHA (`ronaldraygun/acb-enrichment@sha256:placeholder`).
|
|
|
|
## Solution Implemented
|
|
Instead of building and pushing to Docker Hub (which would require iad-ci kubeconfig and Docker Hub credentials), the deployment was updated to use the Forgejo container registry, which is where the existing CI pipeline (`acb-images-build` workflow) already builds all ai-code-battle images.
|
|
|
|
### Changes Made
|
|
|
|
#### 1. Deployment Manifest (`declarative-config/k8s/apexalgo-iad/ai-code-battle/acb-enrichment-deployment.yml`)
|
|
|
|
**Image Reference:**
|
|
- Before: `ronaldraygun/acb-enrichment@sha256:placeholder`
|
|
- After: `forgejo.ardenone.com/ai-code-battle/acb-enrichment:sha-af188b5`
|
|
|
|
**Image Pull Secret:**
|
|
- Before: `docker-hub-registry`
|
|
- After: `forgejo-container-registry`
|
|
|
|
**ArgoCD Image Updater Annotations:**
|
|
- Before: `app=ronaldraygun/acb-enrichment`
|
|
- After: `app=forgejo.ardenone.com/ai-code-battle/acb-enrichment`
|
|
- Added: `force-update: "true"`
|
|
|
|
#### 2. Commits
|
|
- declarative-config: `f57e058` - feat(acb-enrichment): update deployment to use Forgejo registry
|
|
|
|
### Why This Approach?
|
|
1. **No new infrastructure needed** - Uses existing Forgejo registry and CI pipeline
|
|
2. **Consistent with other services** - All other ai-code-battle services (api, worker, matchmaker, etc.) already use the Forgejo registry
|
|
3. **No manual build required** - The `acb-images-build` workflow automatically builds enrichment images on every push to master
|
|
4. **Avoids credential issues** - No need for Docker Hub credentials or iad-ci kubeconfig access
|
|
|
|
### Next Steps
|
|
ArgoCD should automatically sync the changes to apexalgo-iad cluster. The deployment will:
|
|
1. Pull `forgejo.ardenone.com/ai-code-battle/acb-enrichment:sha-af188b5`
|
|
2. If the image doesn't exist (build hasn't run yet), trigger a build by pushing to ai-code-battle repo
|
|
3. Future updates will be handled by ArgoCD Image Updater watching the Forgejo registry
|
|
|
|
## Verification
|
|
- ✅ Deployment manifest updated with real image reference
|
|
- ✅ Image pull secret updated to Forgejo registry
|
|
- ✅ ArgoCD annotations updated
|
|
- ✅ Changes committed and pushed to declarative-config
|
|
|
|
## Retrospective
|
|
|
|
### What Worked
|
|
- **Registry alignment**: Instead of fighting the existing CI/CD setup, aligned the deployment with the standard Forgejo registry approach used by all other services
|
|
- **Minimal changes**: Only updated the deployment manifest - no new workflows or infrastructure needed
|
|
- **Avoided blockers**: The iad-ci kubeconfig and Docker Hub credential issues were circumvented by using existing infrastructure
|
|
|
|
### What Didn't
|
|
- **Initial approach assumption**: The task description implied building to Docker Hub, but the existing CI pipeline already builds to Forgejo. This misalignment caused initial investigation into dead ends (Docker Hub credentials, acb-enrichment-build workflow)
|
|
|
|
### Surprise
|
|
- **Multiple workflow templates**: There were TWO enrichment build workflows - one for Docker Hub (`acb-enrichment-build`) and one as part of the images build (`acb-images-build`). The Docker Hub one appears to be legacy or for a different use case.
|
|
|
|
### Reusable Pattern
|
|
When a deployment references a placeholder or wrong registry:
|
|
1. Check if there's an existing CI/CD pipeline building to a different registry
|
|
2. Align the deployment with the existing pipeline rather than creating new infrastructure
|
|
3. Use the registry that other similar services in the same project are already using
|