build: Linux packages, and the Steadybit apt and yum repositories

[achoimet]

Adds .deb and .rpm packages for the CLI, with publishing to Steadybit's own apt/yum repositories at packages.steadybit.com (the ones the agent comes from) ready to switch on.

What's in it

• goreleaser nfpms: a steadybit-cli package, named like steadybit-agent; the command is still steadybit. It holds:

  • /usr/bin/steadybit;
  • bash, zsh and fish completions in the distributions' standard locations;
  • the license.

  The files are steadybit-cli_{amd64,arm64}.{deb,rpm} with no version in the name, so the releases/latest/download/… URLs stay stable.

• Signed with the agent's key (MAVEN_GPG_PRIVATE_KEY / _PASSWORD, org secrets this repo can read). A local snapshot builds unsigned.

• Release job: attaches the packages to the GitHub release, and would publish them to deb-public / yum-public through steadybit/.github/actions/gar-upload-linux-packages, the same action the extensions use.

• New linux-packages job (every run except tags and the daily schedule):

  • builds a snapshot;
  • installs the .deb on Ubuntu and the .rpm in a fedora:latest container, and runs steadybit -V;
  • uploads to deb-dev / yum-dev on main and on manual runs, as the extensions do.

  Pull requests build unsigned packages and upload nothing.

Blocked on Google Cloud access. A manual run of this branch built, signed, installed and ran both packages. The upload was refused:

Permission 'iam.serviceAccounts.getAccessToken' denied

The workload identity provider behind GCP_ARTIFACT_REGISTRY_IDENTITY_PROVIDER doesn't trust steadybit/cli; it evidently allows specific repositories. Both uploads therefore run only when the repository variable PUBLISH_LINUX_PACKAGES is true, so merging breaks neither main nor releases. To switch on:

1. A Google Cloud admin gives steadybit/cli access to the upload service account: a roles/iam.workloadIdentityUser binding for the repository's principal set, or an entry in the provider's attribute condition, as done for the extensions.
2. Set PUBLISH_LINUX_PACKAGES=true in this repository's variables. Start CI by hand on main to test the upload against the dev repositories.
3. Then add the repository installs to the README:

   # Debian, Ubuntu
   sudo mkdir -p /etc/apt/keyrings
   curl -fsSL https://europe-west1-apt.pkg.dev/doc/repo-signing-key.gpg | sudo tee /etc/apt/keyrings/steadybit.asc >/dev/null
   printf 'Types: deb\nURIs: https://packages.steadybit.com\nSuites: deb-public\nComponents: main\nSigned-By: /etc/apt/keyrings/steadybit.asc\n' | sudo tee /etc/apt/sources.list.d/steadybit.sources >/dev/null
   sudo apt-get update && sudo apt-get install steadybit-cli
   # Fedora, RHEL, Amazon Linux
   printf '[steadybit]\nname=steadybit\nbaseurl=https://packages.steadybit.com/yum-public\nenabled=1\ngpgcheck=0\n' | sudo tee /etc/yum.repos.d/steadybit.repo >/dev/null
   sudo dnf install steadybit-cli

   These are the repository definitions get.steadybit.com/agent-linux.sh writes.

Until then, the README documents installing the attached .deb/.rpm.

Testing

• goreleaser check passes.
• A local snapshot contains the files listed above, and its control data is right (package, maintainer, homepage).
• In CI: packages built and signed, installed and run on Ubuntu 24.04 and Fedora.
• The signing passphrase goes in NFPM_PASSPHRASE: the extensions' NFPM_DEFAULT_PASSPHRASE only applies to package configs without an id.