[dennisklein]

Requested by Dennis · project thread

Before: the RPMs for Fedora 43 and 44 were only CI artifacts, so users had to download and install them by hand and got no updates.

After: a workflow builds each release tag, signs the packages and the repository metadata, smoke-tests the result in Fedora containers and deploys it to https://dennisklein.github.io/nm-sshuttle/. The nm-sshuttle-release package installs the .repo file and the public key. There is no deb repository.

Stacked on #12 (several tunnels), so its base is that branch. Merge #12 first.

This ports the repository from brig (packaging/, scripts/signing-key.sh, the packages and release workflows), minus everything specific to OpenShell, SELinux and the daily upstream check.

How:

• packages.yaml builds SRPMs once, rebuilds them per Fedora release (from packaging/fedora-releases, now 43 and 44), then signs, assembles, smoke-tests and deploys. The existing specs in packaging/rpm/ are reused unchanged.
• A tag vX.Y.Z is packaged under its own version, whatever the specs say. release.yaml starts packages on main for each such tag, since only main may use the signing key. Tags with a hyphen are skipped.
• Pull requests, and runs before the first tag or the key exist, assemble and smoke-test the repository with a throwaway key and deploy nothing. The dry run passed on Fedora 43 and 44 before the rebase onto feat: several tunnels at once #12.
• The site restores the published packages on each run and keeps the newest two versions, so the repository's only state is the Pages site.

Not exercised yet: the real publish and deploy path (signing with the real key, restoring published packages, Pages), which needs the steps below.

Before the first real publish (only the owner can do these):

1. Run scripts/signing-key.sh with the gh CLI signed in as a repository admin. It creates the rpm-signing environment restricted to main, stores RPM_SIGNING_KEY in it and writes packaging/nm-sshuttle-release/RPM-GPG-KEY-nm-sshuttle. Commit that file to main.
2. In the repository settings, under Pages, set the source to GitHub Actions.
3. Push an annotated release tag, for example git tag -a v0.1.0 -m 'nm-sshuttle 0.1.0'. There are no tags yet.

See packaging/README.md for the details.

🤖 Generated with Claude Code

https://claude.ai/code/session_012sahcREDt4XASbqgwTDvYx

[dennisklein]

The one red check here is the release workflow's packages job, which the v0.1.0 tag push started. It runs gh workflow run packages.yaml --ref main, and main does not have packages.yaml with a workflow_dispatch trigger until this PR is merged (HTTP 422: Workflow does not have 'workflow_dispatch' trigger). That is expected before the merge and not a fault in the change.

After the merge, the push to main runs packages, whose plan picks the newest tag, v0.1.0, and publishes it for real. No re-run of release is needed. Everything else on the current head is green.

---

Generated by Claude Code