CI: auto build + deploy guide to bcos.dev on push (cd-develop) #5

Open
opened 2026-07-05 13:08:58 -04:00 by hiveiq · 2 comments
Owner

Why

The guide bundles markdown into the backend jar at build time, so a git-pull never updates a running instance — it must be rebuilt + redeployed. Today that's fully manual (mvn package → docker build → push → ssh deploy), which is error-prone (easy to forget the redeploy; easy to docker build without mvn package and ship stale content). The guide is the ideal CI candidate: content-only, frequent edits, low risk.

Scope — guide-specific exception to the manual-deploy policy

CI is disabled org-wide (deploys manual, per the cd-develop rework). The guide has no workflows at all. This adds CI for the guide only, and — because it's docs on the dev environment — includes auto-deploy to bcos.dev (justified: docs, dev, low blast radius). Prod stays gated.

cd-develop.yml (this issue)

On push to develop: build backend jar (mvn package) → docker build → push registry.bcos.dev/hiveiq-guide-backend:devdeploy to bcos.dev (.251: docker compose pull && up -d hiveiq-guide-backend) → smoke the API.

Publishing model (confirmed)

Audience filtering is runtime via GUIDE_SERVED_AUDIENCES (bcos.dev = all four tiers; prod = customer,internal). So CI needs no build-time audience filtering — same image everywhere, env var per deployment controls what's served. A future cd-main.yml handles prod publish (gated).

Dependency — coordinate with CI/runner session (dlx-claude)

The auto-deploy step needs the Gitea runner to SSH to bcos.dev (.251) — requires a deploy-key secret + network reachability. Flagging so it's provisioned deliberately.

## Why The guide bundles markdown **into the backend jar at build time**, so a git-pull never updates a running instance — it must be rebuilt + redeployed. Today that's fully manual (`mvn package → docker build → push → ssh deploy`), which is error-prone (easy to forget the redeploy; easy to `docker build` without `mvn package` and ship stale content). The guide is the ideal CI candidate: content-only, frequent edits, low risk. ## Scope — guide-specific exception to the manual-deploy policy CI is disabled org-wide (deploys manual, per the cd-develop rework). The guide has **no workflows at all**. This adds CI **for the guide only**, and — because it's docs on the **dev** environment — includes **auto-deploy to bcos.dev** (justified: docs, dev, low blast radius). Prod stays gated. ## cd-develop.yml (this issue) On push to `develop`: build backend jar (`mvn package`) → docker build → push `registry.bcos.dev/hiveiq-guide-backend:dev` → **deploy to bcos.dev** (`.251`: `docker compose pull && up -d hiveiq-guide-backend`) → smoke the API. ## Publishing model (confirmed) Audience filtering is runtime via `GUIDE_SERVED_AUDIENCES` (bcos.dev = all four tiers; prod = `customer,internal`). So CI needs **no** build-time audience filtering — same image everywhere, env var per deployment controls what's served. A future `cd-main.yml` handles prod publish (gated). ## Dependency — coordinate with CI/runner session (dlx-claude) The auto-deploy step needs the **Gitea runner to SSH to bcos.dev (`.251`)** — requires a deploy-key secret + network reachability. Flagging so it's provisioned deliberately.
Author
Owner

Coordination sent to dlx-claude (runner/CI owner) 2026-07-05 via the email bridge: requested the BCOS_DEV_DEPLOY_KEY secret (scoped SSH key for bcosadmin@.251) + confirmation the runners can reach 173.231.195.251:22. Offered a pull-based alternative (watcher on .251) if they'd rather not grant runners SSH into bcos.dev. Build+push works on merge; the deploy step activates once the secret is provisioned. PR #6 awaiting approval.

Coordination sent to dlx-claude (runner/CI owner) 2026-07-05 via the email bridge: requested the **BCOS_DEV_DEPLOY_KEY** secret (scoped SSH key for bcosadmin@.251) + confirmation the runners can reach 173.231.195.251:22. Offered a pull-based alternative (watcher on .251) if they'd rather not grant runners SSH into bcos.dev. **Build+push works on merge; the deploy step activates once the secret is provisioned.** PR #6 awaiting approval.
Author
Owner

Done + verified 2026-07-05. cd-develop.yml live: push to develop (backend paths) -> mvn package -> build -> push :dev -> deploy to bcos.dev -> smoke. Just ran fully GREEN (all 6 steps Success incl. Deploy + Smoke). Deploy key provisioned as a scoped forced-command key on .251 (locked to the guide compose pull/up only; verified an arbitrary command is ignored) + stored as BCOS_DEV_DEPLOY_KEY secret. dlx-claude notified. The guide is now auto-deploy-on-push — no more manual rebuild/redeploy.

**Done + verified 2026-07-05.** cd-develop.yml live: push to develop (backend paths) -> mvn package -> build -> push :dev -> deploy to bcos.dev -> smoke. Just ran fully GREEN (all 6 steps Success incl. Deploy + Smoke). Deploy key provisioned as a scoped **forced-command** key on .251 (locked to the guide compose pull/up only; verified an arbitrary command is ignored) + stored as BCOS_DEV_DEPLOY_KEY secret. dlx-claude notified. The guide is now auto-deploy-on-push — no more manual rebuild/redeploy.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: hiveiq-src/hiveops-guide#5