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 - host-side registry usage is validated
- FlowMonk host-side pilot migration 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. 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 - 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 - 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` - 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 - 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 - 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 ### 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 Mac rehearsal gaps still open
- local Homebrew Gitea package metadata and tarball URLs are not yet reliable across both host installs and Docker builds - 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 - 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 - the pilot registry migration is only validated for FlowMonk backend/web host-side usage, not end-to-end across Docker and all surfaces