OmniRoute

pjandro/OmniRoute

Fork 0

mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-08-28 10:02:49 +03:00

Author	SHA1	Message	Date
Diego Rodrigues de Sa e Souza	b7c07edad8	fix(ci): run the install-upgrade gate on disk, not on the /tmp tmpfs (#11855 ) * 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.	2026-08-28 00:18:02 -03:00

Author

SHA1

Message

Date

Diego Rodrigues de Sa e Souza

b7c07edad8

fix(ci): run the install-upgrade gate on disk, not on the /tmp tmpfs (#11855 )

* 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.

2026-08-28 00:18:02 -03:00

Compare commits

1 Commits

fix/instal ... main

Diff Content Not Available

Compare commits

1 Commits fix/instal ... main

Diff Content Not Available

1 Commits

fix/instal ... main