Upgraded to new go version and added build action#36
Upgraded to new go version and added build action#36costa-labs wants to merge 3 commits intomainfrom
Conversation
|
Caution Review failedAn error occurred during the review process. Please try again later. 📝 WalkthroughWalkthroughThe PR synchronizes Go versions from 1.26.2 to 1.26 in go.mod and Dockerfile, and introduces a new GitHub Actions workflow that authenticates to Docker Hub, sets up Buildx, extracts image metadata, and builds a Docker image on every push without pushing to the registry. ChangesBuild Infrastructure Update
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
.github/workflows/build.yaml (1)
3-5: ⚡ Quick winCI should also run on PRs, not only pushes.
With only
push, failures are discovered after merge instead of at review time.Suggested change
on: push: + pull_request:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build.yaml around lines 3 - 5, The workflow currently triggers only on the "push" event; update the workflow's top-level "on:" block to include "pull_request" alongside "push" so CI runs for PRs as well as pushes (i.e., add a "pull_request:" entry next to the existing "push:" entry in the workflow definition).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build.yaml:
- Line 14: Replace mutable action tags with their immutable commit SHAs: find
occurrences like "docker/login-action@v4" (and the other action tags referenced
in the diff at lines 20, 24, 29) and pin each to the full 40-character commit
SHA (e.g., docker/login-action@<40-char-sha>) instead of the short tag; keep the
rest of the workflow syntax unchanged and optionally add a trailing comment with
the original tag (e.g., # v4) for readability. Ensure every action reference in
the workflow is updated to use a full commit SHA.
- Line 34: The current labels entry using a static custom key
"source_repository='c5413905/remotearbiter'" is nonstandard and brittle; update
the labels configuration (the labels: entry) to use standard OCI annotation keys
such as org.opencontainers.image.source and org.opencontainers.image.revision
and source the values from CI context (e.g., the GitHub repository or
metadata-action outputs like github.repository / github.sha) instead of
hardcoding the repo ID so the build-push-action emits proper OCI metadata.
- Around line 13-17: Remove the unnecessary Docker Hub login step: delete the
workflow step named "Login to Docker Hub" that uses docker/login-action@v4 and
references vars.DOCKERHUB_USERNAME and secrets.DOCKERHUB_TOKEN, since the job
runs with push: false and uses only public base images; ensure no other steps
reference those secrets so they can be safely removed from the workflow.
In `@Dockerfile`:
- Line 5: The Dockerfile's builder stage uses the floating image tag
"golang:1.26" which breaks reproducible builds; update the FROM line in the
Dockerfile to pin a specific patch version (e.g., "golang:1.26.2") or pin to an
immutable digest (e.g., "golang:1.26.2@sha256:<digest>") for the builder stage
so the image referenced by the builder (FROM golang:1.26 ...) remains
deterministic; choose patch-pin for automatic patch rollups or digest-pin for
maximum immutability and update the FROM instruction accordingly.
---
Nitpick comments:
In @.github/workflows/build.yaml:
- Around line 3-5: The workflow currently triggers only on the "push" event;
update the workflow's top-level "on:" block to include "pull_request" alongside
"push" so CI runs for PRs as well as pushes (i.e., add a "pull_request:" entry
next to the existing "push:" entry in the workflow definition).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1edd9405-d604-4b93-8dec-8a2c62756fe9
📒 Files selected for processing (3)
.github/workflows/build.yamlDockerfilego.mod
| - name: Login to Docker Hub | ||
| uses: docker/login-action@v4 | ||
| with: | ||
| username: ${{ vars.DOCKERHUB_USERNAME }} | ||
| password: ${{ secrets.DOCKERHUB_TOKEN }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For docker/build-push-action, is Docker registry login required when push: false and the build only runs locally in GitHub Actions?
💡 Result:
No—if you set docker/build-push-action with push: false and you’re only doing a local build (no registry export/push), you do not need to log in to any Docker registry for the purpose of pushing. Reasoning (what push: false actually does): the action’s push option is documented as a shorthand for the Docker Buildx registry exporter; it only pushes when push is true, since the registry exporter is the mechanism that pushes the build result to a registry [1][2]. A Docker Buildx build without --push (i.e., no registry exporter output) just builds locally (e.g., via the image exporter / docker images store), so registry credentials are not required for that local-only output [3][2]. Caveat (when registry auth can still be required even with push: false): build steps may still need authentication to pull private base images or other referenced images during the build. This can require a registry login even when you aren’t pushing your result, because authentication is for pulling required inputs, not only for pushing outputs [4]. Practical takeaway: for “build only, don’t push anywhere” workflows, you can omit docker/login-action unless your Dockerfile (or build contexts) pull from private registries during the build. If you want to push later, then log in for the push step.
Citations:
- 1: https://github.com/docker/build-push-action/
- 2: https://docs.docker.com/build/exporters/image-registry
- 3: https://docs.docker.com/reference/cli/docker/buildx/build
- 4: Login validation must be ignored if push is false docker/build-push-action#85
🏁 Script executed:
# First, let's see the full build.yaml workflow file
cat -n .github/workflows/build.yaml | head -100Repository: cobaltcore-dev/external-arbiter-operator
Length of output: 1116
🏁 Script executed:
# Also check if there's a Dockerfile to understand if private images are pulled
find . -name "Dockerfile*" -type f | head -20Repository: cobaltcore-dev/external-arbiter-operator
Length of output: 97
🏁 Script executed:
# Look for docker/build-push-action usage in the workflow
rg "docker/build-push-action|push:" .github/workflows/build.yaml -A 5 -B 2Repository: cobaltcore-dev/external-arbiter-operator
Length of output: 415
🏁 Script executed:
cat -n ./DockerfileRepository: cobaltcore-dev/external-arbiter-operator
Length of output: 1872
Remove Docker Hub login step—push: false means no registry push occurs.
The workflow builds only locally without pushing images anywhere. Since the Dockerfile uses only public base images (golang:1.26 and gcr.io/distroless/static:nonroot), no registry authentication is required. Keeping the login step unnecessarily exposes DOCKERHUB_TOKEN and DOCKERHUB_USERNAME secrets.
Suggested change
- - name: Login to Docker Hub
- uses: docker/login-action@v4
- with:
- username: ${{ vars.DOCKERHUB_USERNAME }}
- password: ${{ secrets.DOCKERHUB_TOKEN }}
-
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v4📝 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.
| - name: Login to Docker Hub | |
| uses: docker/login-action@v4 | |
| with: | |
| username: ${{ vars.DOCKERHUB_USERNAME }} | |
| password: ${{ secrets.DOCKERHUB_TOKEN }} | |
| - name: Set up Docker Buildx | |
| uses: docker/setup-buildx-action@v4 |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build.yaml around lines 13 - 17, Remove the unnecessary
Docker Hub login step: delete the workflow step named "Login to Docker Hub" that
uses docker/login-action@v4 and references vars.DOCKERHUB_USERNAME and
secrets.DOCKERHUB_TOKEN, since the job runs with push: false and uses only
public base images; ensure no other steps reference those secrets so they can be
safely removed from the workflow.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Login to Docker Hub | ||
| uses: docker/login-action@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is GitHub’s recommended practice for pinning GitHub Actions (tag vs full commit SHA) to mitigate supply-chain risk?
💡 Result:
GitHub’s recommended practice is to pin GitHub Actions to the full (40-character) commit SHA, not to mutable tags (like @v4, @main, or @latest), to mitigate supply-chain risk [1][2]. Why (tag vs SHA): - GitHub recommends pinning to a specific commit SHA because it prevents malicious code added to a new or updated branch or tag from being automatically used [1]. - When GitHub’s “Require actions to be pinned to a full-length commit SHA” policy is enabled, workflows that attempt to use actions that aren’t pinned to a full commit SHA will fail [2][3]. Practical implication: - Prefer full commit SHA pins in each uses: line (optionally with a comment mapping the SHA to the human version tag you tested), e.g. uses: OWNER/REPO@ rather than uses: OWNER/REPO@v4 [1][2].
Citations:
- 1: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 2: https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise
- 3: https://docs.github.com/en/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository
🏁 Script executed:
cat -n .github/workflows/build.yaml | head -35Repository: cobaltcore-dev/external-arbiter-operator
Length of output: 1116
Pin all GitHub Actions to full commit SHAs instead of mutable version tags.
Mutable major version tags (@v4, @v6, @v7) create supply-chain security risks by allowing malicious code injected into a new or updated tag to run automatically in workflows. Pin each action to its full 40-character commit SHA, optionally with a comment documenting the corresponding tag version for readability (e.g., docker/login-action@abc123...).
Affects: lines 14, 20, 24, 29
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build.yaml at line 14, Replace mutable action tags with
their immutable commit SHAs: find occurrences like "docker/login-action@v4" (and
the other action tags referenced in the diff at lines 20, 24, 29) and pin each
to the full 40-character commit SHA (e.g., docker/login-action@<40-char-sha>)
instead of the short tag; keep the rest of the workflow syntax unchanged and
optionally add a trailing comment with the original tag (e.g., # v4) for
readability. Ensure every action reference in the workflow is updated to use a
full commit SHA.
| tags: ${{ steps.meta.outputs.tags }} | ||
| annotations: ${{ steps.meta.outputs.annotations }} | ||
| push: false | ||
| labels: "source_repository='c5413905/remotearbiter'" No newline at end of file |
There was a problem hiding this comment.
Use standard OCI labels (or metadata-action outputs) instead of static custom label text.
labels: "source_repository='c5413905/remotearbiter'" is brittle and non-standard; prefer OCI keys like org.opencontainers.image.source.
What label format does docker/build-push-action expect, and what are the standard OCI image annotation/label keys for source repository metadata?
Suggested change
- labels: "source_repository='c5413905/remotearbiter'"
+ labels: |
+ org.opencontainers.image.source=https://github.com/cobaltcore-dev/external-arbiter-operator
+ org.opencontainers.image.revision=${{ github.sha }}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build.yaml at line 34, The current labels entry using a
static custom key "source_repository='c5413905/remotearbiter'" is nonstandard
and brittle; update the labels configuration (the labels: entry) to use standard
OCI annotation keys such as org.opencontainers.image.source and
org.opencontainers.image.revision and source the values from CI context (e.g.,
the GitHub repository or metadata-action outputs like github.repository /
github.sha) instead of hardcoding the repo ID so the build-push-action emits
proper OCI metadata.
|
|
||
| # Build the manager binary | ||
| FROM golang:1.26.2 AS builder | ||
| FROM golang:1.26 AS builder |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the Docker Official Image tag semantics for golang(e.g.,1.26vs1.26.x), and what do Docker/GitHub recommend for reproducible CI builds regarding digest pinning?
💡 Result:
Docker Official Image tag semantics for golang 1) What tags exist and how they relate - The golang Official Image publishes “version tags” and “shared tags” that are aliases of the same underlying build. The Docker Hub tag listing explicitly groups 1.26.2, 1.26, 1, and latest together as shared tags [1][2]. - Therefore, golang:1.26 is a moving alias for the current patch release in the 1.26 series (and golang:latest is also an alias) rather than a patch-pinned immutable reference [1][2]. - Conversely, golang:1.26.2 (three-part version) is patch-pinned; it is not described as being aliased with a different patch release the way the two-part alias (1.26) is [1][2]. Practical implication for CI: - FROM golang:1.26 can change over time as the 1.26.x patch line advances, while FROM golang:1.26.2 stays on that exact patch release, which is closer to reproducibility [1][2]. - There are also suite/OS-variant tags (e.g., bookworm, trixie, alpine3.23) that indicate the Debian/Alpine base variant; they are independent of the Go version tag choice [1][3]. 2) Example seen in Docker Hub - Docker Hub shows 1.26.2-trixie, 1.26-trixie, 1-trixie, and trixie as tags in the golang repository [1][2]. This indicates multiple tag names can point at the same build for different “levels” of specificity (patch vs series vs “latest-like” aliases) [1][2]. Digest pinning recommendations for reproducible CI builds 1) Prefer digest pinning when you need immutable/reproducible container inputs - Docker’s documentation describes that digests are immutable and “pin” an image to a specific version: pulling by digest guarantees you get “exactly the same image” each time, whereas tags are not immutable and may resolve to different content over time [4][5]. - Docker also explicitly warns: when you pin by digest, you stop automatically receiving updates (including security updates); you must change the digest yourself to pick up new security fixes [4]. 2) What Docker/GitHub community recommendations look like - Docker/OCI ecosystem guidance and CI-security discussions commonly recommend digest pinning specifically to prevent “floating” tag behavior from breaking reproducibility/security expectations. For example, a Docker-related pinning guidance proposal for pinned dependencies suggests using node@sha256:...-style references for container images in CI [6]. How to apply this to your CI - For maximum reproducibility of the Go build environment image, use a patch (or full) version tag if you cannot use digests, e.g. golang:1.26.2 rather than golang:1.26 [1][2]. - For maximum immutability, pin the base image by digest, e.g. FROM golang:1.26.2@sha256:<digest> (digest format shown in Docker docs) [4][5]. - Keep an update process (manual or automated) to periodically refresh the digest to get security fixes, since digest pinning disables “automatic” tag movement [4].
Citations:
- 1: https://hub.docker.com/_/golang?tab=tags
- 2: https://hub.docker.com/_/golang/tags?name=bullseye&page=1
- 3: https://hub.docker.com/_/golang/
- 4: https://docs.docker.com/reference/cli/docker/image/pull/
- 5: https://docs.docker.com/dhi/core-concepts/digests
- 6: Add guidance on pinning GitHub Actions and container images open-telemetry/sig-security#69
Pin builder image to a deterministic version or digest.
golang:1.26 is a floating tag alias that resolves to different patch releases as the 1.26.x line advances, breaking build reproducibility. Use a patch-pinned tag (golang:1.26.2) for consistency, or pin by digest (golang:1.26.2@sha256:<digest>) for maximum immutability. Note that digest pinning requires manual updates to receive security patches.
Suggested change
-FROM golang:1.26 AS builder
+FROM golang:1.26.2 AS builder
+# or stronger:
+# FROM golang:1.26.2@sha256:<resolved-digest> AS builder🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` at line 5, The Dockerfile's builder stage uses the floating image
tag "golang:1.26" which breaks reproducible builds; update the FROM line in the
Dockerfile to pin a specific patch version (e.g., "golang:1.26.2") or pin to an
immutable digest (e.g., "golang:1.26.2@sha256:<digest>") for the builder stage
so the image referenced by the builder (FROM golang:1.26 ...) remains
deterministic; choose patch-pin for automatic patch rollups or digest-pin for
maximum immutability and update the FROM instruction accordingly.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build.yaml:
- Around line 11-12: The workflow contains duplicate YAML keys named "runs-on"
which makes the file invalid; remove one of the "runs-on" entries so only a
single runner is specified (choose and keep the intended value, e.g.,
"ubuntu-latest" per the proposed fix) and ensure the remaining "runs-on" key is
the only occurrence in the workflow.
- Around line 6-7: The workflow's IMAGE_NAME env value is a placeholder
("user/app") and should be replaced with this repo's real container image
reference; update the IMAGE_NAME environment variable in the YAML to the correct
registry/repository:tag (or set it to a repo-level variable/secrets value) so
pushes/builds target the correct image. Locate the IMAGE_NAME entry in the env
block and replace "user/app" with your actual image name (or wire it to a
secret/variable) to ensure correct registry path when push is enabled.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 471dddc8-44f8-423c-a287-6b32205eb037
📒 Files selected for processing (1)
.github/workflows/build.yaml
| env: | ||
| IMAGE_NAME: user/app |
There was a problem hiding this comment.
IMAGE_NAME is a placeholder — update to the actual image reference.
user/app is the example value from Docker's own template and does not refer to this project's image. If push is ever enabled, builds will target the wrong registry path.
✏️ Proposed fix
- IMAGE_NAME: user/app
+ IMAGE_NAME: ${{ vars.KEPPEL_REGISTRY }}/cobaltcore-dev/external-arbiter-operator📝 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.
| env: | |
| IMAGE_NAME: user/app | |
| env: | |
| IMAGE_NAME: ${{ vars.KEPPEL_REGISTRY }}/cobaltcore-dev/external-arbiter-operator |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build.yaml around lines 6 - 7, The workflow's IMAGE_NAME
env value is a placeholder ("user/app") and should be replaced with this repo's
real container image reference; update the IMAGE_NAME environment variable in
the YAML to the correct registry/repository:tag (or set it to a repo-level
variable/secrets value) so pushes/builds target the correct image. Locate the
IMAGE_NAME entry in the env block and replace "user/app" with your actual image
name (or wire it to a secret/variable) to ensure correct registry path when push
is enabled.
| runs-on: self-hosted | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Remove the duplicate runs-on key — the workflow YAML is invalid.
Both actionlint and YAMLlint flag this as a hard error. Duplicate keys in YAML are undefined; most parsers silently use the last value (ubuntu-latest), dropping self-hosted without warning. Decide which runner is intended and keep only that key.
🐛 Proposed fix (choosing `ubuntu-latest`)
- runs-on: self-hosted
- runs-on: ubuntu-latest
+ runs-on: ubuntu-latest📝 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.
| runs-on: self-hosted | |
| runs-on: ubuntu-latest | |
| runs-on: ubuntu-latest |
🧰 Tools
🪛 actionlint (1.7.12)
[error] 12-12: key "runs-on" is duplicated in "docker" job. previously defined at line:11,col:5
(syntax-check)
🪛 YAMLlint (1.38.0)
[error] 12-12: duplication of key "runs-on" in mapping
(key-duplicates)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build.yaml around lines 11 - 12, The workflow contains
duplicate YAML keys named "runs-on" which makes the file invalid; remove one of
the "runs-on" entries so only a single runner is specified (choose and keep the
intended value, e.g., "ubuntu-latest" per the proposed fix) and ensure the
remaining "runs-on" key is the only occurrence in the workflow.
1 participant
Summary by CodeRabbit