Skip to content

v0.13.1

Choose a tag to compare

@emiliano-go emiliano-go released this 12 Aug 21:24
· 87 commits to master since this release
91bc30f

TL;DR

A release-tooling fix. v0.13.0 shipped correctly (the published tarball and the recorded checksum match), but the release procedure failed the PKGBUILD workflow twice on its way there, and the check()-against-the-shipped-artifact guarantee added in v0.12.1 turned out never to run for the release it was meant to guard. Both are fixed in the workflows; nothing in the analysis engine, the ruleset or the scoring changed.

Fixed

  • The PKGBUILD workflow failed twice on every release. A release moves pkgver and the recorded checksum in two separate commits, and it cannot do otherwise: the checksum is of the tarball GitHub builds from the tag, so it is unknowable until the tag exists. pkgbuild.yml runs on every push, including the version-bump commit and the tag pointing at it, and asserted that the recorded checksum matches the tarball for the recorded version. Between those two commits that assertion cannot hold, so the job failed for a state the release procedure guarantees: once for the branch push, once for the tag push. The workflow now identifies the window and skips the tarball steps with a notice. The three states are distinguishable from the tag alone:

    Commit Condition Tarball checks
    chore(release): bump to vX tag vX does not exist yet skipped
    the tag vX itself HEAD is the tag's own commit skipped
    packaging: set checksum for vX tag exists and HEAD is past it run

    Outside the window the assertion is unchanged and just as strict. The checkout now uses fetch-depth: 0, since a shallow clone carries neither the tags nor the history to tell the states apart.

  • check() never ran against the release tarball it was added to protect. v0.12.1 added a build of the shipped artifact so that a regression breaking it fails CI instead of reaching users. That build lives in pkgbuild.yml, and it could not see the release it was meant to guard: the only commit where the checksum assertion can pass is the packaging: set checksum for vX commit, which release-pkgbuild.yml pushes with GITHUB_TOKEN, and GitHub does not trigger workflows from such pushes. The guarantee therefore first held on the next unrelated push, well after users could install the release. release-pkgbuild.yml now builds and installs the tarball itself (makepkg -si --noconfirm, no --nocheck, no --skipchecksums) in the job that already holds the container, the downloaded tarball and the corrected PKGBUILD, so the release run proves the artifact before publishing it.

Notes

  • v0.13.0 is not affected as a shipped artifact. Its recorded checksum, f083582794221eede5e9fcf89363c30c36bd9adb61399211ad60882d3510751d, matches the tarball GitHub serves for the tag; makepkg --verifysource passed inside the release run, and the PyPI publish, test, security-gate and calibration-gate jobs all succeeded. What failed was the workflow that asserts the checksum from the branch, and what was missing was a build of the artifact during the release itself.
  • This release exercises its own fix. Bumping to 0.13.1 puts the tree back in the window the first fix describes, so the PKGBUILD workflow is expected to report v0.13.1 does not exist yet; release in flight, tarball checks skipped on the bump commit and on the tag, then run in full on the checksum commit.

Stats

  • 4 commits since v0.13.0
  • 6 files changed, +106 / -6
  • 2029 tests (47 files), all passing
  • 51/51 security gates, 10/10 calibration gates
  • Package version 0.13.1