When `orca webhooks add` registers a webhook it generates a signing
secret by default; orca then requires X-Hub-Signature-256 on inbound
POSTs (the public master at :6880 means anyone could otherwise fire
a deploy by crafting the JSON body).
Adds the signing step using the standard github-shaped header. The
secret is consumed from a new Gitea Actions secret ORCA_WEBHOOK_SECRET
on this repo — value provided out-of-band from the master.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The previous CI pushed to registry.breakpilot.com (the future prod
registry that doesn't exist yet) and tried to call `orca apply`, a
CLI shape this orca version doesn't ship. Repointing to the live
infrastructure:
- registry: registry.meghsakha.com
- image path: breakpilot/portal (sibling of breakpilot/compliance-*)
- tags: :latest (for the webhook-driven deploy) + :sha-<sha> (traceability)
- redeploy: POST github-style payload to the orca webhook on the master,
matching the pattern documented in orca-infra/WEBHOOKS.md
The webhook must be registered once on the master:
orca webhooks add --repo platform/portal \
--service breakpilot-portal --branch main
CI also needs REGISTRY_USER + REGISTRY_PASS set on this Gitea repo's
Actions secrets — same htpasswd-backed creds the master uses today.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sharang Parnerkar