feat: upgrade go version to 1.24.7

[mrtechit]

Issue : #126

Upgrade go to 1.24.7

[coderabbitai]

Walkthrough

Go toolchain bumped from 1.23.1 to 1.24.7 in go.mod and the Docker builder image; GitHub Actions release workflow now resolves the Go version via go-version-file: 'go.mod' instead of a hard-coded version. No functional logic or public API changes detected.

Changes

Cohort / File(s)	Summary of changes
CI workflow .github/workflows/release.yml	Replaced hard-coded Go version with go-version-file: 'go.mod', delegating Go version resolution to go.mod.
Docker build Dockerfile	Builder stage base image updated from golang:1.23.1-alpine to golang:1.24.7-alpine; remaining stages unchanged.
Go toolchain go.mod	Go toolchain version updated from 1.23.1 to 1.24.7.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

I hop through versions, light and keen,
From 1.23 to 1.24’s sheen.
Docker builds and workflows sing,
go.mod now sets the versioning.
Carrots, commits, and tiny springs—🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	The PR description references the related issue and explicitly states "Upgrade go to 1.24.7", which directly matches the modifications in go.mod, Dockerfile, and the release workflow, so it is on-topic and sufficient for this lenient check.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Title Check	✅ Passed	The title succinctly describes the primary change — upgrading the project's Go toolchain to 1.24.7. The diff shows updates to go.mod, the Dockerfile builder image, and the release workflow to use Go 1.24.7, so the title accurately reflects the main change. It is concise, follows conventional commit style with a "feat:" prefix, and gives teammates a clear summary when scanning history.

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

Dockerfile (1)

1-2: Fix stale comment to match the new base image.

Comment still references 1.23.1 while FROM uses 1.24.7.

Apply this diff:

-# Use golang:1.23.1-alpine as the base image.
+# Use golang:1.24.7-alpine as the base image.

.github/workflows/release.yml (1)

27-27: Prefer deriving Go version from go.mod in the release workflow

Replace the hardcoded version in .github/workflows/release.yml (line 27):

-          go-version: 1.24.7
+          go-version-file: go.mod

go.mod already specifies "go 1.24.7" and other workflows use go-version-file; actions/setup-go will resolve the point release. If you need to pin a patch, use a toolchain directive in go.mod. Verify any Dockerfile references — I couldn't find an official golang:1.24.7-alpine tag.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 14958a2 and ea69eec.

📒 Files selected for processing (3)

• .github/workflows/release.yml (1 hunks)
• Dockerfile (1 hunks)
• go.mod (1 hunks)

🔇 Additional comments (1)

go.mod (1)

3-3: Incorrect — go directive may include patch versions; no change required

The go directive accepts major.minor or major.minor.patch (e.g., go 1.24.7); toolchain is only needed if you want to explicitly pin a toolchain. go.mod line 3 (go 1.24.7) is valid.

Likely an incorrect or invalid review comment.

[mertssmnoglu]

Thanks, @mrtechit! Could you please use the go-version-file option in the release workflow? If you edit it, I'll approve the pull request and run CI to see the results.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

20-21: Consider pinning GitHub Actions by commit SHA for supply‑chain safety.

Pin checkout/setup-go/goreleaser actions to SHAs instead of tags to avoid unexpected changes.

Also applies to: 25-26, 34-35

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1871800 and 41c3d3e.

📒 Files selected for processing (1)

• .github/workflows/release.yml (1 hunks)

🔇 Additional comments (1)

.github/workflows/release.yml (1)

27-27: Good switch to go-version-file; aligns with go.mod.

This addresses the earlier feedback and keeps the workflow in sync with the toolchain declared in go.mod.

Run this to ensure no other workflows still hardcode a Go version:

#!/bin/bash
# List all setup-go usages and highlight hardcoded go-version entries
rg -nC2 -g '.github/workflows/*.yml' -P 'uses:\s*actions/setup-go@|go-version-file:|go-version:\s*["'\'']?\d' 

[mertssmnoglu]

It's interesting, contract testing job fails but Capture built successfully. I can ignore the contract test since there is no API/Schema changes.

[mertssmnoglu]

Thank you @mrtechit