ci: fix the docker build matrix so partial service sets actually publish - #739
Conversation
…ce sets The include list carried one entry per service to attach a description. An include entry that cannot merge into an existing combination without overwriting a value becomes its own combination, so whenever detect returned a subset, the five unselected services were appended as platform-less combinations. runs-on resolved to empty and the whole build job failed to generate, publishing nothing while the result gate reported "Build failed" with no build jobs in the run. It only passed when all six services were affected. Descriptions now resolve in a step, leaving the matrix a plain service x platform product.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe PR repairs partial Docker publishing by removing service-only matrix
Confidence Score: 5/5The PR appears safe to merge and correctly restores Docker publishing for partial affected-service sets. The detected services are constrained to the six descriptions handled by the new step, and every selected service now expands only with platform objects that provide valid runners; no actionable regression remains. Important Files Changed
Reviews (1): Last reviewed commit: "ci(deps): stop the docker build matrix f..." | Re-trigger Greptile |
There was a problem hiding this comment.
1 issue found across 1 file
Confidence score: 4/5
- In
.github/workflows/docker-publish.yml, the publish case statement duplicates the service list maintained by thedetectjob; adding a service in only one place could cause the build to fail. Keep the lists synchronized or derive both steps from a single source of truth.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".github/workflows/docker-publish.yml">
<violation number="1" location=".github/workflows/docker-publish.yml:142">
P3: This case statement re-enumerates the six services that the `detect` job already lists in both its `ALL` array and its `for svc in ...` loop. Adding a service to `detect` without adding it here makes the build fail with `Unknown service $SERVICE`, so keep the three lists in sync (or drive the description from a shared source). Consider a comment cross-referencing the `detect` list to make the required alignment visible.</violation>
</file>
Architecture diagram
sequenceDiagram
participant GH as GitHub Actions Runner
participant Detect as Detect Affected Services Job
participant Matrix as Build Matrix
participant Build as Docker Build Job
participant Step as Resolve Description Step
participant Meta as Metadata Action
participant Publish as Publish Job
Note over GH,Publish: Docker Build Workflow - Current State
GH->>Detect: Trigger workflow on push/merge
Detect->>Detect: Determine affected services
Detect->>Matrix: Output service list (may be partial subset)
alt Full service set detected (all 6 services)
Matrix->>Matrix: Generate complete service x platform combos
else Partial service set detected (subset)
Matrix->>Matrix: Generate only affected services x platform combos
end
Matrix-->>Build: Matrix combinations with service + platform
Build->>Build: Initialize job with matrix.service + matrix.platform
Build->>Step: Run "Resolve service description" step
Step->>Step: Map service name to description text
Step-->>Build: Description output
alt Valid service name
Step-->>Build: Return description text
else Unknown service
Step->>Build: Exit with error "Unknown service"
Build-->>Publish: Job fails, no image published
end
Build->>Meta: Run docker/metadata-action
Meta->>Meta: Extract labels with service description
Meta-->>Build: Metadata including org.opencontainers.image.description
Build->>Build: Build Docker image with platform-specific runner
Build-->>Publish: Image built successfully
Publish->>Publish: Create/update multi-arch manifest
Publish->>GH: Mark job as successful
GH-->>Publish: Workflow completed
Note over Matrix,Build: Key change: Description resolved in step,<br/>not in matrix include - ensures every<br/>combination has a platform runner
Shadow auto-approve: would not auto-approve because issues were found.
Re-trigger cubic
| insights) text="Databuddy Insights service - queued insight generation" ;; | ||
| links) text="Databuddy Links service - URL shortening and tracking" ;; | ||
| uptime) text="Databuddy Uptime service - availability monitoring" ;; | ||
| *) echo "Unknown service $SERVICE" >&2; exit 1 ;; |
There was a problem hiding this comment.
P3: This case statement re-enumerates the six services that the detect job already lists in both its ALL array and its for svc in ... loop. Adding a service to detect without adding it here makes the build fail with Unknown service $SERVICE, so keep the three lists in sync (or drive the description from a shared source). Consider a comment cross-referencing the detect list to make the required alignment visible.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/docker-publish.yml, line 142:
<comment>This case statement re-enumerates the six services that the `detect` job already lists in both its `ALL` array and its `for svc in ...` loop. Adding a service to `detect` without adding it here makes the build fail with `Unknown service $SERVICE`, so keep the three lists in sync (or drive the description from a shared source). Consider a comment cross-referencing the `detect` list to make the required alignment visible.</comment>
<file context>
@@ -140,14 +127,30 @@ jobs:
+ insights) text="Databuddy Insights service - queued insight generation" ;;
+ links) text="Databuddy Links service - URL shortening and tracking" ;;
+ uptime) text="Databuddy Uptime service - availability monitoring" ;;
+ *) echo "Unknown service $SERVICE" >&2; exit 1 ;;
+ esac
+ echo "text=$text" >> "$GITHUB_OUTPUT"
</file context>
The
buildjob attached image descriptions with a per-serviceincludelist. A matrixincludeentry that cannot merge into an existing combination without overwriting a value becomes its own combination instead, so wheneverdetectreturned a subset of services, the unselected ones were appended as combinations carrying onlyserviceanddescriptionand noplatform.runs-on: ${{ matrix.platform.runner }}then resolved to empty, the build job failed to generate, and the run finished with:Detect affected services— successPublish <service> manifest— skippedDocker Publish Result— failure, printing "Build failed" with zero build jobs in the runNothing was published. The workflow only passed when all six services were affected, which is why it looked healthy on wide-reaching merges.
This bit
78abcc8b3: the Better-Auth audit fix merged,Publish Docker Imagesfailed this way, and the API image was never built, so the fix is not yet running in production. Descriptions now resolve in a step, leaving the matrix a plainservice x platformproduct where every combination has a runner.Also carries
cc8923cae(insights copy, already reviewed in #737).Summary by cubic
Fixes the Docker build matrix so partial service sets actually publish images instead of silently failing with zero build jobs.
The matrix
includelist attached per-service descriptions, but unselected services became platform-less combinations whendetectreturned a subset, soruns-onresolved empty and the whole build job failed to generate. Descriptions now resolve in a step, leaving the matrix a plain service × platform product.This also means the Better-Auth audit fix from
78abcc8b3was never built into the API image and is now finally running in production.Written for commit e3ee66d. Summary will update on new commits.