CI "minimum" leg builds with go1.26.11, so the go 1.26.0 floor is untested

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#323 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
62/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github, github-actions, go
Bereich
ci-cd

Rechercherichtung

Beginne in .github/workflows/go.yml, wo der Leg build (minimum) actions/setup-go mit go-version-file: 'go.mod' verwendet, wodurch die toolchain-Zeile (go1.26.11) statt der Direktive go 1.26.0 in go.mod installiert wird. Entweder übergibst du die Version der go-Direktive als go-version an setup-go (ausgelesen mit einem sed-Schritt) oder formulierst den Kommentar und den Leg-Namen so um, dass klar ist, dass die Toolchain-Zeile getestet wird. Fertig ist es, wenn das Log des Legs die Version der Direktive zeigt oder der Kommentar zu dem passt, was getestet wird, und die Entscheidung zur 1.26.0-Untergrenze neben der lipgloss-Ignorierregel in .github/dependabot.yml vermerkt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

ci good first issue severity: low

Summary

The CI leg that claims to prove the go.mod floor installs the toolchain version instead, so nothing builds or tests with Go 1.26.0, the version that also holds back a dependency upgrade.

Where

  • .github/workflows/go.yml:11
  • .github/workflows/go.yml:28
  • go.mod:3
  • go.mod:5
  • .github/dependabot.yml:15

Details

go.yml:11-13 says "minimum" proves the go.mod floor (1.26.0) still builds and passes, and the leg uses actions/setup-go with go-version-file: 'go.mod' (go.yml:28-33). go.mod has go 1.26.0 (line 3) and toolchain go1.26.11 (line 5); setup-go takes the toolchain line. The log of job build (minimum) in run 43648865601 (head d0c56f0) reads Setup go version spec 1.26.11, Successfully set up Go version 1.26.11, go version go1.26.11 linux/amd64, with GOTOOLCHAIN: local. No other job installs 1.26.0 (the rest use stable, which was go1.27.4, or the same go.mod file).

Impact

No CI job has built or tested the code with Go 1.26.0 since the toolchain directive was added (#243). The floor is what keeps lipgloss on v2.0.x (dependabot.yml:15-19 ignores >= 2.1.0 because it needs go 1.26.7; docs/DEVELOPER_GUIDE.md:340-341 repeats the rule), so an available upgrade is held back for a minimum that nothing verifies. A user who builds with GOTOOLCHAIN=local on 1.26.0 to 1.26.10 is on an untested path. The "Check go directive" step only compares the text of the line.

Steps to reproduce

gh api repos/TMHSDigital/subenum/actions/jobs/132612623946/logs, then search for Setup go version spec.

Suggested fix

Make the leg install the go line's version: read it in a step (sed -n 's/^go //p' go.mod) and pass it to setup-go as go-version (setup-go already sets GOTOOLCHAIN=local, so 1.26.0 is then what compiles). Or, if 1.26.0 is not really meant to be supported, say in the comment that the leg tests the toolchain line, raise the go directive on purpose, and drop the lipgloss ignore.

Notes

Related: #243 (added the toolchain directive).

Acceptance criteria

  • The leg's log shows the version of the go directive, or the comment and leg name say it tests the toolchain line
  • The decision about the 1.26.0 floor is written down next to the Dependabot ignore rule

Getting started

  • Relevant files: .github/workflows/go.yml, go.mod, .github/dependabot.yml
  • How to run tests: make test (or go test ./...). Tests must stay hermetic: use -simulate, -simulate-zone or the local DNS test server, never a live domain.
  • Related docs: docs/DEVELOPER_GUIDE.md, docs/ARCHITECTURE.md

Filed by repo-audit/full-audit at d0c56f0. Severity: low. Effort: S. audit-key: ci|.github/workflows/go.yml|build.minimum.go-version-file

Vorherrschende Sprache
Go
Sterne
1
Forks
1
Ø Merge
6 Std. 42 Min.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TMHSDigital/subenum

Alle Issues in TMHSDigital/subenum

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.