codeSplitters webhooks: a GitHub-compatible mode so existing CI triggers fire from us #532

Why

codeSplitters should be a proxy to people's existing build setups: the event source and scoreboard, while the build runs wherever it already runs (Jenkins, Buildkite, Argo, homegrown). It's also a hedge in case GitHub Actions gets pricier as agents run CI constantly: switching should mean changing a URL, not rewriting a pipeline.

src/hooks.ts already sends signed, retried, GitHub-shaped JSON, but not GitHub-named:

Off-the-shelf receivers (the Jenkins GitHub plugin, Buildkite, Argo Events, Tekton triggers) switch on those headers, so they ignore us today.

Scope

• A per-hook github_compat: true option. When it's on, deliveries use GitHub's event names and headers, and the payload fields those receivers actually read (ref, before, after, repository.clone_url, head_commit, pull_request.*).
• clone_url points at our git endpoint, so the receiver can fetch the sha.
• Keep the native names as the default.

Done when

• Tests show a compat delivery passing GitHub's signature check (HMAC over the body with the hook secret) and carrying the right headers.
• One real receiver (for example a local Jenkins or a smee-style relay) triggers on a codeSplitters commit. File that as a MANUAL RUN issue if it needs a person.

Related: #463, #465, and the GitHub API shim (#533).

🤖 Generated with Claude Code