ci: push PR images to Quay and tag full stack for deployment#1077
Merged
Gkrumbach07 merged 5 commits intomainfrom Mar 27, 2026
Merged
ci: push PR images to Quay and tag full stack for deployment#1077Gkrumbach07 merged 5 commits intomainfrom
Gkrumbach07 merged 5 commits intomainfrom
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughWorkflow triggers for Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant Git as Git
participant Runner as Build Runner
participant Registry as Container Registry
Dev->>Git: push or open PR
Git->>GH: webhook (push / pull_request)
GH->>GH: read inputs (optional `components`) or default to all
alt PR
GH->>Git: fetch base branch (if needed)
GH->>GH: compute merge-base (used for tagging/sha)
end
GH->>Runner: build & push component images (selected or all)
Runner->>Registry: push images (sha tags)
alt push to main
GH->>Registry: create manifests -> `latest`, `stage`, `${sha}`
else push to alpha
GH->>Registry: create manifests -> `alpha`, `${sha}`
else pull_request
GH->>Registry: create PR manifest (existing PR flow)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/components-build-deploy.yml (1)
78-95: 🧹 Nitpick | 🔵 TrivialConsider adding the workflow file to paths-filter or documenting the behavior.
The workflow file
.github/workflows/components-build-deploy.ymlis in thepathstrigger (line 7) but not in thepaths-filterstep. This means workflow-only changes will trigger the pipeline withhas-builds=falseandhas-unchanged=true, causing all components to be aliased from merge-base.If this is intentional (useful for testing workflow changes), consider adding a comment documenting this behavior. Otherwise, consider either:
- Adding a filter for workflow changes that forces a full rebuild, or
- Removing the workflow file from the trigger paths
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/components-build-deploy.yml around lines 78 - 95, The paths-filter step (id: filter) lacks a filter for workflow file changes, so workflow-only edits still run the pipeline with has-builds=false and causes all components to be aliased; to fix, either add a new filter key (e.g., workflows) under the filters block that matches '.github/workflows/**' and configure it to force a full rebuild, or document this intentional behavior near the paths trigger and the filter step (id: filter) so reviewers know workflow edits will trigger the aliasing behavior; update the filters block (keys like frontend, backend, operator, claude-runner, state-sync, public-api, ambient-api-server) accordingly or remove the workflow file from the paths trigger if you prefer not to trigger on workflow-only changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 281-312: In the tag-unchanged-for-pr job, before running docker
buildx imagetools create, add a pre-flight existence check for the source image
(${IMAGE}:${MERGE_BASE}) inside the same "Tag ${{ matrix.component.name }} from
merge base as pr-${{ github.event.pull_request.number }}" run block: attempt to
inspect the image (e.g., docker buildx imagetools inspect
"${IMAGE}:${MERGE_BASE}" || docker manifest inspect "${IMAGE}:${MERGE_BASE}")
and if the inspect fails, print a clear error mentioning MERGE_BASE, IMAGE and
PR_TAG and exit 1; only run docker buildx imagetools create when the inspect
succeeds. This ensures you fail fast with a helpful message rather than the
confusing buildx error.
- Around line 67-75: The shallow fetch with git fetch origin "${BASE_REF}"
--depth=50 in the "Determine merge base for PR" step (id: merge-base) can miss
the true merge base, so update that step to attempt an unshallow/deeper fetch if
git merge-base returns empty or fails: after computing SHA=$(git merge-base
"origin/${BASE_REF}" ${{ github.event.pull_request.head.sha }}), check if SHA is
empty or the command failed, then run git fetch --unshallow or git fetch origin
"${BASE_REF}" --depth=1000 (or loop increasing depth), recompute SHA, and if
still empty emit a clear error via echo and exit non-zero; ensure variables
BASE_REF and SHA are preserved and logged for debugging.
---
Outside diff comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 78-95: The paths-filter step (id: filter) lacks a filter for
workflow file changes, so workflow-only edits still run the pipeline with
has-builds=false and causes all components to be aliased; to fix, either add a
new filter key (e.g., workflows) under the filters block that matches
'.github/workflows/**' and configure it to force a full rebuild, or document
this intentional behavior near the paths trigger and the filter step (id:
filter) so reviewers know workflow edits will trigger the aliasing behavior;
update the filters block (keys like frontend, backend, operator, claude-runner,
state-sync, public-api, ambient-api-server) accordingly or remove the workflow
file from the paths trigger if you prefer not to trigger on workflow-only
changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 262c161f-6e99-4b8b-ad89-3af55da22b6b
📒 Files selected for processing (1)
.github/workflows/components-build-deploy.yml
Comment on lines
+281
to
+312
| tag-unchanged-for-pr: | ||
| needs: [detect-changes] | ||
| if: github.event_name == 'pull_request' && needs.detect-changes.outputs.has-unchanged == 'true' | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: read | ||
| id-token: write | ||
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| component: ${{ fromJSON(needs.detect-changes.outputs.unchanged-matrix) }} | ||
| steps: | ||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
|
|
||
| - name: Log in to Quay.io | ||
| uses: docker/login-action@v3 | ||
| with: | ||
| registry: quay.io | ||
| username: ${{ secrets.QUAY_USERNAME }} | ||
| password: ${{ secrets.QUAY_PASSWORD }} | ||
|
|
||
| - name: Tag ${{ matrix.component.name }} from merge base as pr-${{ github.event.pull_request.number }} | ||
| run: | | ||
| MERGE_BASE="${{ needs.detect-changes.outputs.merge-base-sha }}" | ||
| PR_TAG="pr-${{ github.event.pull_request.number }}" | ||
| IMAGE="${{ matrix.component.image }}" | ||
|
|
||
| echo "Aliasing ${IMAGE}:${MERGE_BASE} → ${IMAGE}:${PR_TAG}" | ||
| docker buildx imagetools create \ | ||
| -t "${IMAGE}:${PR_TAG}" \ | ||
| "${IMAGE}:${MERGE_BASE}" |
Contributor
There was a problem hiding this comment.
Add validation that merge-base image exists before attempting to tag.
The docker buildx imagetools create command will fail with a confusing error if ${IMAGE}:${MERGE_BASE} doesn't exist in Quay. This can happen if:
- The merge-base commit didn't trigger a build (paths filter didn't match)
- The image was pruned by Quay's tag expiration policy
- The alpha branch is new and has no prior images
Consider adding a pre-flight check to verify the source image exists and provide a clear error message.
🛡️ Proposed fix with existence check
- name: Tag ${{ matrix.component.name }} from merge base as pr-${{ github.event.pull_request.number }}
run: |
MERGE_BASE="${{ needs.detect-changes.outputs.merge-base-sha }}"
PR_TAG="pr-${{ github.event.pull_request.number }}"
IMAGE="${{ matrix.component.image }}"
+ # Verify source image exists
+ if ! docker buildx imagetools inspect "${IMAGE}:${MERGE_BASE}" > /dev/null 2>&1; then
+ echo "::error::Source image ${IMAGE}:${MERGE_BASE} not found in registry. The merge-base commit may not have been built."
+ echo "::error::Consider rebasing onto a more recent commit that has images available."
+ exit 1
+ fi
+
echo "Aliasing ${IMAGE}:${MERGE_BASE} → ${IMAGE}:${PR_TAG}"
docker buildx imagetools create \
-t "${IMAGE}:${PR_TAG}" \
"${IMAGE}:${MERGE_BASE}"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| tag-unchanged-for-pr: | |
| needs: [detect-changes] | |
| if: github.event_name == 'pull_request' && needs.detect-changes.outputs.has-unchanged == 'true' | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read | |
| id-token: write | |
| strategy: | |
| fail-fast: false | |
| matrix: | |
| component: ${{ fromJSON(needs.detect-changes.outputs.unchanged-matrix) }} | |
| steps: | |
| - name: Set up Docker Buildx | |
| uses: docker/setup-buildx-action@v3 | |
| - name: Log in to Quay.io | |
| uses: docker/login-action@v3 | |
| with: | |
| registry: quay.io | |
| username: ${{ secrets.QUAY_USERNAME }} | |
| password: ${{ secrets.QUAY_PASSWORD }} | |
| - name: Tag ${{ matrix.component.name }} from merge base as pr-${{ github.event.pull_request.number }} | |
| run: | | |
| MERGE_BASE="${{ needs.detect-changes.outputs.merge-base-sha }}" | |
| PR_TAG="pr-${{ github.event.pull_request.number }}" | |
| IMAGE="${{ matrix.component.image }}" | |
| echo "Aliasing ${IMAGE}:${MERGE_BASE} → ${IMAGE}:${PR_TAG}" | |
| docker buildx imagetools create \ | |
| -t "${IMAGE}:${PR_TAG}" \ | |
| "${IMAGE}:${MERGE_BASE}" | |
| tag-unchanged-for-pr: | |
| needs: [detect-changes] | |
| if: github.event_name == 'pull_request' && needs.detect-changes.outputs.has-unchanged == 'true' | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read | |
| id-token: write | |
| strategy: | |
| fail-fast: false | |
| matrix: | |
| component: ${{ fromJSON(needs.detect-changes.outputs.unchanged-matrix) }} | |
| steps: | |
| - name: Set up Docker Buildx | |
| uses: docker/setup-buildx-action@v3 | |
| - name: Log in to Quay.io | |
| uses: docker/login-action@v3 | |
| with: | |
| registry: quay.io | |
| username: ${{ secrets.QUAY_USERNAME }} | |
| password: ${{ secrets.QUAY_PASSWORD }} | |
| - name: Tag ${{ matrix.component.name }} from merge base as pr-${{ github.event.pull_request.number }} | |
| run: | | |
| MERGE_BASE="${{ needs.detect-changes.outputs.merge-base-sha }}" | |
| PR_TAG="pr-${{ github.event.pull_request.number }}" | |
| IMAGE="${{ matrix.component.image }}" | |
| # Verify source image exists | |
| if ! docker buildx imagetools inspect "${IMAGE}:${MERGE_BASE}" > /dev/null 2>&1; then | |
| echo "::error::Source image ${IMAGE}:${MERGE_BASE} not found in registry. The merge-base commit may not have been built." | |
| echo "::error::Consider rebasing onto a more recent commit that has images available." | |
| exit 1 | |
| fi | |
| echo "Aliasing ${IMAGE}:${MERGE_BASE} → ${IMAGE}:${PR_TAG}" | |
| docker buildx imagetools create \ | |
| -t "${IMAGE}:${PR_TAG}" \ | |
| "${IMAGE}:${MERGE_BASE}" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/components-build-deploy.yml around lines 281 - 312, In the
tag-unchanged-for-pr job, before running docker buildx imagetools create, add a
pre-flight existence check for the source image (${IMAGE}:${MERGE_BASE}) inside
the same "Tag ${{ matrix.component.name }} from merge base as pr-${{
github.event.pull_request.number }}" run block: attempt to inspect the image
(e.g., docker buildx imagetools inspect "${IMAGE}:${MERGE_BASE}" || docker
manifest inspect "${IMAGE}:${MERGE_BASE}") and if the inspect fails, print a
clear error mentioning MERGE_BASE, IMAGE and PR_TAG and exit 1; only run docker
buildx imagetools create when the inspect succeeds. This ensures you fail fast
with a helpful message rather than the confusing buildx error.
For PRs that only change a subset of components, unchanged components
now get their merge-base image aliased as pr-{number} in Quay, so the
full stack can be deployed with a single consistent tag.
Also adds alpha to push/PR branch triggers so PRs targeting alpha have
merge-base images available in the registry.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Split merge-manifests into main (latest/stage/sha) and alpha (alpha/sha) so alpha never touches main's tags - Compute base SHA for both PRs (merge-base) and pushes (parent commit) - Unchanged components on alpha pushes get aliased from parent commit SHA - No cross-contamination: alpha and main tagging are fully independent Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Gkrumbach07
force-pushed
the
ci/pr-image-tagging-and-alpha-builds
branch
from
8aba27b to
46a98cd
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 358-366: Add a pre-check in the "Tag ... as alpha" step to
validate that the source image tag exists before calling docker buildx
imagetools create: use the PARENT_SHA and IMAGE variables to attempt inspection
(e.g., docker manifest inspect "${IMAGE}:${PARENT_SHA}" or an equivalent
registry API call) and, if the inspect call fails or returns non-200, log a
clear message and skip/exit the step gracefully instead of running docker buildx
imagetools create; ensure the step refers to PARENT_SHA and IMAGE and only runs
the imagetools create when the existence check succeeds.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2ba6c97f-3291-4d69-9e18-9a64b2ece048
📒 Files selected for processing (1)
.github/workflows/components-build-deploy.yml
Comment on lines
+358
to
+366
| - name: Tag ${{ matrix.component.name }} from parent commit as alpha | ||
| run: | | ||
| PARENT_SHA="${{ needs.detect-changes.outputs.merge-base-sha }}" | ||
| IMAGE="${{ matrix.component.image }}" | ||
|
|
||
| echo "Aliasing ${IMAGE}:${PARENT_SHA} → ${IMAGE}:alpha" | ||
| docker buildx imagetools create \ | ||
| -t "${IMAGE}:alpha" \ | ||
| "${IMAGE}:${PARENT_SHA}" |
Contributor
There was a problem hiding this comment.
Add validation that parent commit image exists before attempting to tag.
Same issue as the PR aliasing job: if ${IMAGE}:${PARENT_SHA} doesn't exist in Quay (parent commit didn't trigger a build for this component, or images were pruned), the docker buildx imagetools create command will fail with a confusing error.
🛡️ Proposed fix with existence check
- name: Tag ${{ matrix.component.name }} from parent commit as alpha
run: |
PARENT_SHA="${{ needs.detect-changes.outputs.merge-base-sha }}"
IMAGE="${{ matrix.component.image }}"
+ # Verify source image exists
+ if ! docker buildx imagetools inspect "${IMAGE}:${PARENT_SHA}" > /dev/null 2>&1; then
+ echo "::warning::Source image ${IMAGE}:${PARENT_SHA} not found. Skipping alpha tag for this component."
+ echo "::warning::The parent commit may not have built this component."
+ exit 0
+ fi
+
echo "Aliasing ${IMAGE}:${PARENT_SHA} → ${IMAGE}:alpha"
docker buildx imagetools create \
-t "${IMAGE}:alpha" \
"${IMAGE}:${PARENT_SHA}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/components-build-deploy.yml around lines 358 - 366, Add a
pre-check in the "Tag ... as alpha" step to validate that the source image tag
exists before calling docker buildx imagetools create: use the PARENT_SHA and
IMAGE variables to attempt inspection (e.g., docker manifest inspect
"${IMAGE}:${PARENT_SHA}" or an equivalent registry API call) and, if the inspect
call fails or returns non-200, log a clear message and skip/exit the step
gracefully instead of running docker buildx imagetools create; ensure the step
refers to PARENT_SHA and IMAGE and only runs the imagetools create when the
existence check succeeds.
The checkout action uses fetch-depth=1. git merge-base needs history from both branches to find their common ancestor, so deepen the clone before computing the merge base. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.github/workflows/components-build-deploy.yml (2)
276-296:⚠️ Potential issue | 🟠 MajorManual dispatches now deploy the wrong tags outside
main.After this split, a
workflow_dispatchonalphapublishesalpha/${github.sha}, butdeploy-with-disptachstill rolls outstagefor most components, so it ignores the fresh build. On any other ref, no manifests are created at all, yet runner/state-sync can still be pinned to${github.sha}. Either keep the old dispatch manifest path or restrict the deploy job to refs that publish the tags it consumes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/components-build-deploy.yml around lines 276 - 296, The workflow currently creates multi-arch manifests only for refs main and alpha, causing manual workflow_dispatch on alpha (or other refs) to publish tags that the deploy job (deploy-with-dispatch) doesn't consume; update the manifest creation steps to match what deploy-with-dispatch expects or constrain deploy-with-dispatch to only run on refs that publish those tags. Concretely, modify the docker buildx imagetools create invocation(s) to include the same tag set that deploy-with-dispatch consumes (e.g., add the :stage tag and ${github.sha}:stage/arch variants when handling alpha or add a catch-all branch that creates the ${github.sha} and :stage manifests), or change the deploy-with-dispatch trigger/if condition to only run on refs where those tags are produced; reference matrix.component.image, ${github.sha}, the existing "Create multi-arch manifest for ... (alpha)" step, and the deploy-with-dispatch job when making the change.
276-296:⚠️ Potential issue | 🔴 CriticalPartial branch builds never backfill commit tags for unchanged images.
Lines 282-295 only create
${github.sha}for components inmerge-matrix. The new alias jobs then usemerge-base-sha/PARENT_SHAas the source for unchanged components, but those commit tags were never created for untouched images. Example: commitArebuilds onlyfrontend; the next partial run that usesAas its base will fail at Line 337 or Line 369 when it looks forbackend:A,state-sync:A, etc. Please publish${github.sha}for unchanged components onmain/alphaas well.Also applies to: 328-337, 361-369
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/components-build-deploy.yml around lines 276 - 296, The multi-arch manifest steps for main/alpha currently omit publishing the ${github.sha} tag for components that weren't rebuilt, causing later alias jobs (which use merge-base-sha / PARENT_SHA) to fail when looking up e.g. backend:${github.sha}. Update the two imagetools create blocks (the "Create multi-arch manifest for ${{ matrix.component.name }} (main)" and "(alpha)") to always include -t ${{ matrix.component.image }}:${{ github.sha }} and ensure the source images include the arch-suffixed tags for the base/parent commit (use the existing merge-base-sha / PARENT_SHA variables or matrix component base SHA equivalents as the source images), so unchanged components get a ${github.sha} tag created even when only some components were rebuilt.
♻️ Duplicate comments (1)
.github/workflows/components-build-deploy.yml (1)
67-76:⚠️ Potential issue | 🟠 Major
git merge-baseis still brittle with long-lived PRs.Both fetches are still capped at 100 commits. If the common ancestor sits outside that window, Line 76 fails again and the workflow never produces
merge-base-sha. Please add a deeper-fetch/--unshallowfallback before usingSHA.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/components-build-deploy.yml around lines 67 - 76, The merge-base step (id: merge-base) is brittle because both git fetch calls are limited to --depth=100 so SHA=$(git merge-base ...) can fail for long-lived PRs; modify the step to attempt a deeper fetch or unshallow before computing SHA: first try increasing history (e.g., additional git fetch --deepen or fetching origin/${BASE_REF} without depth), and if that still might be shallow run git fetch --unshallow as a fallback, then compute SHA=$(git merge-base "origin/${BASE_REF}" ${{ github.event.pull_request.head.sha }}); ensure any fetch errors are handled so merge-base-sha is produced reliably.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 276-296: The workflow currently creates multi-arch manifests only
for refs main and alpha, causing manual workflow_dispatch on alpha (or other
refs) to publish tags that the deploy job (deploy-with-dispatch) doesn't
consume; update the manifest creation steps to match what deploy-with-dispatch
expects or constrain deploy-with-dispatch to only run on refs that publish those
tags. Concretely, modify the docker buildx imagetools create invocation(s) to
include the same tag set that deploy-with-dispatch consumes (e.g., add the
:stage tag and ${github.sha}:stage/arch variants when handling alpha or add a
catch-all branch that creates the ${github.sha} and :stage manifests), or change
the deploy-with-dispatch trigger/if condition to only run on refs where those
tags are produced; reference matrix.component.image, ${github.sha}, the existing
"Create multi-arch manifest for ... (alpha)" step, and the deploy-with-dispatch
job when making the change.
- Around line 276-296: The multi-arch manifest steps for main/alpha currently
omit publishing the ${github.sha} tag for components that weren't rebuilt,
causing later alias jobs (which use merge-base-sha / PARENT_SHA) to fail when
looking up e.g. backend:${github.sha}. Update the two imagetools create blocks
(the "Create multi-arch manifest for ${{ matrix.component.name }} (main)" and
"(alpha)") to always include -t ${{ matrix.component.image }}:${{ github.sha }}
and ensure the source images include the arch-suffixed tags for the base/parent
commit (use the existing merge-base-sha / PARENT_SHA variables or matrix
component base SHA equivalents as the source images), so unchanged components
get a ${github.sha} tag created even when only some components were rebuilt.
---
Duplicate comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 67-76: The merge-base step (id: merge-base) is brittle because
both git fetch calls are limited to --depth=100 so SHA=$(git merge-base ...) can
fail for long-lived PRs; modify the step to attempt a deeper fetch or unshallow
before computing SHA: first try increasing history (e.g., additional git fetch
--deepen or fetching origin/${BASE_REF} without depth), and if that still might
be shallow run git fetch --unshallow as a fallback, then compute SHA=$(git
merge-base "origin/${BASE_REF}" ${{ github.event.pull_request.head.sha }});
ensure any fetch errors are handled so merge-base-sha is produced reliably.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: d58c74d0-c393-4500-bfa0-285fbb512501
📒 Files selected for processing (1)
.github/workflows/components-build-deploy.yml
Replace the merge-base aliasing approach with simply building all
components. Docker layer cache makes unchanged components fast cache
hits, and this eliminates all the complexity around merge-base
detection, unchanged matrices, and tag-aliasing jobs.
- PRs: build all 7 components, tag as pr-{number}
- Alpha push: build all 7 components, tag as alpha
- Main push: still only builds changed components (existing behavior)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Cache makes unchanged components fast, so just build everything on every trigger. Only exception: workflow_dispatch still supports selecting specific components. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pr-{number}tags (previously build-only)pr-{number}, so the entire stack is deployable with a single consistent tagalphanow build and push images, and PRs targetingalphatrigger the workflowgithub.event.pull_request.base.refto resolve the correct base regardless of target branchDeploy jobs remain
main-only — no changes there.Test plan
pr-{number}tag in Quayalphabranch and verify images are built and pushedalphaand verify merge-base resolution worksmain🤖 Generated with Claude Code