platform/portal
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

ci(portal): retarget image build to registry.meghsakha.com + orca webhook #14

Merged
sharang merged 2 commits from ci/registry-meghsakha-orca-webhook into main 2026-06-10 12:05:39 +00:00
Conversation 0 Commits 2 Files Changed 1
+27 -8
sharang commented 2026-06-10 10:13:51 +00:00
Owner
Copy Link
Copy Source

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

  • 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

🤖 Generated with Claude Code

## 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)
sharang added 1 commit 2026-06-10 10:13:53 +00:00
ci(portal): retarget image build to registry.meghsakha.com + orca webhook
ci / shared (pull_request) Successful in 14s
Details
ci / test (pull_request) Successful in 10m17s
Details
ci / e2e (pull_request) Has been skipped
Details
ci / image (pull_request) Has been skipped
Details
8fc4dc09c9 
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 added 1 commit 2026-06-10 10:18:21 +00:00
ci(portal): sign orca webhook POST with HMAC-SHA256
ci / shared (pull_request) Successful in 13s
Details
ci / test (pull_request) Successful in 10m17s
Details
ci / e2e (pull_request) Has been skipped
Details
ci / image (pull_request) Has been skipped
Details
3fa0e26bd1 
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 main 2026-06-10 12:05:39 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Benjamin_Boenisch sharang (Sharang Parnerkar)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: platform/portal#14
Delete Branch "ci/registry-meghsakha-orca-webhook"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?