Fix misc build issues#57
Conversation
|
Warning Review limit reached
More reviews will be available in 51 minutes and 54 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughGo module directive updated from ChangesGo toolchain upgrade and build config
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
`go.mod` files use full go versions (1.2x.0) these days, and in this case, `go-version-file` will instruct the `setup-go` action to use exactly this version, why the desired behaviour would be to use the latest patch release (ie newest 1.2x.y). This commit uses the oldest stable release of go instead (latest 1.25.x at the time of this commit). Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
go 1.25 is the oldest supported go release. `tools/go.mod` already requires go 1.25 Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
With the `golangci-lint` changes, the default target is now `golangci-lint` build through the inclusion of `tools.mk`, which was not intentional. Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
At the moment, this job is not doing anything… Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
`make test` and `make lint` may be testing `routes-controller` build, but I prefer to have an explicit job testing the build. Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
|
Phew, finally all green ! |
| module github.com/crc-org/routes-controller | ||
|
|
||
| go 1.23.0 | ||
| go 1.25 |
There was a problem hiding this comment.
shouldn't with this change we also update the gh action file to use 1.25 instead of oldstable ?
| - uses: actions/checkout@v4 | ||
| - uses: actions/setup-go@v6 | ||
| with: | ||
| go-version: oldstable |
There was a problem hiding this comment.
here also we are using oldstable does it the stable of 1.25.x ?
There was a problem hiding this comment.
my assumption is that oldstable == 1.25.x, and stable == 1.26.x
https://github.com/crc-org/routes-controller/actions/runs/28015680805/job/82919263700 has this in the logs:
Run actions/setup-go@v6
Setup go version spec oldstable
oldstable version resolved as 1.25.11
So the assumption seems correct.
But even if in the future we stick to 1.25 in go.mod, I think it’s fine to build with oldstable rather than hardcoding 1.25 to ensure routes-controller is buildable with a supported golang version
| - uses: actions/checkout@v4 | ||
| - uses: actions/setup-go@v6 | ||
| with: | ||
| go-version: oldstable |
Following the golangci-lint changes, more adjustment are needed, mostly related to the go version used for building. This should fix CI builds.
go-version-file: go.modmakedefault target should bebuildSummary by CodeRabbit