AddComponentBatch was missing the SERVICE_NAME injection that AddComponent
has. When an app-react component (e.g. creator-ui) was rendered via the
batch endpoint alongside a service component, {{SERVICE_NAME}} in App.tsx.tmpl
was never substituted — rendering the literal string into the repo.
Fix: scan the batch's own code requests for a service component first
(since the service isn't in the DB yet during batch processing), then
fall back to findFirstServiceComponent from DB.
This is the same AddComponent vs AddComponentBatch parity gap that caused
the JWT_SECRET issue (RC-2). The auth API URL in every app-react project
was broken when deployed via the batch endpoint.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
AddComponent (single-component path) already calls ensureProjectJWTSecret,
but AddComponentBatch has its own parallel implementation that bypassed it.
Components added via the /batch endpoint never had JWT_SECRET provisioned,
causing CrashLoopBackOff on startup ("JWT_SECRET must be set").
Add the call before the createInitialComponentDeployment loop so the secret
is stored in the credential store before K8s Secrets are created.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Three coordinated fixes for CI pipeline race conditions:
1. Woodpecker step dependencies: Added depends_on: [deps] to all 6 component
templates (service, worker, cli, app-astro, app-react, app-nextjs) so build
steps wait for go work sync to complete.
2. Idempotent resource provisioning: Modified provisionResources() to check
for existing database/cache before creating, preventing "already exists"
errors on component re-adds.
3. Batch component endpoint: POST /projects/{id}/components/batch enables
atomic multi-component additions in a single git commit. Validates all
components upfront, provisions infra sequentially, commits code components
atomically.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
