mirror of
https://github.com/ether/etherpad-lite.git
synced 2026-07-18 00:57:55 +00:00
b19ad89eb0
* fix(docker): don't let pnpm self-provision a pinned version on offline boot (#7911) The official Docker image installs pnpm directly via npm (corepack was dropped for Node 25+). Standalone pnpm still honours the "packageManager" pin in package.json: the image's pnpm intentionally lags that pin (pnpm 11.1.x enforces a minimum-release-age policy the frozen-lockfile build can't satisfy), so pnpm treats every invocation — including the informational `pnpm --version` probe Etherpad runs at startup — as a request to download and run the pinned build. Behind a corporate firewall / in an air-gapped install that download fails: [WARN] plugins - Failed to get pnpm version: Error: Command exited with code 1: pnpm --version which is what #7911 reported. Fix — neutralise the gap instead of closing it (closing it would break the frozen-lockfile build on 11.1.x): - Dockerfile build stage sets `pnpm_config_pm_on_fail=ignore` (the pnpm 11 successor to managePackageManagerVersions), inherited by the development and production runtime stages. pnpm then uses the installed pnpm instead of fetching the pinned one. It does not change which pnpm runs the build-time install, so the frozen-lockfile build is unaffected. - plugins.ts startup probe and the updater's pnpm-on-PATH checks run with the same flag, so the fix also covers non-Docker offline installs and the probe can never fail-loud. Add a backend spec that fails CI if the offline guard is dropped while the image pnpm differs from the package.json pin. Verified with a standalone (non-corepack) pnpm: a "packageManager" mismatch makes `pnpm --version` exit 1 by default (tries to fetch the pinned build), and exit 0 reading the local version with pm_on_fail=ignore. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: scope pnpm offline-guard check to the runtime-inherited build stage Address Qodo review: the regression spec matched ENV pnpm_config_pm_on_fail anywhere in the Dockerfile, so it would still pass if the guard were removed from the `build` stage (which the runtime stages inherit) but left in the throwaway `adminbuild` stage — reintroducing the offline failure. Extract the `build` stage block and assert the ENV is present there specifically. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| db | ||
| eejs | ||
| handler | ||
| hooks | ||
| security | ||
| types | ||
| updater | ||
| utils | ||
| metrics.ts | ||
| padaccess.ts | ||
| prom-instruments.ts | ||
| prometheus.ts | ||
| README.md | ||
| server.ts | ||
| stats.ts | ||
About the folder structure
- db - all modules that are accessing the data structure and are communicating directly to the database
- handler - all modules that respond directly to requests/messages of the browser
- utils - helper modules
Module name conventions
Module file names start with a capital letter and uses camelCase
Where does it start?
server.ts is started directly