Jinemi/thermograph
4
0
Fork 0
Code Issues 2 Pull requests 4 Projects Releases Packages Wiki Activity Actions 2

promote main -> release: registry host migration to dev.jinemi.com #163

Merged
emi merged 3 commits from main into release 2026-08-01 23:28:37 +00:00
Conversation 0 Commits 3 Files changed 39 +343 -157
emi commented 2026-08-01 23:27:57 +00:00
Owner
Copy link

Promotion of main to release (prod), authorised by the owner.

Ships two commits:

  • 53e2eb7 registry: move the registry host to dev.jinemi.com, MCP to mcp.jinemi.com (#161)
  • 4dcd677 make: add root install/up/down for the local stack

Where the green evidence comes from

CI does not gate PRs into release — pr-build.yml fires only for dev and
main, so this PR will report no status of its own. Stating the actual
provenance rather than implying a check passed here:

  • PR #162 (dev -> main): 18/18 checks green, including the required
    gate, build-backend, build-frontend, validate-observability,
    secrets-guard and shell-lint.
  • Beta is live on the new registry host and healthy. All five
    thermograph-beta services settled at 1/1 on
    dev.jinemi.com/jinemi/thermograph/{backend,frontend}:sha-53e2eb7c842f;
    beta.thermograph.org/healthz returns 200 and /api/version reports
    backend_version=2, payload_ver=p2 — identical to prod's current values, as
    expected for a change that touches deploy config and docs but no application
    code.
  • Dev has been running the same commit's images since before the promotion,
    also healthy.

Prod-specific risk check

Beta and prod are co-resident on vps2, so beta's successful roll exercised the
exact host, /etc/hosts pins, mesh route and REGISTRY_TOKEN path prod will
use. Specifically verified on vps2:

  • both dev.jinemi.com and git.thermograph.org pinned to 10.10.0.2;
  • dev.jinemi.com/v2/ returns 401 (reachable, auth required) via the mesh,
    not 403;
  • REGISTRY_TOKEN present in /etc/thermograph.env (prod's own file), and
    deploy.sh sources it before the docker login, so prod's missing
    dev.jinemi.com credential is recreated on the way through — the same
    sequence that just worked for beta;
  • every service in thermograph-stack.yml is constrained to
    node.role == manager, so no pull can land on an unpinned worker.

Rollback stays available: both names address the same Forgejo and the same
packages, so previously pushed git.thermograph.org/... tags remain pullable.

Promotion of `main` to `release` (prod), authorised by the owner. Ships two commits: - `53e2eb7` registry: move the registry host to dev.jinemi.com, MCP to mcp.jinemi.com (#161) - `4dcd677` make: add root install/up/down for the local stack ## Where the green evidence comes from CI does not gate PRs into `release` — `pr-build.yml` fires only for `dev` and `main`, so this PR will report no status of its own. Stating the actual provenance rather than implying a check passed here: - **PR #162 (`dev` -> `main`): 18/18 checks green**, including the required `gate`, `build-backend`, `build-frontend`, `validate-observability`, `secrets-guard` and `shell-lint`. - **Beta is live on the new registry host and healthy.** All five `thermograph-beta` services settled at 1/1 on `dev.jinemi.com/jinemi/thermograph/{backend,frontend}:sha-53e2eb7c842f`; `beta.thermograph.org/healthz` returns 200 and `/api/version` reports `backend_version=2, payload_ver=p2` — identical to prod's current values, as expected for a change that touches deploy config and docs but no application code. - **Dev has been running the same commit's images since before the promotion**, also healthy. ## Prod-specific risk check Beta and prod are co-resident on vps2, so beta's successful roll exercised the exact host, `/etc/hosts` pins, mesh route and `REGISTRY_TOKEN` path prod will use. Specifically verified on vps2: - both `dev.jinemi.com` and `git.thermograph.org` pinned to `10.10.0.2`; - `dev.jinemi.com/v2/` returns **401** (reachable, auth required) via the mesh, not 403; - `REGISTRY_TOKEN` present in `/etc/thermograph.env` (prod's own file), and `deploy.sh` sources it before the `docker login`, so prod's missing `dev.jinemi.com` credential is recreated on the way through — the same sequence that just worked for beta; - every service in `thermograph-stack.yml` is constrained to `node.role == manager`, so no pull can land on an unpinned worker. Rollback stays available: both names address the same Forgejo and the same packages, so previously pushed `git.thermograph.org/...` tags remain pullable.
emi added 3 commits 2026-08-01 23:27:59 +00:00
make: add root install/up/down for the local stack
All checks were successful
secrets-guard / encrypted (pull_request) Successful in 5s
Details
shell-lint / shellcheck (pull_request) Successful in 7s
Details
PR build (required check) / changes (pull_request) Successful in 19s
Details
PR build (required check) / build-backend (pull_request) Has been skipped
Details
PR build (required check) / build-frontend (pull_request) Has been skipped
Details
PR build (required check) / validate-observability (pull_request) Has been skipped
Details
PR build (required check) / gate (pull_request) Successful in 1s
Details
Sync infra to hosts / sync-beta (push) Has been skipped
Details
Sync infra to hosts / sync-prod (push) Has been skipped
Details
Sync infra to hosts / sync-centralis (push) Has been skipped
Details
secrets-guard / encrypted (push) Successful in 6s
Details
Sync infra to hosts / sync-dev (push) Successful in 12s
Details
shell-lint / shellcheck (push) Successful in 8s
Details
4dcd6775c4 
A fresh checkout had no working path to the stack locally. Neither compose
file carries a `build:` for backend or frontend -- each ships as its own
registry image -- so with no image present `make dev-up` fell through to
pulling the `:local` tag, which nothing publishes, and failed with 403
against a registry a laptop has no login for.

`install` builds both images from backend/Dockerfile and frontend/Dockerfile
under exactly the tag the compose files default to; `up` verifies they exist
and says what to run instead of retrying the pull. Image names are read back
from `docker compose config --images` rather than restated here, so an org
rename cannot leave this file building a tag nothing runs.

infra's dev-up/dev-down now set COMPOSE_PROJECT_NAME=thermograph-dev, which
matches deploy/deploy-dev.sh and what the root CLAUDE.md already described;
a local run previously landed in the prod-shaped `thermograph` project. Drop
dev-up's `--build`, a no-op since the Dockerfiles moved out of infra, and
correct the comment claiming a 0.0.0.0 default -- the overlay has published
on loopback since dev moved to a public VPS.
registry: move the registry host to dev.jinemi.com, MCP to mcp.jinemi.com
All checks were successful
Sync infra to hosts / sync-beta (push) Has been skipped
Details
Sync infra to hosts / sync-prod (push) Has been skipped
Details
Sync infra to hosts / sync-centralis (push) Has been skipped
Details
Sync infra to hosts / sync-dev (push) Successful in 9s
Details
secrets-guard / encrypted (push) Successful in 5s
Details
Validate observability stack / validate (push) Successful in 12s
Details
shell-lint / shellcheck (push) Successful in 8s
Details
Build + push images (Forgejo registry) / build-push (frontend) (push) Successful in 26s
Details
Build + push images (Forgejo registry) / build-push (backend) (push) Successful in 1m10s
Details
Deploy / deploy (backend) (push) Successful in 1m41s
Details
Deploy / deploy (frontend) (push) Successful in 1m48s
Details
secrets-guard / encrypted (pull_request) Successful in 8s
Details
shell-lint / shellcheck (pull_request) Successful in 9s
Details
PR build (required check) / changes (pull_request) Successful in 20s
Details
PR build (required check) / validate-observability (pull_request) Successful in 15s
Details
PR build (required check) / build-frontend (pull_request) Successful in 17s
Details
PR build (required check) / build-backend (pull_request) Successful in 2m26s
Details
PR build (required check) / gate (pull_request) Successful in 1s
Details
53e2eb7c84 
Completes the Forgejo domain migration. ROOT_URL moved to dev.jinemi.com
earlier; the registry half was deliberately deferred. Every image name,
REGISTRY_HOST default, runner label and --add-host pin now names
dev.jinemi.com, so the registry host and the bearer-token realm agree again.

Both names address the same Forgejo, so no image needs re-pushing and a
rollback to a tag pushed under the old prefix still resolves.
git.thermograph.org therefore stays served off the same Caddy site block --
one block, so the /v2/* mesh-only matcher keeps covering both names -- for
pre-migration tags and for runners holding it as their registered instance
URL.

Mesh clients now pin both names in /etc/hosts: the new one as registry host
and token realm, the old one for pre-migration tags. runner-vps2/config.yaml
carries both --add-host entries for the same reason.

Also renames Centralis' endpoint to mcp.jinemi.com in the two places this
repo names it; Centralis itself is provisioned outside this repo.

Host-side steps this cannot do (documented in deploy/forgejo/README.md,
"Host-side steps"): the Forgejo Actions variable REGISTRY_HOST, docker login
against the new host, and the /etc/hosts pins.
Merge pull request 'promote dev -> main: registry host migration to dev.jinemi.com' (#162) from dev into main
Some checks failed
Sync infra to hosts / sync-dev (push) Has been skipped
Details
Sync infra to hosts / sync-centralis (push) Failing after 6s
Details
Sync infra to hosts / sync-beta (push) Successful in 10s
Details
secrets-guard / encrypted (push) Successful in 12s
Details
Validate observability stack / validate (push) Successful in 15s
Details
Sync infra to hosts / sync-prod (push) Successful in 10s
Details
Build + push images (Forgejo registry) / build-push (frontend) (push) Successful in 39s
Details
Build + push images (Forgejo registry) / build-push (backend) (push) Successful in 42s
Details
shell-lint / shellcheck (push) Successful in 12s
Details
Deploy / deploy (frontend) (push) Successful in 40s
Details
Deploy / deploy (backend) (push) Successful in 1m56s
Details
secrets-guard / encrypted (pull_request) Successful in 8s
Details
shell-lint / shellcheck (pull_request) Successful in 10s
Details
0eb4f63895
emi merged commit e9e9512155 into release 2026-08-01 23:28:37 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
  
Compat/Breaking

Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Jinemi/thermograph#163
No description provided.
Delete branch "main"

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?