STAC-25500 Port the DEB signing and pre-release publishing lane to GitHub Actions

[LouisParkin]

Closes the last two GitLab jobs on this repo with no GitHub counterpart: sign_deb and pre_release_deb (.gitlab-ci-agent.yml lines 604 and 635). Stacked on #454.

Security prerequisite, not cleanup

sign_debian_package.sh called printenv unconditionally. On GitLab that dumped the GPG private key and its passphrase into the job log. stackstate-agent is a public repo, so on GitHub that log is world-readable. It also left the exported private key in the checkout as gpg_private.key, where any later artifact upload would collect it.

Both are removed before any signing secret is wired in, as STAC-25500 requires. Key setup now happens in an ephemeral GNUPGHOME (mktemp, mode 700) removed by an EXIT trap that also kills the gpg-agent, so a preset passphrase cannot outlive the job on a reused runner. The passphrase reaches gpg through a mode-600 file, never argv.

Fixes a latent signing bug

The old preset step was:

echo $SIGNING_PRIVATE_PASSPHRASE | gpg-preset-passphrase -v -c $(gpg --list-secret-keys ... | awk ...)

A key exposes one keygrip per primary and subkey. Unquoted, that substitution expands to multiple words, so with a signing subkey the second keygrip became a stray argument and was never presetted — leaving signing able to block on a pinentry prompt no CI runner can answer. Each keygrip is now presetted individually.

Verified against a generated throwaway key: two keygrips, both presetted, passphrase delivered on stdin, GNUPGHOME removed by the trap, nothing left in the workspace.

Shared setup

The two scripts need the same key in the same state but are separate processes, and on GitHub may be separate steps, so neither can rely on a keyring the other left behind. The setup moves into gpg_signing_setup.sh, sourced by both. gpg-preset-passphrase is auto-detected across /usr/lib/gnupg2, /usr/lib/gnupg, /usr/libexec and PATH (the path differs by distro and release), and it fails loudly rather than silently skipping the preset when absent.

Both scripts fall back CI_PROJECT_DIR → GITHUB_WORKSPACE, and publish_package.sh falls back CI_COMMIT_REF_NAME → GITHUB_REF_NAME, so the apt codename stays the release branch exactly as on GitLab.

Workflow

Job	Notes
sign-and-publish-deb	Downloads both arch artifacts and runs a single deb-s3 upload. GitLab fanned this out per arch, so two jobs rewrote the same apt index concurrently — collecting both first removes that race.
generate-install-script	Runs inv release.generate-install -t inside the build container: the task collection imports python-gitlab plus the GitHub/Datadog API helpers and only loads in the conda env. Asserts the rendered script contains no None.s3.amazonaws.com from an unset bucket variable — generate_install reads three bucket vars and silently renders None for any that are missing.
publish-install-script	Uploads it, so the container job never holds a credential.

Both publishing jobs are gated on push and bound to the agent-pre-release environment, which carries the deployment branch rule, the signing secrets and the AWS role. Pull requests cannot reach them.

Blocked on

This lane cannot go green until these exist — the code is ready and reviewable now:

1. GitHub environment agent-pre-release with a deployment branch rule for the release branch.
2. Secrets in it: SIGNING_PUBLIC_KEY, SIGNING_PRIVATE_KEY, SIGNING_PRIVATE_PASSPHRASE, SIGNING_KEY_ID.
3. Variable AGENT_PRERELEASE_ROLE_ARN, from StackVista/terraform-infra#76 (STAC-25545).

Validation

• shellcheck -x — clean on all three scripts.
• gpg_signing_setup exercised against a real generated key: explicit override, PATH auto-detection, and the missing-binary failure path (exits 1 with a clear message).
• actionlint — clean apart from the pre-existing self-hosted runner-label notices.
• zizmor v1.28.0 — No findings to report.
• YAML parses; all 10 needs: references resolve.

https://stackstate.atlassian.net/browse/STAC-25500
Refs https://stackstate.atlassian.net/browse/STAC-25546 and https://stackstate.atlassian.net/browse/STAC-25545

[LouisParkin]

Rebase regression fixed — amd64 gate is green

1a2d643ef3 restores two lines that the earlier rebase silently reverted.

When this branch was rebased onto the updated #454, the conflict in build-deb.yml was resolved with git checkout --theirs, which takes the replayed commit's whole copy of the file. That copy predated the exception work on #454, so it quietly dropped the quay-qualified LOCAL_IMAGE and exceptions-path: exceptions. It passed lint and read fine — the only symptom was in the gate summary.

Before (e3a578b, amd64):

total in-scope findings:  24
suppressed by exception:  0
unmanaged:                24

After (1a2d643, amd64):

total in-scope findings:  24
suppressed by exception:  24
unmanaged:                0

That now matches #454 exactly. Verified structurally too — git diff STAC-25457-publish-lane -- .github/workflows/ on this branch is additions-only, no removed lines.

Remaining red is one external gap, not this PR

The only failing jobs left on this branch are the two arm64 container image builds:

• Build agent container image (docker build, no push on PR, arm64)
• Build cluster-agent container image (docker build, no push on PR, arm64)

Both die inside scan-image with:

##[error]VEX repositories downloaded, but no OpenVEX documents were found for Grype

The message is misleading. The real cause is that the lean arm64 runner image does not ship jq, and scan-image classifies every VEX document with jq -e '...' >/dev/null 2>&1 — so a missing jq is indistinguishable from "not a VEX document" and all 1105 docs are discarded.

The timing confirms it: arm64 "skipped" 1105 documents in 830 ms (~0.75 ms each, too fast to have forked a process) against ~32 ms per document on amd64.

Fix is open as stackstate-ci-images#16 (STAC-25559). Once that image is built and the arm64-docker scale set picks up the new tag, these two jobs should go green with no change needed here.