mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-04 22:15:07 +03:00
b7c07edad8
* fix(ci): run the install-upgrade gate on disk, not on the /tmp tmpfs The v3.8.50 publish failed this gate again, and this time it said why: free space in /tmp: 2.9 GB ⚠️ only 2.9 GB free — this gate needs roughly 12 GB crashed: upgrade install ran out of disk space (58269 ENOSPC errors) On the self-hosted runner `/tmp` is a **12 GB tmpfs backed by RAM**, while the root filesystem had 66 GB free. The gate builds two ~3 GB install trees, installs the second one over twice, and packs a 275 MB tarball — roughly 12 GB, all of it demanded from the wrong filesystem. This is why freeing disk never fixed it: 84 GB were freed on `/`, and none of it ever reached the volume the gate was using. The check even measured the right number and reported it against the wrong path, so the warning read as "the disk is full" when the disk was fine. - work in `<repo>/.install-upgrade/` (gitignored) instead of `os.tmpdir()`, overridable with `OMNIROUTE_INSTALL_UPGRADE_WORKDIR` - the free-space log and the ENOSPC crash message now name the directory the run actually uses, so the next reader is sent to the filesystem that ran out Phase A already passes on the current main: clean install healthy, version reported correctly, 130 tables — the authentication fix and migration 163 from #11845 both hold. Only Phase B was starved. * docs(env): document OMNIROUTE_INSTALL_UPGRADE_WORKDIR The workdir override introduced in this branch is a new `process.env.*` read, and two gates caught it immediately: `issue #7793: real .env.example is in sync with process.env.* reads in code` and `check:env-doc-sync` (Docs Sync STRICT). Both were right — an env var that exists only in code is an env var nobody can find. Documented in `.env.example` and `docs/reference/ENVIRONMENT.md` with the reason it exists: the gate needs ~12 GB and must not land on a small tmpfs.