a6970c7e7 did this for the sdist: its provenance attestation is only
stored in the GitHub attestations API, and fetching it from there needs
a recent gh and a GitHub token, so the sigstore bundle is attached to
the release as <asset>.sigstore.jsonl for offline verification.
Do the same for the standalone binaries: the jobs that build them attest
them, so they are also the ones that have the bundle. Each of them stores
it under the name of every asset it attested (one attestation covers both
the single-file binary and the .tgz) and uploads it in the artifact that
carries the binaries, so the release job attaches it to the release along
with them - it uploads whatever is in the artifacts.
vm_tests attested after uploading its artifact, so the attestation is now
made before the upload, like in the other two jobs.
Also document the offline verification in the binaries README (which is a
release asset itself) and in the release checklist.
Co-Authored-By: Claude Opus 5 <[email protected]>
The usage/man docs sources live in the src/borg/archiver/ package;
the monolithic archiver.py is borg 1.x.
Co-Authored-By: Claude Fable 5 <[email protected]>
The auto-generated release notes claimed the macOS binaries are built
with FUSE support; they are built with the "none" FUSE variant
(toxenv py314-none) and no workflow installs macFUSE, matching what
00_README.txt says. Also drop the corresponding stale macFUSE step
from the release checklist.
Co-Authored-By: Claude Fable 5 <[email protected]>
Vagrant is no longer used for testing environments or binary builds
(platform testing and binary building happen on GitHub CI; local Linux
testing uses Podman via scripts/linux-run). The section also claimed a
"windows10" box that the Vagrantfile does not define.
Co-Authored-By: Claude Fable 5 <[email protected]>
The advanced tox examples predate tox 4: positionals before -- are
rejected now, and borg.testsuite.locking no longer exists. Also, with
the [tool.tox] TOML-array commands, everything after -- becomes a
single --pyargs value, so module selection works but combining it with
pytest options like -k does not; say so and point at running pytest
directly instead. Also fix the tox.ini and borg/archiver.py references.
Co-Authored-By: Claude Fable 5 <[email protected]>
Pushing a release tag so far only built the standalone binaries and uploaded
them as workflow artifacts - everything else was manual: build and sign the
sdist, upload it to PyPI, fetch the binary artifacts and create the GitHub
release with them.
Add a release job (.github/workflows/release.yml), called by ci.yml for tags
after the tests and the binary builds succeeded - it runs inside the same
workflow run, because that is where the binary artifacts are. It builds the
sdist, verifies that the sdist is complete by installing it into a clean venv
and running borg, attests its provenance and drafts the GitHub release with
the sdist and all standalone binaries attached.
A pypi job then uploads the sdist to PyPI via trusted publishing, so no API
token has to be stored anywhere. It lives in ci.yml because PyPI trusted
publishing does not work from a reusable workflow. It uses the "pypi"
environment: configuring required reviewers for it makes the irreversible
upload wait for an approval.
The Windows binaries now use the same naming and layout as the binaries of
the other platforms (borg-windows-x86_64-gh.exe and .tgz, with the
single-directory variant and a provenance attestation), so they become
release assets, too.
The GitHub release is created as a draft: the release notes want a human, the
detached GPG signature of the sdist can only be made locally, and the binaries
should be tried out before the release becomes visible.
bad:
- no *BSD testing and FreeBSD binary building on gh
- binaries not signed by me, because they are built on gh
good:
- for linux intel/amd64 and arm64, built on ubuntu
- for macOS intel and arm64, built on a relatively recent macOS
- I can get rid of that ancient macOS VM I used for building.
- the source code distribution (sdist) is still made locally on
my machine and thus signed with my signature (*.asc).
last coala release (0.11.0) is now over 6y old.
when using pip install coala, a ton of stuff gets installed (expected)
and a part of that downgrades some stuff we use to outdated, incompatible
versions.
when trying to run coala with python 3.11, it just crashes because the
last release was made for py35/py36 (as seen in their setup.py).
a lot of PRs and tickets pile up at the coala project on github,
but noone is maintaining it.
Fix various code blocks in the docs
- rst markup: put codeblock markup on separate line to make it better visible / separate it from normal text colons.
- borg help texts in archiver.py: put codeblock markup instead of colon - that way it looks like a single colon when using the cli help and also works as code block markup.
