Conversation
Add provenance: false to both build steps to prevent Buildx from wrapping images in manifest lists, which caused docker manifest create to fail with "is a manifest list" error. Re-enable amd64 build and create-manifest jobs. Add --ignore-warnings ARM64-COW-BUG to redis-server in both Dockerfiles so Redis starts on ARM64 kernels instead of exiting with a copy-on-write bug warning.
📝 WalkthroughWalkthroughWorkflow Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant User as "User\n(dispatch)"
participant GA as "GitHub Actions\n(publish workflow)"
participant API as "GitHub API"
participant Runner as "Build Runner"
participant Docker as "docker/build-push\n(action)"
rect rgba(0,128,255,0.5)
User->>GA: Trigger (with or without `tag`)
end
GA->>GA: resolve-tag job evaluates `tag` input
alt tag provided (non-empty)
GA->>API: Query tag → get commit SHA
API-->>GA: commit SHA + tag name
GA->>Runner: set VERSION = tag without leading `v` (sanitize)
else tag empty
GA->>Runner: use github.sha and github.ref_name → set VERSION (sanitize)
end
Runner->>Docker: build & push images (provenance=false)
Docker-->>Runner: push result
Runner->>Runner: container entrypoint starts `redis-server --ignore-warnings ARM64-COW-BUG`
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip You can make CodeRabbit's review stricter and more nitpicky using the `assertive` profile, if that's what you prefer.Change the |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
Dockerfile (1)
193-193:--ignore-warnings ARM64-COW-BUGis unnecessary in the x86_64 Dockerfile.This flag suppresses a Redis warning specific to ARM64 architectures. Since this Dockerfile targets x86_64 (line 70 downloads
Miniforge3-Linux-x86_64.sh), the flag has no effect here. It's harmless but adds noise.Consider keeping this flag only in
Dockerfile.armfor clarity, or leave it for consistency if you prefer identical entrypoint scripts across architectures.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile` at line 193, The redis startup command includes the ARM-specific flag "--ignore-warnings ARM64-COW-BUG" which is unnecessary for the x86_64 Dockerfile; remove that flag from the line containing "redis-server --daemonize yes --dir /var/lib/redis --appendonly no" in this Dockerfile, or alternatively only add the flag in the ARM-specific Dockerfile (e.g., Dockerfile.arm) so the x86_64 build stays clean.
🤖 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/publish-docker-images.yml:
- Around line 34-47: When computing VERSION from branch names (when TAG is empty
and when using github.event.workflow_run.head_branch), sanitize the derived
VERSION (the variables VERSION and any use of github.ref_name /
github.event.workflow_run.head_branch) by replacing slashes with hyphens and
stripping or replacing any characters invalid for Docker tags (e.g., convert "/"
-> "-" and remove/replace characters outside [A-Za-z0-9_.-], optionally
lowercasing) so the produced Docker tag is valid; apply this sanitization
immediately after assigning VERSION in both branches of the conditional (the
blocks that set VERSION="${{ github.ref_name }}" and VERSION="${TAG#v}" when
coming from workflow_run) and before using VERSION to tag images.
---
Nitpick comments:
In `@Dockerfile`:
- Line 193: The redis startup command includes the ARM-specific flag
"--ignore-warnings ARM64-COW-BUG" which is unnecessary for the x86_64
Dockerfile; remove that flag from the line containing "redis-server --daemonize
yes --dir /var/lib/redis --appendonly no" in this Dockerfile, or alternatively
only add the flag in the ARM-specific Dockerfile (e.g., Dockerfile.arm) so the
x86_64 build stays clean.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5dc23b5e-17c7-46a8-885f-a536e1d311b1
📒 Files selected for processing (3)
.github/workflows/publish-docker-images.ymlDockerfileDockerfile.arm
- Remove ENV GH_TOKEN to prevent token from persisting in published images; use inline env var scoped to the gh release download command only - Re-declare GITHUB_USER/GITHUB_REPO ARGs in run-app stage (ARGs don't persist across FROM boundaries) - Add disk space cleanup step to CI build jobs to prevent runner exhaustion - Remove stale thirdparty PATH entries (Sirius, Fido, etc.) and add Sage - Upgrade actions/checkout from v3 to v4
There was a problem hiding this comment.
🧹 Nitpick comments (1)
Dockerfile (1)
192-192: ARM64-specific flag in x86_64 Dockerfile.The
--ignore-warnings ARM64-COW-BUGflag is specific to ARM64 architecture and has no effect on x86_64. While harmless (Redis ignores unrecognized warning names), you may want to keep the Dockerfiles architecture-specific for clarity.Consider removing this flag from the x86_64 Dockerfile to maintain clean separation:
♻️ Suggested change
-redis-server --daemonize yes --dir /var/lib/redis --appendonly no --ignore-warnings ARM64-COW-BUG\n\ +redis-server --daemonize yes --dir /var/lib/redis --appendonly no\n\🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@Dockerfile` at line 192, The Dockerfile contains an x86_64-specific invocation of redis-server that includes the ARM64-only option '--ignore-warnings ARM64-COW-BUG'; remove that token from the x86_64 Dockerfile command (the line starting with "redis-server --daemonize yes --dir /var/lib/redis --appendonly no ...") so the command becomes architecture-neutral, and keep the flag only in the ARM64 Dockerfile variant if one exists.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@Dockerfile`:
- Line 192: The Dockerfile contains an x86_64-specific invocation of
redis-server that includes the ARM64-only option '--ignore-warnings
ARM64-COW-BUG'; remove that token from the x86_64 Dockerfile command (the line
starting with "redis-server --daemonize yes --dir /var/lib/redis --appendonly no
...") so the command becomes architecture-neutral, and keep the flag only in the
ARM64 Dockerfile variant if one exists.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 86803f48-1d7d-4a02-961d-c032d16f706a
📒 Files selected for processing (3)
.github/workflows/build-docker-images.ymlDockerfileDockerfile.arm
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/publish-docker-images.yml:
- Around line 49-50: After sanitizing VERSION (the line using VERSION=$(echo
"$VERSION" | tr '/' '-' | tr -cd 'A-Za-z0-9_.-')), validate it immediately: if
VERSION is empty or longer than Docker's tag limit (128 characters) print a
clear error message that includes the sanitized value and exit non‑zero so the
workflow fails fast instead of producing opaque errors later during
push/manifest steps; implement this check right after the tr/... line and use
explicit checks for -z "$VERSION" and string length > 128, returning a helpful
error and exit 1.
- Around line 35-36: The current SHA assignment uses the ref for ${TAG} which
returns a tag object SHA for annotated tags; update the logic that sets SHA so
it resolves to the underlying commit for annotated tags: call gh api repos/${{
github.repository }}/git/ref/tags/${TAG} and inspect .object.type and
.object.sha (store as TAG_SHA); if .object.type == "tag" then call gh api
repos/${{ github.repository }}/git/tags/${TAG_SHA} and use its .object.sha as
the final SHA, otherwise use the original .object.sha; ensure the final value is
assigned to the SHA variable used by downstream steps (e.g.,
needs.resolve-tag.outputs.sha).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1bde99de-6e3d-4b28-90e8-531bc18e0366
📒 Files selected for processing (1)
.github/workflows/publish-docker-images.yml
| SHA=$(gh api repos/${{ github.repository }}/git/ref/tags/${TAG} --jq '.object.sha') | ||
| VERSION="${TAG#v}" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Checking whether origin has annotated tags (which use tag objects)..."
ANNOTATED_TAG=$(
git ls-remote --tags origin \
| awk '/\^\{\}$/ {tag=$2; sub("refs/tags/","",tag); sub(/\^\{\}$/,"",tag); print tag; exit}'
)
if [ -z "${ANNOTATED_TAG:-}" ]; then
echo "No annotated tags found right now; risk still exists for future annotated tags."
exit 0
fi
echo "Annotated tag detected: ${ANNOTATED_TAG}"
ENCODED_TAG=$(python - <<'PY'
import os, urllib.parse
print(urllib.parse.quote(os.environ["ANNOTATED_TAG"], safe=""))
PY
)
echo "GitHub /git/ref/tags/{tag} response object fields:"
curl -s "https://api.github.com/repos/OpenMS/FLASHApp/git/ref/tags/${ENCODED_TAG}" \
| python - <<'PY'
import json,sys
d=json.load(sys.stdin)
print("object.type =", d.get("object",{}).get("type"))
print("object.sha =", d.get("object",{}).get("sha"))
PYRepository: OpenMS/FLASHApp
Length of output: 208
🌐 Web query:
GitHub REST API git/ref/tags annotated tags object.type object.sha
💡 Result:
In the GitHub REST API, git/refs/tags refer to references under refs/tags/, accessed via endpoints like GET /repos/{owner}/{repo}/git/refs/tags/{tag} or matching refs. For annotated tags (the only type supported by the Git tags API), the ref's object has type "tag" and sha pointing to the annotated tag object SHA. To create an annotated tag: 1. POST /repos/{owner}/{repo}/git/tags to create the tag object, providing "object" (SHA of the target commit/tree/blob) and "type" ("commit", "tree", or "blob"). The response includes the new tag object's sha. 2. POST /repos/{owner}/{repo}/git/refs with "ref": "refs/tags/{tagname}" and "sha": {tag_object_sha}. Example creation request: { "tag": "v0.0.1", "message": "initial version", "object": "c3d0be41ecbe669545ee3e94d31ed9a4bc91ee3c", "type": "commit", ... } The tag object response includes its own "sha" (tag SHA), "object.sha" (target SHA), and "object.type". For a refs/tags/{tag} response: {"object": {"type": "tag", "sha": "{tag_sha}"}}. To get the tagged object's SHA/type, GET the tag object at /repos/{owner}/{repo}/git/tags/{tag_sha}, which has "object": {"type": "...", "sha": "..."}.
Citations:
- 1: https://docs.github.com/en/rest/git/tags
- 2: https://docs.github.com/rest/git/tags
- 3: https://docs.github.com/en/rest/git/refs
- 4: https://stackoverflow.com/questions/29199453/how-do-i-get-the-sha-associated-with-the-actual-code-for-a-tag
Resolve annotated tags to commit SHA before exporting sha.
On Line 35, .object.sha from git/ref/tags/{tag} returns a tag object SHA for annotated tags, not a commit SHA. While the repository currently has no annotated tags, using a tag object SHA in the checkout at Line 74/117 via ref: needs.resolve-tag.outputs.sha will fail if annotated tags are created. The code should handle both annotated and lightweight tags.
🔧 Proposed fix
if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
TAG="${{ github.event.inputs.tag }}"
if [ -n "$TAG" ]; then
- SHA=$(gh api repos/${{ github.repository }}/git/ref/tags/${TAG} --jq '.object.sha')
+ REF_TYPE=$(gh api repos/${{ github.repository }}/git/ref/tags/${TAG} --jq '.object.type')
+ REF_SHA=$(gh api repos/${{ github.repository }}/git/ref/tags/${TAG} --jq '.object.sha')
+ if [ "$REF_TYPE" = "tag" ]; then
+ SHA=$(gh api repos/${{ github.repository }}/git/tags/${REF_SHA} --jq '.object.sha')
+ else
+ SHA="$REF_SHA"
+ fi
VERSION="${TAG#v}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-docker-images.yml around lines 35 - 36, The
current SHA assignment uses the ref for ${TAG} which returns a tag object SHA
for annotated tags; update the logic that sets SHA so it resolves to the
underlying commit for annotated tags: call gh api repos/${{ github.repository
}}/git/ref/tags/${TAG} and inspect .object.type and .object.sha (store as
TAG_SHA); if .object.type == "tag" then call gh api repos/${{ github.repository
}}/git/tags/${TAG_SHA} and use its .object.sha as the final SHA, otherwise use
the original .object.sha; ensure the final value is assigned to the SHA variable
used by downstream steps (e.g., needs.resolve-tag.outputs.sha).
| # Sanitize VERSION for valid Docker tags: replace / with -, strip invalid chars | ||
| VERSION=$(echo "$VERSION" | tr '/' '-' | tr -cd 'A-Za-z0-9_.-') |
There was a problem hiding this comment.
Fail fast when sanitized VERSION is invalid.
After Line 50, VERSION can become empty (or exceed Docker’s tag limit) and fail later during push/manifest steps with opaque errors. Validate immediately.
🔧 Proposed fix
# Sanitize VERSION for valid Docker tags: replace / with -, strip invalid chars
VERSION=$(echo "$VERSION" | tr '/' '-' | tr -cd 'A-Za-z0-9_.-')
+ if [ -z "$VERSION" ]; then
+ echo "::error::Resolved VERSION is empty after sanitization"
+ exit 1
+ fi
+ if [ ${`#VERSION`} -gt 128 ]; then
+ echo "::error::Resolved VERSION exceeds 128 characters (${`#VERSION`})"
+ exit 1
+ fiAlso applies to: 52-54
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-docker-images.yml around lines 49 - 50, After
sanitizing VERSION (the line using VERSION=$(echo "$VERSION" | tr '/' '-' | tr
-cd 'A-Za-z0-9_.-')), validate it immediately: if VERSION is empty or longer
than Docker's tag limit (128 characters) print a clear error message that
includes the sanitized value and exit non‑zero so the workflow fails fast
instead of producing opaque errors later during push/manifest steps; implement
this check right after the tr/... line and use explicit checks for -z "$VERSION"
and string length > 128, returning a helpful error and exit 1.
Summary by CodeRabbit
Chores
Bug Fixes