The previous CI pushed images to registry.breakpilot.com (a future prod registry that doesn't exist yet) and tried to call orca apply --env=stage, a CLI shape this orca version doesn't ship. Result: image build job failed at the docker login step.
What
Retarget the image build to the live infrastructure used by every other service in orca-infra:
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
One-time setup before this can deploy
Add Gitea Actions secrets on this repo: REGISTRY_USER + REGISTRY_PASS (the existing htpasswd creds — same ones used in other Gitea Actions workflows that push to this registry)
On the orca master (46.225.100.82):
orca webhooks add --repo platform/portal --service breakpilot-portal --branch main
Test plan
Merge → push to main fires CI
image job builds + pushes both tags to registry.meghsakha.com
curl to orca webhook returns 200
Master pulls :latest and recreates breakpilot-portal
## Why
The previous CI pushed images to `registry.breakpilot.com` (a future prod registry that doesn't exist yet) and tried to call `orca apply --env=stage`, a CLI shape this orca version doesn't ship. Result: image build job failed at the docker login step.
## What
Retarget the image build to the live infrastructure used by every other service in `orca-infra`:
- Registry: `registry.meghsakha.com` (htpasswd-backed, S3-storage)
- Image path: `breakpilot/portal` (mirrors `breakpilot/compliance-*`, `breakpilot/pitch-deck`)
- 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`
## One-time setup before this can deploy
1. Add Gitea Actions secrets on this repo: ` REGISTRY_USER` + `REGISTRY_PASS` (the existing htpasswd creds — same ones used in other Gitea Actions workflows that push to this registry)
2. On the orca master (46.225.100.82):
```
orca webhooks add --repo platform/portal --service breakpilot-portal --branch main
```
## Test plan
- [x] Merge → push to main fires CI
- [x] `image` job builds + pushes both tags to registry.meghsakha.com
- [x] curl to orca webhook returns 200
- [x] Master pulls `:latest` and recreates `breakpilot-portal`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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>
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>
sharang
merged commit 0862420e7c into main2026-06-10 12:05:39 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
The previous CI pushed images to
registry.breakpilot.com(a future prod registry that doesn't exist yet) and tried to callorca apply --env=stage, a CLI shape this orca version doesn't ship. Result: image build job failed at the docker login step.What
Retarget the image build to the live infrastructure used by every other service in
orca-infra:registry.meghsakha.com(htpasswd-backed, S3-storage)breakpilot/portal(mirrorsbreakpilot/compliance-*,breakpilot/pitch-deck):latest(for the webhook-driven deploy) +:sha-<sha>(traceability)orca-infra/WEBHOOKS.mdOne-time setup before this can deploy
REGISTRY_USER+REGISTRY_PASS(the existing htpasswd creds — same ones used in other Gitea Actions workflows that push to this registry)Test plan
imagejob builds + pushes both tags to registry.meghsakha.com:latestand recreatesbreakpilot-portal🤖 Generated with Claude Code
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>