Skip to content

feat(v0.1.1-PR-C): release-publish workflow with pre-publish assertions#58

Open
BitCrafts wants to merge 1 commit into
mainfrom
feat/v0.1.1-release-publish-workflow
Open

feat(v0.1.1-PR-C): release-publish workflow with pre-publish assertions#58
BitCrafts wants to merge 1 commit into
mainfrom
feat/v0.1.1-release-publish-workflow

Conversation

@BitCrafts
Copy link
Copy Markdown
Contributor

Summary

PR C of three for v0.1.1. Closes #57.

Adds a manual workflow_dispatch gate that codifies every check we ran by hand against v0.1.0 to find its regressions:

  1. Tag exists + Release is a draft (refuses to "publish" the wrong thing)
  2. sha256sum -c SHA256SUMS
  3. Every .tar.zst ships a LICENSE.* / COPYING file at root (would have caught package: bc-tools + bc-libs tarballs ship without their LICENSE files (GPL/LGPL non-compliance) #53)
  4. bc-tools-*/bin/* doesn't dynamically link liburing / libblake3 / libxxhash (would have caught package(bc-tools): binaries dynamically link liburing despite README promising static #54)
  5. Vigil source tarball ≥ 100 KiB (would have caught the PR fix(ci): correct LICENSE path in Vigil source-tarball step #44 regression)

If every assertion holds, the workflow runs gh release edit <tag> --draft=false and emits the published URL as a GH Actions notice.

release.yml keeps --draft. This is the audit that says "ship it" — one click, with the gates running automatically.

Usage

GitHub → Actions → release-publish → Run workflow → tag=v0.1.1

Local verification

  • YAML parses cleanly via python3 -c "yaml.safe_load(...)"
  • All 8 embedded run: scripts are shellcheck-clean (severity=warning)
  • Permissions scoped tight: only contents: write (needed to edit the Release)
  • No new secrets required; uses the default GITHUB_TOKEN

Test plan

  • CI green (this PR doesn't touch C/Python so the only relevant checks are CodeQL Analyze actions + DCO + detect-changes)
  • After merge: tag v0.1.1 (which will exercise the FIXED release.yml from PRs A + B), then trigger release-publish manually with tag=v0.1.1 and confirm it publishes the Release cleanly

Add `.github/workflows/release-publish.yml`, a `workflow_dispatch`
gate between a draft GitHub Release (created by release.yml on
tag push) and its publication. The maintainer triggers it from
the Actions UI with the tag as input; the workflow runs every
check that caught a v0.1.0 regression, then flips
`gh release edit <tag> --draft=false` if and only if every
assertion holds.

release.yml keeps `--draft` as the safety net. This workflow is
the audit step that says "yes, ship it".

Assertions encoded (each its own named step so the UI shows
which one failed):

1. The tag exists and the Release for that tag is currently a
   draft — refuses to "publish" an already-published Release
   or one that was deleted.
2. `sha256sum -c SHA256SUMS` validates every asset checksum.
3. Every `.tar.zst` ships a top-level `LICENSE.*` or `COPYING`
   file — would have caught the v0.1.0 bc-tools / bc-libs
   GPL §3 / LGPL §4 non-compliance (#53).
4. `ldd` on each `bc-tools-*/bin/*` binary refuses any reference
   to `liburing`, `libblake3`, or `libxxhash` — would have caught
   the v0.1.0 dynamic-link regression (#54). Mirror of the new
   in-build assertion in scripts/lib/bx-package.sh.
5. The Vigil source tarball is at least 100 KiB — would have
   caught the v0.1.0 13-byte zstd-of-empty regression (PR #44),
   defence in depth alongside release.yml's own size check.

Each `run:` block uses `set -euo pipefail`. All eight embedded
scripts are shellcheck-clean.

Triggering:

  GitHub → Actions → release-publish → Run workflow → tag=vX.Y.Z

Closes #57.

Signed-off-by: Younes Benmoussa <younes.benmoussa@pm.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ci: add release-publish workflow with pre-publish assertions

1 participant