Dockerfile.release (1)

3-3: Pin grpc-health-probe image and confirm binary path

We’ve verified that the v0.4.40 release provides platform binaries named grpc_health_probe-linux-<arch> and that the OCI package places the probe at /ko-app/grpc-health-probe . To ensure reproducible, immutable builds, update your Dockerfile.release to pin the image by digest:

-COPY --from=ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.40 /ko-app/grpc-health-probe /usr/local/bin/grpc_health_probe
+COPY --from=ghcr.io/grpc-ecosystem/grpc-health-probe@sha256:38d74888e537b1a4d581ffa9281dec6c24e55429f3a20d943c9a118e7f3fab7f \
+     /ko-app/grpc-health-probe /usr/local/bin/grpc_health_probe

Multi-arch (manifest/index) digest:
sha256:38d74888e537b1a4d581ffa9281dec6c24e55429f3a20d943c9a118e7f3fab7f

Optionally, you can target a single platform by using its specific digest (e.g., linux/amd64:
sha256:89681cb8547431a60d02a4180791d9d8ea41decf155a540c6703564927abc87b).

docs/api-reference/apidocs.swagger.json (1)

3559-3559: Optional: add a top-level security requirement to satisfy CKV_OPENAPI_4/5.

Static analysis flags the lack of a global security rule; you have securityDefinitions but no top-level “security” stanza. If desired, add something like:

   "securityDefinitions": {
     "ApiKeyAuth": {
       "type": "apiKey",
       "name": "Authorization",
       "in": "header"
     }
   }
+ , "security": [
+   { "ApiKeyAuth": [] }
+ ]

Note: This is outside the stated scope; feel free to defer.

docs/api-reference/openapiv2/apidocs.swagger.json (1)

3531-3537: Consider defining global security to match the existing ApiKeyAuth definition.

You define securityDefinitions.ApiKeyAuth but don’t reference it globally or per-operation. Adding a top-level security requirement improves accuracy and satisfies common linters (e.g., CKV_OPENAPI_4/5). Endpoints that are intentionally public can override with "security": [] at the operation level.

Apply this diff to add a global security block:

   "securityDefinitions": {
     "ApiKeyAuth": {
       "type": "apiKey",
       "name": "Authorization",
       "in": "header"
     }
-  }
+  },
+  "security": [
+    { "ApiKeyAuth": [] }
+  ]
 }

Note: The trailing newline at EOF is a nice touch; keep it.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

internal/info.go (1)

26-26: Version bump verified and consistent.

All occurrences of “v1.4.3” have been updated and match the intended bump:

• internal/info.go (Version constant)
• proto/base/v1/openapi.proto (OpenAPI version field)
• docs/api-reference/apidocs.swagger.json
• docs/api-reference/openapiv2/apidocs.swagger.json
• go.mod (github.com/go-logr/logr v1.4.3 // indirect)
• go.sum & sdk/go/grpc/go.sum (lockfile entries for logr v1.4.3)

No stray references remain.

proto/base/v1/openapi.proto (1)

12-12: OpenAPI proto version updated correctly.

No issues spotted with the bump to v1.4.3.

docs/api-reference/apidocs.swagger.json (1)

6-6: Info.version bumped to v1.4.3 — LGTM.

docs/api-reference/openapiv2/apidocs.swagger.json (1)

6-6: All version references updated to v1.4.3

Verified that every OpenAPI spec and internal version constant has been bumped to v1.4.3:

• docs/api-reference/openapiv2/apidocs.swagger.json (version: “v1.4.3”)
• docs/api-reference/apidocs.swagger.json (version: “v1.4.3”)
• proto/base/v1/openapi.proto (version: “v1.4.3”)
• internal/info.go (Version = “v1.4.3”)

No mismatches detected. If this spec is the canonical source for generating downstream docs/SDKs, be sure to regenerate those artifacts for v1.4.3 before release.

Dockerfile (1)

8-8: Critical: grpc-health-probe v0.4.40 tag not published on GHCR (as of Aug 21, 2025) — build will fail.

The COPY stage references ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.40, but the GHCR package page shows the latest published tag is v0.4.36; v0.4.40 is not listed. This will cause the multi-stage COPY to fail at build time. Pinning by digest is recommended once you choose an available tag. (github.com)

Proposed stop-gap (use the latest available tag and pin by digest):

- COPY --from=ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.40 /ko-app/grpc-health-probe /usr/local/bin/grpc_health_probe
+ # Use currently published tag and pin to its digest (update when newer tag is available).
+ COPY --from=ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.36@sha256:55a379bb4a7ef1c779e4e123ff31dd0046d1014eab083a89f4ac196a97548bec \
+   /ko-app/grpc-health-probe /usr/local/bin/grpc_health_probe

Follow-ups:

• When upstream publishes a newer tag you want (e.g., v0.4.40), switch to tag@sha256:.
• Optionally drop the dependency entirely and use native Kubernetes gRPC probes if you don’t rely on grpc_health_probe-specific features. (kubernetes.io)

Run this to verify the tag availability and binary path before merging:

#!/bin/bash
set -euo pipefail

# 1) Confirm which tags exist on GHCR
# (The web UI shows v0.4.36 as latest; this confirms via skopeo if available.)
skopeo inspect docker://ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.36 | jq '.Digest,.Name' || true
skopeo inspect docker://ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.40 | jq '.Digest,.Name' || true

# 2) Inspect image config to see entrypoint/cmd; ko-built images usually place the binary under /ko-app/
skopeo inspect --raw docker://ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.36 | jq -r '.config.Config.Entrypoint,.config.Config.Cmd'

# 3) Optionally verify the file exists in the layer (pull + containerd-less check)
#   Note: If docker is available:
# docker pull ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.36
# docker run --rm ghcr.io/grpc-ecosystem/grpc-health-probe:v0.4.36 ls -l /ko-app/ || true

Dockerfile.local (1)

2-2: Base image bump and digest pinning LGTM; consider pinning the Air install for supply-chain safety.

• Nice: golang:1.24.6-alpine is pinned by digest — good practice.
• Suggestion: the curl | sh install of Air pulls the installer from the moving "master" HEAD. Pin to a specific Air version and verify checksum to reduce supply-chain risk.

Example refactor:

-RUN curl -sSfL https://raw.githubusercontent.com/cosmtrek/air/master/install.sh | sh -s -- -b $(go env GOPATH)/bin
+ARG AIR_VERSION=v1.52.0
+# Pin install script by commit and verify checksum (example shows pattern; update COMMIT/SHASUM to real values).
+ADD https://raw.githubusercontent.com/cosmtrek/air/<COMMIT>/install.sh /tmp/air-install.sh
+RUN echo "<SHASUM>  /tmp/air-install.sh" | sha256sum -c - && \
+    sh /tmp/air-install.sh -b $(go env GOPATH)/bin -d -v ${AIR_VERSION}

If you want, I can look up the latest stable Air version and its checksum and provide the exact values.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

tools/go.mod (1)

3-3: Toolchain bump to 1.24.6 looks consistent.

Matches the broader PR intent to unify Go version across modules and CI. No action needed.

.github/workflows/release.yml (1)

26-26: CI Go version aligned to ~1.24.6.

Good consistency with go.mod and Docker bases. Pinning the action by commit is already in place.

Dockerfile (1)

1-1: Builder base bump + digest pinning LGTM.

The update to golang:1.24.6-alpine with a pinned digest is consistent with the rest of the PR and good for reproducibility.

Dockerfile.release (2)

5-6: If you keep git, use shallow, pinned clone; drop redundant apk update

If you decide to stick with git, reduce attack surface and layer size.

-RUN apk update && apk add --no-cache git
-RUN git clone https://github.com/grpc-ecosystem/grpc-health-probe.git
+RUN apk add --no-cache git
+ARG GRPC_HEALTH_PROBE_REF=v0.4.40
+RUN git clone --depth 1 --branch ${GRPC_HEALTH_PROBE_REF} https://github.com/grpc-ecosystem/grpc-health-probe.git

---

10-11: Ensure the binary lands at /go/bin deterministically

go install relies on GOPATH/GOBIN defaults; to make the COPY robust, you can build with an explicit output path.

-ENV GOTOOLCHAIN=local
-RUN CGO_ENABLED=0 go install -a -tags netgo -ldflags=-w
+ENV GOTOOLCHAIN=local
+RUN --mount=type=cache,target=/root/.cache/go-build \
+    --mount=type=cache,target=/go/pkg/mod \
+    CGO_ENABLED=0 go build -trimpath -tags netgo -ldflags "-s -w -buildid=" \
+      -o /go/bin/grpc-health-probe .

Dockerfile (1)

16-21: Optional: pin the final static base by digest here as well (consistency with permify-builder)

You already pin the builder image; consider pinning the final cgr.dev/chainguard/static:latest to a digest in this Dockerfile too (it’s already pinned in Dockerfile.release), or make it an ARG that CI injects with a digest. This avoids drift if latest changes between builds.

Example:

-FROM cgr.dev/chainguard/static:latest@sha256:6a4b683f4708f1f167ba218e31fcac0b7515d94c33c3acf223c36d5c6acd3783
+ARG STATIC_BASE=cgr.dev/chainguard/static:latest@sha256:6a4b683f4708f1f167ba218e31fcac0b7515d94c33c3acf223c36d5c6acd3783
+FROM ${STATIC_BASE}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Dockerfile.release (1)

13-13: LGTM: Copy path matches builder output

Assuming the install/build writes to /go/bin/grpc-health-probe, the COPY destination and binary name are consistent with common conventions. Nice.

Dockerfile (3)

1-1: LGTM: Builder image is pinned by digest

Pinning the Go builder image improves reproducibility. Good call.

---

17-17: LGTM: Final copy path and binary name are consistent

This matches the builder output path and retains the expected destination name.

---

18-21: Note: This change addresses the prior GHCR tag/path concern

Switching from copying out of a prebuilt GHCR image to building the probe from source resolves the earlier concern about the non-existent tag and uncertain binary path. Nice move.