bytelyst/learning_ai_common_plat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(docs): record local FlowMonk Docker workaround

Browse Source
This commit is contained in:
saravanakumardb1 2026-03-23 19:09:04 -07:00
parent 2296d98bf6
commit 6f748b11d4
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md
View File

@ -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

2
docs/devops/SINGLE_VM_DEPLOYMENT.md
View File

@ -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