STAC-25142 Add GitHub Actions lint + unit-test workflow (agent CI migration phase 1)

[LouisParkin]

What

Phase 1 of the stackstate-agent GitLab → GitHub CI migration (STAC-25142): ports the lint + unit-test jobs from .gitlab-ci-agent.yml to a GitHub Actions workflow, .github/workflows/lint-and-unit-tests.yml.

Job	Runner	Ported from
filename-linting	docker	filename_linting — cheap gate; only needs git ls-files, so the GitLab job's inv deps/go work vendor boilerplate is dropped
unbranded-unit-tests	xlarge	unbranded_unit_tests — full inv agent.build --race + inv test, DataDog branding
branded-unit-tests	xlarge	branded_unit_tests — same + ./fix_branding.sh, StackState branding

All three run inside container: <proxy>/quay/stackstate/datadog_build_linux_x64:0cd01a13 — the same BUILD_IMAGE the GitLab pipeline uses (produced by datadog-agent-buildimages, pulled via the read-only quay proxy). No new runner class is needed: xlarge (6 CPU / 40Gi, DinD) maps to GitLab sts-k8s-xl-runner.

Test-execution policy (architect directive — minimize redundant runs)

Each suite runs once on the path to master:

• filename-linting on every PR (fast).
• The two ~2h suites run on pull_request, deduped via concurrency: cancel-in-progress.
• Follow-up (Phase 6): when the merge queue is enabled, the heavy suites move to merge_group (run once at land) and drop from pull_request; master/version-branch pushes then build + publish without re-running tests.

Open question raised for architects (biggest compute lever, tracked in the migration scope doc): unbranded and branded are nearly the same ~2h job twice — do we need both on every path, or branded-as-gate + unbranded on the queue only?

Prerequisite for green checks

This is a public repo, so the read-only registry-proxy credentials must be available to it for the container: image pull: vars.REGISTRY_HOST, vars.REGISTRY_USER, secrets.REGISTRY_PASSWORD. If the first run fails on the image pull, these need scoping to this repo (org secret scope, or a repo-level read robot as done for datadog-agent-buildimages). Org secrets are never exposed to fork PRs, so fork PRs skip these jobs by design.

Security

contents: read only, SHA-pinned actions/checkout, persist-credentials: false, no PATs, registry secret only via container.credentials. Zizmor: clean. actionlint: clean apart from expected self-hosted-runner label warnings (docker, xlarge).

Validation

• YAML parses; Zizmor clean; actionlint clean (self-hosted labels aside).
• CI (the heavy suites) will exercise the container:-on-xlarge (manual DinD) path for the first time — that's the main thing this PR validates.

Jira: https://stackstate.atlassian.net/browse/STAC-25142

🤖 Generated with Claude Code

[LouisParkin]

Added commit: Cerberus bearer token (STAC-25536)

Heads-up for anyone who already reviewed — one commit added on top: ed1f889f.

StackVista/cerberus#4 (STAC-24889) adds authentication to the Cerberus Lambda. The endpoint was previously completely unauthenticated — anyone who knew the URL could lock/unlock a protected branch or post as the Cerberus Slack bot. Every non-Slack request must now carry Authorization: Bearer <ssm:/cerberus/api-token>, compared constant-time in internal/auth/auth.go → verifyBearer.

That PR is still open, so cerberus-notify.yml as reviewed works today. The moment it deploys, the unauthenticated POST gets a 401, curl --fail reddens the notify job, and no Slack message is sent — the exact silent-failure condition the job exists to remove.

Sending the header now is forward-compatible (the deployed Lambda ignores unknown headers), so this is correct either side of that deploy and needs no coordination. Fixing it here rather than as a follow-up PR because this branch hasn't merged yet.

Changes

• cerberus-notify.yml: CERBERUS_API_TOKEN added to workflow_call.secrets + step env; bearer header on the POST; guard extended to both secrets.
• The three callers (build-binaries, build-deb, lint-and-unit-tests) pass the secret through.
• Dropped curl --verbose — it echoes request headers, which now include the token. GitHub would mask it, but not emitting it beats relying on masking.

CERBERUS_API_TOKEN already exists as a repo-level secret alongside CERBERUS_LAMBDA_URL (both provisioned 2026-08-04), so no pulumi-infra change is needed — verified against the repo's secret list.

required: false is deliberate and unchanged in spirit from the URL: passing ${{ secrets.X }} for a secret the repo lacks yields an empty string, which GitHub rejects against a required secret and fails the call before the guard can warn.

Validation

• zizmor: clean on all four workflows.
• actionlint: no new findings (only pre-existing self-hosted runner-label noise).
• actionlint negative control: renaming the secret to CERBERUS_API_TOKENN made it report "secret CERBERUS_API_TOKEN is not defined in ./.github/workflows/cerberus-notify.yml" for all three callers — proving the reusable-workflow call is genuinely resolved, not silently passed.
• Execution harness: extracted the real run: body and ran it against a stubbed curl. Bearer header is a single argv element; a hostile commit message ("quoted" $(whoami) + backticks, multi-line) is JSON-escaped into commit.title, not executed, first line only; all three missing-secret combinations warn and exit 0 with no curl call; empty commit message is safe under set -u.

The identical fix shipped for stackstate-process-agent in #253 (merged).