akiomik / akiomik/mado

CI does not check the winget manifest's ReleaseDate against the changelog

Ouverte
#416 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
ci
Langage dominant
Rust
Étoiles
409
Forks
12
Merge moyen
5 h 45 min
PR mergées (30 j)
30

Description

`pkg/winget/mado.yml` carried `ReleaseDate: 2025-01-17` — v0.1.4's date — from
v0.1.5 through v0.3.2, because nothing moved it and nothing noticed. #415 makes
`just update-winget` stamp it from the changelog heading for the version, which
closes the path that let it drift. It does not close the others: a hand edit,
or a release where step 4 of the release procedure is done by hand or skipped,
puts the manifest right back into the state it was in for four releases.

The two checks that touch this file today both miss it:

- `scripts/release/check-versions.sh` reads the version pins only — `Cargo.toml`,
`Cargo.lock`, `action/entrypoint.sh`, `README.md`. `pkg/` is out of its scope
by design, since those manifests legitimately lag by one release until CD has
published.
- the winget job in `ci-pkg.yml` runs `winget validate`, which checks the
manifest's shape against the schema. `ReleaseDate` is an optional
`format: date` string there, so any well-formed date passes — including one
from a release two years back.

## What a check would assert

`ReleaseDate` equals the date on the `## [] - YYYY-MM-DD`
heading in `CHANGELOG.md`.

It has to skip while `PackageVersion` is behind `Cargo.toml`, which is every
commit between a release PR merging and the packages PR merging — the window
the release procedure documents as expected. Reading the version from the
manifest rather than from `Cargo.toml` gives that for free: during the window
the manifest names the previous release, and the previous release's changelog
section is still there to agree with.

## Notes

Whether the changelog is the right source at all is a separate question — #415
takes the date from there rather than from the release's `publishedAt`, so that
the release notes and the manifest cannot disagree, at the cost of following
the timezone whoever dated the changelog was in. A check built on the changelog
locks that choice in; one built on `publishedAt` would need the release to
exist, which is true by the time step 4 runs but not while CI runs on the
release PR.

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Inspect ci-pkg.yml, scripts/release/check-versions.sh, pkg/winget/mado.yml, and CHANGELOG.md, starting with the existing winget job and the manifest and changelog version formats. The check is done when it compares the manifest's PackageVersion and ReleaseDate with the matching changelog heading while allowing the documented release-window lag; run the relevant CI validation locally if available.

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

Évaluation

Stack technique
github-actions, rust, shell
Domaine
ci-cd, release
Type d'issue
Fonctionnalité
Difficulté
3/5
Temps estimé
1-2 jours
Activité
Active
Clarté
Clairement spécifiée
Accessibilité débutants
76/100

Recevez les nouvelles issues par e-mail

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