Upgraded to new go version and added build action#36
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughSynchronizes Go version from 1.26.2 → 1.26 in go.mod and Dockerfile, and adds a 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
| 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
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/build.yaml (1)
9-12: ⚡ Quick winSet explicit least-privilege
GITHUB_TOKENpermissions.Define token permissions in the workflow (or job) so scope is deterministic and minimized.
Suggested change
name: ci on: push: +permissions: + contents: read + env: IMAGE_NAME: user/app🤖 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 9 - 12, The workflow currently relies on the default GITHUB_TOKEN scope; add an explicit least-privilege permissions block for the job named "container" so the token scope is deterministic and minimized (e.g., under jobs.container add a permissions mapping such as permissions: contents: read and only other scopes required by the steps), ensuring the permissions block is placed alongside runs-on and steps for that job.
🤖 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.
Nitpick comments:
In @.github/workflows/build.yaml:
- Around line 9-12: The workflow currently relies on the default GITHUB_TOKEN
scope; add an explicit least-privilege permissions block for the job named
"container" so the token scope is deterministic and minimized (e.g., under
jobs.container add a permissions mapping such as permissions: contents: read and
only other scopes required by the steps), ensuring the permissions block is
placed alongside runs-on and steps for that job.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9dc982fa-6389-49d6-9e17-2ad817a056c4
📒 Files selected for processing (1)
.github/workflows/build.yaml
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/build.yaml (1)
13-21:⚠️ Potential issue | 🟠 Major | ⚡ Quick winWorkflow is not performing a build, and it unnecessarily consumes registry secrets.
On Line 13–18, the job logs into a registry, but on Line 20–21 it only runs
podman --version. There is no container build/test/push step, so this CI job currently doesn’t validate the Go upgrade and exposes secrets without need.Suggested minimal fix
jobs: container: runs-on: self-hosted steps: - - name: Login to Docker Hub - uses: docker/login-action@v4 - with: - registry: ${{ vars.KEPPEL_REGISTRY }} - username: ${{ vars.KEPPEL_USERNAME }} - password: ${{ secrets.KEPPEL_SECRET }} - - - name: Check Podman version - run: podman --version + - name: Check Podman version + run: podman --version + - name: Build container image + run: podman build -t ${{ env.IMAGE_NAME }} .🤖 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 - 21, The workflow currently performs "Login to Docker Hub" (docker/login-action@v4) but never builds/tests/pushes any container—remove the login step (and the referenced vars.secrets usage) to avoid exposing registry credentials, or alternatively add the corresponding container build/test/push steps that actually use the registry; update or delete the "Login to Docker Hub" step (and any references to vars.KEPPEL_REGISTRY, vars.KEPPEL_USERNAME, secrets.KEPPEL_SECRET) so the job either performs a real Podman/Build action after "Check Podman version" or does not perform any registry login.
🤖 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.
Duplicate comments:
In @.github/workflows/build.yaml:
- Around line 13-21: The workflow currently performs "Login to Docker Hub"
(docker/login-action@v4) but never builds/tests/pushes any container—remove the
login step (and the referenced vars.secrets usage) to avoid exposing registry
credentials, or alternatively add the corresponding container build/test/push
steps that actually use the registry; update or delete the "Login to Docker Hub"
step (and any references to vars.KEPPEL_REGISTRY, vars.KEPPEL_USERNAME,
secrets.KEPPEL_SECRET) so the job either performs a real Podman/Build action
after "Check Podman version" or does not perform any registry login.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6abc2671-b563-4804-b15a-3167ca8697e2
📒 Files selected for processing (1)
.github/workflows/build.yaml
1 participant
Summary by CodeRabbit