feat(ci): run next-Go CI and e2e on PRs as non-blocking checks #28
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/next-go-on-prs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Change ci-next-go from a weekly scheduled run to trigger on every PR
(and push to master) as a warning-only signal, so next-Go regressions
surface on the PR that introduces them rather than silently rolling up
to Monday's canary. continue-on-error stays true, so a failure shows
as a grey/yellow status on the PR rather than blocking merge. Drop
1.26 from the matrix — it's already covered by ci.yml.
Add a parallel e2e-next-go workflow that mirrors e2e.yml but against
the next Go major, so we get the same warning-only signal for the
e2e smoke test.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
Automated review by pr-reviewer v0.17.0 | Safety Check | Claude Sonnet 4 | tracking id
r-e4c198-5dc854This is an AI-generated review and may contain mistakes.
Status: ✅ Completed
✅ Verdict: LGTM — This is a straightforward CI workflow change that adds non-blocking Go version testing - no security issues or obvious bugs detected.
Complexity: moderate
This PR modifies CI workflows to run next-Go testing on PRs instead of just weekly schedules. The changes look safe:
continue-on-error: trueto make failures non-blockingNo security vulnerabilities, secrets, or obvious bugs detected. The Go version 1.27 is reasonable for next-Go testing.
c1c86fd4fc514a5b5e23golang:1.27-bookworm doesn't exist on Docker Hub while Go 1.27 is unreleased. Switch ci-next-go to a current-stable base image and install the target toolchain via golang.org/dl/{gotip,goX.YrcZ}@latest, prepending its bin dir to PATH through $FORGEJO_PATH. Drop the e2e-next-go workflow added in the previous commit — the controller binary is compiled inside the Containerfile (which hardcodes golang:1.26-alpine), so an e2e-next-go job wouldn't actually exercise the controller built with next-Go without also parameterizing the Containerfile FROM. Defer that until we need the signal. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>Automated review by pr-reviewer v0.17.0 | Safety Check | Claude Sonnet 4 | tracking id
r-e53bff-e9adacThis is an AI-generated review and may contain mistakes.
Status: ✅ Completed
✅ Verdict: LGTM — This is a reasonable CI workflow change that shifts next-Go testing from weekly to per-PR with continue-on-error enabled.
Complexity: moderate
Safety Check Review
This PR modifies a CI workflow to run next-Go testing on PRs instead of weekly. The changes look safe:
continue-on-error: trueso failures don't block PRsfail-fast: falsefor better error reportingThe shell script logic for installing different Go versions appears correct and follows standard patterns. No security issues or obvious bugs detected.