Automate Woodpecker secret sync after Harbor robot rotation #245

New issue

Open

opened 2026-03-28 23:26:55 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-03-28 23:26:55 +00:00

Owner

Type

Feature

Lineage

Board: board-pal-e-platform
Story: story:superuser-deploy
Arch: arch:ci-pipeline
Discovered from: #234 (pal-e-docs-app ImagePullBackOff → Harbor 401)

Repo

forgejo_admin/pal-e-services (terraform manages Harbor robots) + Woodpecker API (secrets target)

User Story

As the platform operator, I need Woodpecker CI secrets to stay in sync with Harbor robot accounts so that tofu apply doesn't silently stale all downstream CI pipelines.

Context

Harbor robot accounts are terraform-managed (harbor_robot_account.service_ci). Woodpecker secrets are manually set per SERVICE_ONBOARDING.md Step 4. When tofu apply recreates a robot (new credentials), the Woodpecker secrets become stale, causing 401 Unauthorized on image push. This broke pal-e-docs-app (#234) — the robot was created by terraform but Woodpecker still had old creds.

File Targets

~/pal-e-services/main.tf or modules/ — add Woodpecker secret provisioning via terraform or post-apply script
Alternative: scripts/sync-harbor-creds.sh — post-apply script that reads tofu output and updates Woodpecker secrets via API

Acceptance Criteria

After tofu apply that rotates Harbor robots, Woodpecker secrets are automatically updated
No manual SERVICE_ONBOARDING.md Step 4 needed for existing services
New service onboarding still works

Test Expectations

tofu apply on a test service → Woodpecker secret matches new robot credentials
Pipeline pushes to Harbor successfully with synced credentials

Constraints

Woodpecker API requires admin token for secret management
Must handle the case where tofu doesn't change robot (no-op apply)
Don't break existing manual secret workflow during transition

Checklist

Design approach (terraform resource vs post-apply script)
Implement sync mechanism
Test with one service
Roll out to all services

#234 — pal-e-docs-app ImagePullBackOff (the incident that exposed this)
service-onboarding-sop — Step 4 (manual secret setup)

### Type Feature ### Lineage - Board: board-pal-e-platform - Story: story:superuser-deploy - Arch: arch:ci-pipeline - Discovered from: #234 (pal-e-docs-app ImagePullBackOff → Harbor 401) ### Repo `forgejo_admin/pal-e-services` (terraform manages Harbor robots) + Woodpecker API (secrets target) ### User Story As the platform operator, I need Woodpecker CI secrets to stay in sync with Harbor robot accounts so that `tofu apply` doesn't silently stale all downstream CI pipelines. ### Context Harbor robot accounts are terraform-managed (`harbor_robot_account.service_ci`). Woodpecker secrets are manually set per SERVICE_ONBOARDING.md Step 4. When `tofu apply` recreates a robot (new credentials), the Woodpecker secrets become stale, causing 401 Unauthorized on image push. This broke pal-e-docs-app (#234) — the robot was created by terraform but Woodpecker still had old creds. ### File Targets - `~/pal-e-services/main.tf` or `modules/` — add Woodpecker secret provisioning via terraform or post-apply script - Alternative: `scripts/sync-harbor-creds.sh` — post-apply script that reads `tofu output` and updates Woodpecker secrets via API ### Acceptance Criteria - [ ] After `tofu apply` that rotates Harbor robots, Woodpecker secrets are automatically updated - [ ] No manual SERVICE_ONBOARDING.md Step 4 needed for existing services - [ ] New service onboarding still works ### Test Expectations - [ ] `tofu apply` on a test service → Woodpecker secret matches new robot credentials - [ ] Pipeline pushes to Harbor successfully with synced credentials ### Constraints - Woodpecker API requires admin token for secret management - Must handle the case where tofu doesn't change robot (no-op apply) - Don't break existing manual secret workflow during transition ### Checklist - [ ] Design approach (terraform resource vs post-apply script) - [ ] Implement sync mechanism - [ ] Test with one service - [ ] Roll out to all services ### Related - #234 — pal-e-docs-app ImagePullBackOff (the incident that exposed this) - `service-onboarding-sop` — Step 4 (manual secret setup)