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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#323 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
62/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
github, github-actions, go
Domaine
ci-cd

Piste de recherche

Commence par .github/workflows/go.yml, où le leg build (minimum) utilise actions/setup-go avec go-version-file: 'go.mod', ce qui installe la ligne toolchain (go1.26.11) au lieu de la directive go 1.26.0 de go.mod. Tu peux soit passer la version de la directive go à setup-go sous la forme go-version (lue avec une étape sed), soit reformuler le commentaire et le nom du leg pour indiquer qu'il teste la ligne de toolchain. C'est terminé lorsque le journal du leg affiche la version de la directive, ou lorsque le commentaire correspond à ce qui est testé, et que la décision du plancher 1.26.0 est notée à côté de la règle d'ignorance lipgloss dans .github/dependabot.yml.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Go
Étoiles
1
Forks
1
Merge moyen
6 h 42 min
PR mergées (30 j)
7

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de TMHSDigital/subenum

Toutes les issues de TMHSDigital/subenum

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.