fix(web): password input type + ci reusable workflow + multi-arch images#808
Merged
jsbroks merged 2 commits intoctrlplanedev:mainfrom Feb 18, 2026
Conversation
|
|
Contributor
📝 WalkthroughWalkthroughCentralizes Docker image build/push logic into a new reusable GitHub Actions workflow ( Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant WF as Caller Workflow (apps-*.yaml)
participant RW as Reusable Workflow (build-image.yaml)
participant Runner as GitHub Actions Runner
participant Registry as Docker Registry / Docker Hub
WF->>Runner: trigger job "build" (uses reusable workflow)
Runner->>RW: invoke reusable workflow with inputs (image-name, dockerfile, context)
RW->>Runner: checkout, setup QEMU & Buildx, compute metadata/tags
alt Docker creds available
RW->>Registry: login
RW->>Registry: push built image tags
else no creds / non-main branch
RW->>Runner: build image (no push)
end
RW->>WF: return job status and printed metadata summary
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 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)
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 |
![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: 3
🧹 Nitpick comments (1)
.github/workflows/build-image.yaml (1)
65-83: Consider adding build cache for multi-arch builds.Multi-arch builds (amd64 + arm64 via QEMU) are significantly slower than single-arch. Without
cache-from/cache-to, every build starts from scratch. GitHub Actions cache or registry-based caching can dramatically reduce build times.Example addition to both build steps:
cache-from: type=gha cache-to: type=gha,mode=max🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-image.yaml around lines 65 - 83, Add registry/GHA action build cache settings to the two docker/build-push-action@v6 steps ("Build" and "Build and Push") so multi-arch builds reuse layers: update the step inputs for both to include cache-from and cache-to entries (e.g., cache-from: type=gha and cache-to: type=gha,mode=max) ensuring the same cache keys are used across runs; keep other inputs (context, file, platforms, tags, push) unchanged.
🤖 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/build-image.yaml:
- Around line 85-92: Avoid interpolating `${{ steps.meta.outputs.tags }}`
directly in the shell run to prevent potential script injection; instead capture
it into an environment variable (e.g., IMAGE_TAGS) and echo that into
$GITHUB_STEP_SUMMARY. Update the Summary step so it sets IMAGE_TAGS to the value
of `steps.meta.outputs.tags` (via job/env or a preceding run that exports
IMAGE_TAGS) and then use `echo "$IMAGE_TAGS" >> $GITHUB_STEP_SUMMARY` in the run
block; reference the Summary step, the `GITHUB_STEP_SUMMARY` file, the
`steps.meta.outputs.tags` output, and the new `IMAGE_TAGS` env var when making
the change.
- Around line 57-63: Update the GitHub Action step that uses
docker/metadata-action by changing the version reference from
docker/metadata-action@v4 to docker/metadata-action@v5 in the step named
"Extract metadata (tags, labels) for Docker" (id: meta); ensure the uses line is
updated to docker/metadata-action@v5 and keep the existing inputs (images, tags)
unchanged so the metadata extraction continues to work with the newer runtime.
- Around line 42-48: Replace direct interpolation of ${{
secrets.DOCKERHUB_USERNAME }} and ${{ secrets.DOCKERHUB_TOKEN }} inside the run
block with workflow-level environment variables and reference those in the
shell; set env: DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }} and env:
DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }} on the step, then change the
test in the script to check the environment variables (e.g. if [ -z
"${DOCKERHUB_USERNAME}" ] || [ -z "${DOCKERHUB_TOKEN}" ] ) and write
DOCKERHUB_LOGIN to $GITHUB_ENV based on those checks so secrets are not expanded
directly into the shell.
---
Nitpick comments:
In @.github/workflows/build-image.yaml:
- Around line 65-83: Add registry/GHA action build cache settings to the two
docker/build-push-action@v6 steps ("Build" and "Build and Push") so multi-arch
builds reuse layers: update the step inputs for both to include cache-from and
cache-to entries (e.g., cache-from: type=gha and cache-to: type=gha,mode=max)
ensuring the same cache keys are used across runs; keep other inputs (context,
file, platforms, tags, push) unchanged.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/build-image.yaml (1)
68-86: Passlabelsfrom the metadata action into both build steps.
docker/metadata-actionemits alabelsoutput alongsidetags(OCIorg.opencontainers.image.*annotations such assource,revision,created, etc.). Both theBuildandBuild and Pushsteps currently omit it, so built images lack standard OCI metadata.♻️ Proposed fix
- name: Build uses: docker/build-push-action@v6 if: github.ref != 'refs/heads/main' with: context: ${{ inputs.context }} push: false file: ${{ inputs.dockerfile }} platforms: ${{ inputs.platform }} tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }} - name: Build and Push uses: docker/build-push-action@v6 if: github.ref == 'refs/heads/main' && env.DOCKERHUB_LOGIN == 'true' with: context: ${{ inputs.context }} push: true file: ${{ inputs.dockerfile }} platforms: ${{ inputs.platform }} tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/build-image.yaml around lines 68 - 86, The Build and Build and Push steps (uses: docker/build-push-action@v6) are missing the metadata labels output; add labels: ${{ steps.meta.outputs.labels }} to the with-block of both the "Build" and "Build and Push" steps so the images receive the OCI annotations emitted by the metadata action (in the same place where tags: ${{ steps.meta.outputs.tags }} is set).
🤖 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/build-image.yaml:
- Around line 29-31: Remove the unnecessary id-token permission from the
workflow permissions block: delete the "id-token: write" entry under the
permissions mapping (leave "contents: read" intact) so the permissions section
only grants the minimal "contents: read" scope and does not request OIDC
id-token access.
---
Duplicate comments:
In @.github/workflows/build-image.yaml:
- Around line 88-97: The summary step no longer interpolates GitHub output
directly into the shell but uses the IMAGE_TAGS env var; no code change
required—ensure the "Summary" step still sets env: IMAGE_TAGS: ${{
steps.meta.outputs.tags }} and writes IMAGE_TAGS to $GITHUB_STEP_SUMMARY as
shown (references: the "Summary" step and the IMAGE_TAGS environment variable).
- Around line 60-66: Confirmed upgrade of the docker/metadata-action to v5 in
the workflow step with id "meta" using "docker/metadata-action@v5"; no code
changes required—verify the step named "Extract metadata (tags, labels) for
Docker" still receives the correct inputs (images: ${{ inputs.image-name }} and
the tags block with type=sha,format=short,prefix=) and run the workflow to
ensure metadata generation behaves as expected.
- Around line 42-51: The secret interpolation issue has been resolved by mapping
secrets to step-level env vars and referencing them as $DOCKERHUB_USERNAME and
$DOCKERHUB_TOKEN inside the run block; no code changes are needed—keep the
existing step that sets DOCKERHUB_LOGIN in GITHUB_ENV based on
DOCKERHUB_USERNAME/DOCKERHUB_TOKEN and proceed with the merge.
---
Nitpick comments:
In @.github/workflows/build-image.yaml:
- Around line 68-86: The Build and Build and Push steps (uses:
docker/build-push-action@v6) are missing the metadata labels output; add labels:
${{ steps.meta.outputs.labels }} to the with-block of both the "Build" and
"Build and Push" steps so the images receive the OCI annotations emitted by the
metadata action (in the same place where tags: ${{ steps.meta.outputs.tags }} is
set).
Comment on lines
+29
to
+31
| permissions: | ||
| contents: read | ||
| id-token: write |
Contributor
There was a problem hiding this comment.
Remove the unnecessary id-token: write permission.
id-token: write is solely required to allow GitHub's OIDC provider to issue a JWT; it does not grant write access to repository resources, but it does expand the workflow's permission surface. This workflow authenticates to Docker Hub via static DOCKERHUB_USERNAME/DOCKERHUB_TOKEN secrets — no OIDC flow is involved — so the permission is superfluous and violates least-privilege.
🔒 Proposed fix
permissions:
contents: read
- id-token: write📝 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
| permissions: | |
| contents: read | |
| id-token: write | |
| permissions: | |
| contents: read |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/build-image.yaml around lines 29 - 31, Remove the
unnecessary id-token permission from the workflow permissions block: delete the
"id-token: write" entry under the permissions mapping (leave "contents: read"
intact) so the permissions section only grants the minimal "contents: read"
scope and does not request OIDC id-token access.
jsbroks
approved these changes
Feb 18, 2026
zachspar
deleted the
spar/fix/password-plaintext-and-multiarch-images
branch
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
3 participants
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.
Background
When basic auth is enabled, the password input is in plaintext. Also all images are built for
linux/amd64, so doing local chart development on ARM based hardware is not possible without emulation.What's Changed?
Summary by CodeRabbit
Bug Fixes
Chores