From 6f748b11d414be02374a2f735fdd9c92909ec09d Mon Sep 17 00:00:00 2001 From: saravanakumardb1 Date: Mon, 23 Mar 2026 19:09:04 -0700 Subject: [PATCH] fix(docs): record local FlowMonk Docker workaround --- docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md | 6 +++--- docs/devops/SINGLE_VM_DEPLOYMENT.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md b/docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md index 59caf715..f27d18df 100644 --- a/docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md +++ b/docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md @@ -176,7 +176,7 @@ At the time of writing: - host-side registry usage is validated - FlowMonk host-side pilot migration is validated -- Docker-side local-registry validation is still blocked after auth succeeds because embedded tarball URLs still resolve to `localhost:3300` inside the build container +- FlowMonk backend/web Docker builds are validated locally with a real token plus `--add-host localhost:host-gateway`, but the default advertised tarball URL shape is still not clean enough to call this solved generically That blocker must be resolved before we can claim full local E2E completion. @@ -191,9 +191,9 @@ The local rehearsal on this Mac has proven enough to validate the **host-side** - Docker / BuildKit package installs from the local Homebrew Gitea instance are still not green - the Homebrew Gitea `ROOT_URL` / package tarball URL behavior is still fragile across host and Docker boundaries - Docker-side package installs currently need a real Gitea package token even though host-side installs only need non-empty `GITEA_NPM_TOKEN` env resolution for `.npmrc` -- even with a real token, the current FlowMonk backend Docker build still fails once package metadata redirects tarball fetches to `http://localhost:3300/...` inside the container +- FlowMonk backend/web Docker builds now work locally with `host.docker.internal` plus `--add-host localhost:host-gateway`, but that host-specific workaround should not yet be treated as the final VM-ready/default solution - local Gitea Actions has not yet been validated end-to-end for the package build → publish → consumer flow -- the FlowMonk pilot is currently validated only for backend/web host-side consumption; Docker is still blocked and mobile remains outside the registry-backed pilot slice +- the FlowMonk pilot is now validated for backend/web host-side consumption plus local Docker builds with the documented workaround; mobile remains outside the registry-backed pilot slice - not all `@bytelyst/*` packages have been revalidated under the local Gitea registry with a fresh consumer install after the `pnpm pack` publish flow changes ### Why this matters for Azure diff --git a/docs/devops/SINGLE_VM_DEPLOYMENT.md b/docs/devops/SINGLE_VM_DEPLOYMENT.md index edfed805..57088618 100644 --- a/docs/devops/SINGLE_VM_DEPLOYMENT.md +++ b/docs/devops/SINGLE_VM_DEPLOYMENT.md @@ -717,7 +717,7 @@ The remaining work is concentrated more in the **build and package-distribution ### Local Mac rehearsal gaps still open - local Homebrew Gitea package metadata and tarball URLs are not yet reliable across both host installs and Docker builds -- pilot Docker builds from the local Gitea registry are still blocked +- FlowMonk backend/web Docker builds are now green locally only when using a real Gitea package token plus `--add-host localhost:host-gateway`; that workaround is not yet the final default/VM-ready shape - local Gitea Actions has not yet been fully validated for the package publish + consumer install path - the pilot registry migration is only validated for FlowMonk backend/web host-side usage, not end-to-end across Docker and all surfaces