mirror of
https://github.com/ether/etherpad-lite.git
synced 2026-07-17 16:47:05 +00:00
322 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
dependabot[bot]
|
acba429e1a
|
build(deps): bump actions/checkout from 6 to 7 (#7977)
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v6...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
John McLear
|
32249d99e2
|
fix(ci): reap whole server tree in installer smoke test so it can't hang 6h (#7981)
The "Installer test" workflow has hung for 6 hours (until GitHub's job
ceiling cancels it) on every ubuntu/macos run since v3.2.0. The smoke
test starts `pnpm run prod` in the background, confirms /api responds,
then tears it down with:
kill "$PID"
wait "$PID"
`pnpm run prod` is a nested launcher (pnpm -> pnpm --filter -> node), so
$PID is only the outer pnpm. SIGTERM is forwarded down the chain and the
script then `wait`s on it, but if the node server doesn't exit (e.g. a
live flush timer keeping the event loop alive) the wait blocks forever
and the step never releases its output pipe -> 6h hang. Windows passed
because it uses `Stop-Process -Force`.
Fix the teardown to be robust regardless of server shutdown behaviour:
- `set -m` so the launcher gets its own process group
- kill the whole group (SIGTERM, then SIGKILL fallback) via a trap
- drop the blocking `wait`
- add `timeout-minutes: 8` to both smoke steps as a hard backstop so a
future hang fails in minutes, not 6 hours
This unblocks CI on PRs that touch the installer workflow. The
underlying clean-shutdown regression (server not exiting on SIGTERM,
likely the ueberDB flush-timer setInterval) is tracked separately.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
a698e34772
|
chore(release): park the non-functional ep_etherpad npm publish (#7922)
The releaseEtherpad workflow renames ep_etherpad-lite -> ep_etherpad and publishes ./src to npm, but that publish is not load-bearing: - `ep_etherpad` has 0 dependents on npm; nothing in this repo depends on it. - Plugins import `ep_etherpad-lite` resolved from the LOCAL core install, and plugin CI clones `ether/etherpad` rather than `npm install`-ing core. - Etherpad is run via git clone / Docker / zip / snap, never `npm install`. It has been failing with E404 (the ep_etherpad package has no OIDC trusted publisher configured on npmjs.com), which is why npm is stuck at 2.5.0 while 3.0/3.1/3.2/3.3 shipped fine without it. Rather than chase a trusted-publisher setup for a publish nobody consumes, park the workflow: gate the job behind an explicit `confirm: true` dispatch input so a stray run fails fast with a clear message instead of a confusing 404, and document the status in the header + the AGENTS.MD Releasing section. This is the package owner's (samtv12345) call: either finish the trusted- publisher config to revive it, or remove the workflow. Parked pending that decision; nothing about the release depends on it. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
a59b310dbf
|
deps: pin ueberdb2 to 6.1.9 (fixes standalone-server startup exit) + run deb smoke on PRs (#7969)
ueberdb2 6.1.10 rewrote the cache/buffer layer (CacheAndBufferLayer.ts), replacing the constructor's always-on, *referenced* `setInterval` flush timer with a lazily-armed `setTimeout` that is `.unref()`'d and only created when there are dirty keys. On a fresh, empty dirty DB there are no dirty keys, so no flush timer is ever armed and ueberdb2 no longer anchors Node's event loop. In the packaged (.deb/systemd) production boot this exposes a startup window where the loop has no referenced handle and the process exits cleanly (code 0) before `server.listen()` binds the port — so the server never serves /health. Symptom on develop: the Debian-package amd64 smoke test failed on three consecutive pushes (#7966 ueberdb2 6.1.9->6.1.12, then #7965, #7967), with the service logging the version banner then "Deactivated successfully" and the health check on :9001 never connecting. Backend/Docker/downstream-smoke stayed green because they keep the loop alive by other means; only the bare fresh-empty-dirty-DB packaged boot hits the gap. ueberdb2 6.1.12 is the latest published release, so there is no fixed version to roll forward to yet — pin back to the last green release (6.1.9) on both src/ and bin/. Also add a `pull_request` trigger to the Debian-package workflow (scoped to the same production-footprint paths). The smoke step is the only check that catches this "boots then exits before binding" class of regression, but it previously ran only on push to develop — i.e. *after* merge — which is exactly why the Dependabot bump turned develop red instead of being blocked at PR time. The release/apt-publish jobs are tag-guarded, so PRs run the build+smoke job only. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
dependabot[bot]
|
8a4e1feed8
|
build(deps): bump awalsh128/cache-apt-pkgs-action from 1.6.0 to 1.6.1 (#7963)
Bumps [awalsh128/cache-apt-pkgs-action](https://github.com/awalsh128/cache-apt-pkgs-action) from 1.6.0 to 1.6.1. - [Release notes](https://github.com/awalsh128/cache-apt-pkgs-action/releases) - [Commits](https://github.com/awalsh128/cache-apt-pkgs-action/compare/v1.6.0...v1.6.1) --- updated-dependencies: - dependency-name: awalsh128/cache-apt-pkgs-action dependency-version: 1.6.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
Stefan Müller
|
68d322957f
|
feat: Add test step to check etherpad works offline (#7936) | ||
|
John McLear
|
e56a33efd0
|
ci(downstream): enable pad/cli/desktop smoke clients (Phase 2) (#7924)
Implements the per-kind orchestration (clone @ pinned ref, inject core's freshly-generated wire-vectors fixture via ETHERPAD_WIRE_VECTORS, run each client's vectorTest + smokeCmd against the booted server) in a testable run-clients.sh, and flips the three manifest entries to enabled, pinned to the commits that carry their Phase 2 tests: ether/pad#1, ether/etherpad-cli-client#136, ether/etherpad-desktop#78. Validated end-to-end locally against a real core: all three clients' vectors + live smoke pass. Refs should be bumped to the squash-merge commits once those client PRs land. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
860ab68c04
|
test: downstream client compatibility gate (Phase 1) (#7923)
* docs: design for downstream client compatibility tests Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs: Phase 1 implementation plan for downstream compat tests Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): add golden wire-vector generator Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): add committed golden wire-vectors fixture Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): assert wire-vectors fixture stability + consistency Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): pin socket.io handshake + USER_CHANGES sequence Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): snapshot client-facing HTTP API shapes Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(downstream): add client manifest (entries disabled pending Phase 2) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(downstream): add downstream-smoke workflow (boot/self-check/teardown + manifest scaffold) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(downstream): validate settings rewrite + ignore docs/** (Qodo) Fail fast if the template's port/auth literals drift so a no-op sed can't silently boot the smoke server on the wrong port/auth. Also ignore docs/** (not just doc/**) so docs-only PRs don't trigger the boot job. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
d3074e3707
|
test(ci): remove the silent-ELIFECYCLE flake investigation scaffolding (#7868)
* test(ci): remove the silent-ELIFECYCLE investigation scaffolding The Windows backend flake is root-caused (server.ts handler gate for the in-process process.exit path; Windows pinned to Node 24.16.0 for the libuv TCP-connect overrun, tracked upstream as nodejs/node#63620). Remove the temporary diagnostics added while hunting it: - delete src/tests/backend/diagnostics.ts (per-test heartbeat + node-report snapshots) and its `--require` from the backend `test` script; - drop the `--report-on-fatalerror`/`-on-signal`/`-uncaught-exception` `NODE_OPTIONS` and the "Upload Node diagnostic reports" steps; - drop the Windows OS-level netstat/tasklist sidecar watcher. Kept: the real fixes — the log-only unhandledRejection guard in tests/backend/common.ts, the lowerCasePadIds socket-teardown tracking (comment de-referenced from the deleted file), and `pnpm test -- --exit` on Windows. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test: drop the obsolete report-on-fatalerror NODE_OPTIONS guard assertion The backend-tests-flake-mitigation source-lint guard required every backend step to keep the --report-on-fatalerror NODE_OPTIONS + node-report upload. Those diagnostics are removed in this PR now that the flake is root-caused, so drop that assertion. Retain the Windows-only `--exit` checks (still a live invariant) and reframe the file around the resolved root cause. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
d582398826
|
fix: eliminate the Windows backend silent-ELIFECYCLE flake (handler gate + Node 24.16.0) (#7866)
* fix(test): stop a single leaked promise rejection from killing the whole backend suite
Root cause of the long-standing Windows backend-test "silent ELIFECYCLE"
flake (~22% of runs, rotating across random spec files, no mocha summary,
no JS-handler trace, bypassing --report-on-fatalerror / Defender / Windows
event log / AeDebug). Found by capturing a full-memory dump of the dying
node.exe with Sysinternals ProcDump (-t dump-on-terminate) and symbolizing
it against Node 24.15.0's node.pdb. The dying thread's stack:
exit_or_terminate_process / common_exit (CRT exit)
node::Exit
node::DefaultProcessExitHandlerInternal
node::Environment::Exit
node::ReallyExit (process.exit binding)
... v8 MicrotaskQueue::RunMicrotasks ...
node::InternalCallbackScope::Close
No exception stream — a *clean* ExitProcess, not a crash. The job log
pinned the trigger:
[INFO] server - Exiting...
AssertionError at tests/backend/specs/SessionStore.ts:235
at process.processTicksAndRejections
Mechanism: a timing-fragile test (SessionStore touch/expiry specs use real
setTimeout against a 200ms-expiry session; socket.io delay-race specs are
similar) gets timed out and abandoned by mocha, but its async body keeps
running. When its trailing assertion later throws, it surfaces as an ORPHAN
unhandled rejection belonging to no awaited test. Three handlers then
escalated that into a whole-process exit:
- server.ts installed process-global uncaughtException/unhandledRejection
handlers that call exports.exit() → process.reallyExit() (production
graceful-shutdown behaviour, catastrophic in-process under mocha)
- common.ts (PR #7663) and diagnostics.ts (PR #7838) rethrew the rejection
and process.exit(1)
Because it's a deliberate, clean exit it bypassed every forensic layer; it
rotated across files because the orphan rejection lands during whatever test
is running; it's Windows-mostly because event-loop timing makes the abandoned
test's assertion fire in a *later* test's window more often there.
Fix (two halves):
1. server.ts: gate the process-global uncaughtException / unhandledRejection
/ signal handlers behind `require.main === module`. They are correct for
a real Etherpad process but must not fire when server.start() is called
in-process by a test runner — mocha owns process-level error handling
there. Mirrors the existing `if (require.main === module) exports.start()`
idiom; production (node server.js) is unchanged.
2. common.ts + diagnostics.ts: the backend-test bootstraps now LOG unhandled
rejections instead of rethrowing / exiting. Orphan rejections cannot be
cleanly attributed to a test, so rethrowing only yields an
ERR_MOCHA_MULTIPLE_DONE abort. Real failures are unaffected — an assertion
in a test's own awaited path rejects that test's promise and mocha fails
it normally, never reaching this global handler.
Verified locally: a spec that leaks a delayed rejection during a later test
now reports `3 passing` / exit 0 with the rejection logged, instead of
aborting the run.
Follow-ups (separate PRs): harden the SessionStore / socket.io timing specs
to not leak (fake timers); remove the now-unneeded diagnostic scaffolding
(diagnostics.ts heartbeat/node-report, the #7846 OS sidecar) now that the
cause is known.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(ci): run Windows backend tests on Node 25 to dodge the libuv connect overrun
Node 24.x's bundled libuv has a stack buffer overrun in the Windows TCP-connect
path (uv__tcp_connect / uv__tcp_try_connect), proven by a SilentProcessExit
full-memory dump of the dying mocha process: the main thread executes
__fastfail(FAST_FAIL_STACK_COOKIE_CHECK_FAILURE) from __report_gsfailure with
TCPWrap::Connect -> uv_tcp_connect on the stack. It fires under the backend
suite's heavy localhost connection churn, is address-family independent (occurs
on both sockaddr_in and sockaddr_in6, so an IPv4 pin does NOT help), and -- being
memory corruption -- bypasses all JS/Node observability, rotating across tests
as the "silent ELIFECYCLE" flake (~22% of Windows runs).
Empirically: Node 25 = 16/16 green; Node 24 (even with an IPv4 pin) = ~39% fail.
Node 25's newer bundled libuv does not overrun. Linux stays on Node 24 LTS (the
bug is Windows-specific). Revisit once the libuv fix is backported to 24.x.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(ci): pin Windows backend to Node 24.16.0 (libuv fix) instead of 25
Bisect (standalone repro) pinpointed the fix to Node 24.16.0 (libuv 1.52.1):
24.15.0 (libuv 1.51.0) crashes the connect overrun 4/4 on 127.0.0.1, while
24.16.0 is clean 0/8. 24.16.0 stays on the Node 24 "Krypton" LTS line, so prefer
it over Node 25 (non-LTS). Pinned explicitly because setup-node's default
check-latest:false reuses the runner's pre-cached 24.15.0 for a bare "24".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(ci): reference upstream nodejs/node#63620 in the Windows Node-pin comment
Links the explicit 24.16.0 pin to the filed upstream issue so the pin can be
dropped back to plain "24" once the libuv connect-overrun fix is across the
supported 24.x baseline.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
c4d2467cb3
|
test(ci): OS-level sidecar watcher for the Windows silent ELIFECYCLE (#7846)
In-process diagnostics (diagnostics.ts heartbeat at 5 Hz + node-report snapshots on every beforeEach and heartbeat tick) merged in #7838 and #7842 reach a hard ceiling: during every captured death window the V8 main isolate is event-loop-starved for 200-400 ms before the process is externally terminated, so any timer-driven probe (heartbeat, setTimeout, --report-on-signal handler) never gets serviced and we have zero JS-visible state from the actual moment of death. To capture state during the starvation window we need a probe whose own scheduling does not depend on the dying process's libuv event loop. This commit adds a tiny bash background loop to the Windows backend-test steps (both with- and without-plugins). Every 500 ms it appends: - netstat.log: localhost TCP socket state — surfaces TIME_WAIT / CLOSE_WAIT accumulation or ephemeral-port exhaustion that the in-process libuv handle list can't see (libuv only shows handles Node currently knows about; the kernel may hold many more sockets in disposal states). - tasklist.log: node.exe process state from the Windows OS view (handle count, working set, CPU time), independent of whether V8 is responsive. Both files land in $GITHUB_WORKSPACE/node-report/ which is already the artifact-upload target on failure, so they ride for free on existing infrastructure. The watcher is killed cleanly after `pnpm test` returns so it never holds the runner open. On the next captured silent ELIFECYCLE we'll have, for the first time, a 500 ms-resolution external observation of TCP and process state across the death window. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
abda0485d3
|
test(docker): admin save persists across container restart (#7819) (#7821)
* test(docker): admin save persists across container restart (#7819) The OP reports the symptom on the official Docker image specifically. Adds two layers of coverage to docker.yml's build-test job, driven from inside a container started against the same TEST_TAG the existing test-container step uses: 1. New mocha spec adminSettings_7819.ts under tests/container/specs/api — authenticates against /admin, opens the /settings socket, saves an augmented JSON with an ep_oauth-shaped top-level block, and asserts the next load reply contains the marker. Intentionally leaves the marker on disk so the workflow can inspect it. 2. docker.yml now `docker exec test grep`s for the marker after test-container, then `docker restart`s the container, waits for the health probe, and re-greps. Both checks must pass — the first proves the socket-driven save actually touched the file inside the container layer; the second proves an in-place restart doesn't reset it. A recreate (docker rm + docker run) would wipe the file, but that's expected (image layer) and out of scope. Container is started with `-e ADMIN_PASSWORD=changeme1` so the existing settings.json.docker provisions the admin user; pad.js doesn't touch /admin so the existing API specs are unaffected. test-container timeout bumped 5s → 30s to cover socket connect + save round-trip, and the mocha discovery extension list now includes `ts` so the new spec is picked up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(docker): authenticate via /admin-auth/ POST, surface auth/load failures fast (#7819) CI failed on #7821 with a generic 20s mocha timeout because the spec hit GET /admin/ to grab a session cookie. webaccess.ts only treats paths starting with /admin-auth as requireAdmin — and the container runs with REQUIRE_AUTHENTICATION=false (default), so GET /admin/ never issued a Basic challenge and Set-Cookie was empty. The socket then connected unauthenticated, adminsettings.ts's connection handler returned early without binding any listeners, and the load() promise hung until mocha killed the test with no useful diagnostic. Switch to POST /admin-auth/ (always-requireAdmin, regardless of settings.requireAuthentication). Assert a 2xx with at least one Set-Cookie before proceeding. Add an 8s timeout + meaningful error message to load() so the "session was not admin" failure mode reports immediately instead of burning the suite budget. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(docker): replace splice with hand-built payload (#7819) Last CI failed because the splice-after-last-} approach landed a comma between an existing trailing-comma-before-comment and the close brace of settings.json.docker, producing `, /* … */, "ep_oauth"` — invalid JSON. settings.json.docker uses jsonc `/* */` and `//` comments and a trailing-comma-before-comment-before-close shape that's annoying to patch from the test side, and the existing isJSONClean has zero backend coverage so the splice is going through Etherpad's lenient write path anyway. Switch to a hand-built minimal-but-viable settings document containing the ep_oauth block. Three properties hold: - We're testing the WRITE path, not the synthesis path. Whatever bytes we send, the next `load` must return verbatim. - The post-save document must survive `docker restart` (the next step in docker.yml) — minimal-but-viable means port/users/dbType are present so Etherpad boots back up and HEALTHCHECK passes. - The next `load` reply must equal the bytes we saved (`reply.results === augmented`) — stronger than `.includes()`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
49111f2fc9
|
Enhance bug report template with abstraction question
Added a question about using abstraction like Docker in the bug report template. |
||
|
John McLear
|
271eb6ab5c
|
ci: swap deprecated ep_readonly_guest for ep_guest in plugin matrix (#7808)
ep_readonly_guest is archived (read-only on GitHub) and its authenticate hook unconditionally swaps req.session.user with a read-only guest, even when the request carries an HTTP Authorization header. That silently demoted admin login attempts and stalled the anonymizeAuthorSocket tests for 14 min/run on every with-plugins CI matrix (#7795). The pre-fix theory blamed ep_hash_auth.handleMessage; the actual hook trace is a red herring — handleMessage only fires on the /pad namespace and never on /settings. ep_guest is the maintained successor (same authors, same purpose). 1.0.72 on npm already includes the "defer to basic auth / admin paths" fix backported to ep_readonly_guest by intent here. Swapping the matrix unblocks the anonymizeAuthorSocket suite on Linux, Windows, and the upgrade-from-latest-release workflow. The runtime probe added in #7796 stays — it still catches any other authenticate-hook plugin that rejects the test's plain-text credentials (e.g. a future ep_hash_auth-style hashed-only plugin). Reattribute its comment so future readers don't chase ep_hash_auth. Closes #7795. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
04045fe532
|
Roll Node.js floor back to >= 24 (Active LTS) — closes #7779 (#7781)
* Roll Node.js floor back to >= 24 (Active LTS) Closes #7779. #7779 originally proposed bumping past the Node 25 stop-gap to Node 26. After re-checking the release schedule, the cleaner LTS target is actually Node 24: - Node 24 (Krypton) is currently in Active LTS, supported until ~May 2028. - Node 25 hit end-of-life on April 10 2026 — the floor merged in #7752 / #7749 / #7754 a day ago ships an already-EOL major. - Node 26 was released May 5 2026 and does not enter Active LTS until October 2026. So this PR reverts the Node 25 ratchet from those three PRs and lands on Node 24 — Etherpad's runtime floor stays on a supported LTS for the next ~2 years. Runtime / infra - `package.json` + `src/package.json`: `engines.node` `>=25.0.0` -> `>=24.0.0` - `bin/functions.sh`, `bin/installer.sh`, `bin/installer.ps1`: `REQUIRED_NODE_MAJOR` 25 -> 24 - `Dockerfile`: `node:25-alpine` -> `node:24-alpine` (both stages). Corepack-via-npm workaround is intentionally kept: it works on Node 24 (which still ships corepack) and on Node 25+ (which doesn't), so the same recipe survives the next LTS bump without churn. Comments reworded accordingly. - `snap/snapcraft.yaml`: pinned `NODE_VERSION` 25.9.0 -> 24.15.0; design notes + corepack comment adjusted - `packaging/nfpm.yaml`: `nodejs (>= 25)` -> `nodejs (>= 24)` in top-level depends + deb/rpm overrides - `packaging/bin/etherpad`: comment matches the new pin - `packaging/README.md`: build prereqs + apt install snippet point at `node_24.x`; the long-stale "engines.node floor is 20" line is fixed while we're here - `.github/workflows/*.yml`: setup-node `node-version` 25 -> 24 across every workflow; backend / frontend-admin / upgrade matrices `[25]` -> `[24]` - `.github/workflows/deb-package.yml`: `NODE_MAJOR=25` + `node_25.x` smoke-test installer -> 24 - `bin/plugins/lib/npmpublish.yml`: 25 -> 24 (template propagates to the ~80 ether/* plugins via update-plugins workflow) Docs - `README.md`: install one-liner + Requirements -> Node.js >= 24 - `doc/npm-trusted-publishing.md`: runner requirement -> Node 24 - `doc/plugins.md` / `doc/plugins.adoc`: plugin metadata example `engines.node` -> `">=24.0.0"` @types/node is left at ^25.8.0 — newer type definitions cover Node 24 runtime fine and avoid an unnecessary lockfile churn. Companion homepage one-liner change to follow on ether/ether.github.com. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(plugins): example engines.node = ">=22.0.0", not core's floor Plugin code is overwhelmingly ace-hook glue and rarely uses Node-version- specific APIs, so plugin engines.node should reflect the plugin's own requirements, not track core. Showing core's 24-floor in the example encouraged plugin authors to blindly copy a tighter pin than necessary and locked plugins out of being installable on older Etherpad/Node deployments. Use the most-recent Node LTS that has actually reached EOL (20 -> EOL April 2026) as the example floor, i.e. >=22. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
80c385e657
|
fix(deb): keep plugin_packages in-tree so admin-installed plugins can resolve ep_etherpad-lite (#7750)
* fix(deb): keep plugin_packages in-tree to fix admin-installed plugins
The .deb postinstall symlinked /opt/etherpad/src/plugin_packages to
/var/lib/etherpad/plugin_packages so the etherpad user could install
plugins under ProtectSystem=strict. Node.js resolves symlinks to their
realpath before walking node_modules, so a plugin installed via the
admin UI lived under /var/lib/etherpad/... and could no longer reach
the bundled ep_etherpad-lite in /opt/etherpad/node_modules. Every
require('ep_etherpad-lite/...') in installed plugins (and the matching
esbuild client-bundle build) failed with MODULE_NOT_FOUND, etherpad
exited, and the systemd unit restart-looped (ether/ep_comments_page#416).
Keep plugin_packages as a real in-tree directory, make it (and its
.versions/ subdir) group-writable by etherpad like node_modules already
is, and add it to ReadWritePaths= in the unit. Migrate the contents of
any pre-existing /var/lib/etherpad/plugin_packages symlink target back
in-tree on upgrade.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* ci(deb): update assertions for in-tree plugin_packages + cover migration
The previous assertions in packaging/test-local.sh and the deb-package
workflow checked that /opt/etherpad/src/plugin_packages was a symlink to
/var/lib/etherpad/plugin_packages -- the layout this PR is removing.
They would have failed under the new postinst.
- Assert plugin_packages is a real directory (not a symlink), owned by
group etherpad with mode 2775, matching node_modules.
- After the happy-path /health check, simulate a pre-fix install by
recreating the symlink with a marker plugin, re-run the postinst via
dpkg-reconfigure, and assert the marker payload was migrated back
in-tree and the symlink is gone. Locks in regression coverage for the
upgrade path (ether/ep_comments_page#416).
* ci(deb): add ep_layout_trip_wire fixture to gate plugin_packages layout
Layout assertions alone don't actually exercise the failure mode from
ether/ep_comments_page#416: they confirm /opt/etherpad/src/plugin_packages
is a real directory but never load a plugin whose index.js does
require('ep_etherpad-lite/...') from the on-disk realpath.
Ship a tiny test plugin under packaging/test-fixtures/ep_layout_trip_wire
that exercises the four require() patterns from the bug report (eejs,
Settings, log4js, pad_utils) and emits a marker line from
expressCreateServer. Both packaging/test-local.sh and the deb-package
workflow now stage it into plugin_packages/.versions/, wire up the
toplevel + node_modules symlinks live-plugin-manager would create,
list it in installed_plugins.json, restart etherpad, and assert:
* marker line appears in the journal (every require resolved), and
* no "Cannot find module 'ep_etherpad-lite" appears anywhere.
Verified locally that the fixture loads under the in-tree layout
(marker present) and fails under a symlinked-out-of-tree layout
(marker absent, MODULE_NOT_FOUND in the log) -- so the gate catches
the regression in both directions.
* fix(deb): clean up runtime plugin artifacts on purge
With plugin_packages now living under /opt/etherpad/src/plugin_packages,
admin-installed plugins land in dpkg-unmanaged paths (the .versions/
stage that live-plugin-manager populates plus matching ep_* symlinks
under src/node_modules/). dpkg --purge would leave them behind because
the manifest never recorded them.
In postremove's purge branch: explicitly rm -rf plugin_packages and any
runtime ep_* symlinks in node_modules, then rm -rf the whole APP_DIR
as belt-and-braces against other runtime drift. Verified in a sandbox
that a staged ep_runtime@1.0.0 + node_modules/ep_runtime symlink are
both gone after purge runs.
Add post-purge assertions to both packaging/test-local.sh and the
deb-package workflow: /opt/etherpad/src/plugin_packages and
/var/lib/etherpad must not exist after dpkg --purge.
Addresses Qodo PR #7750 review item 3 (\"Purge cleanup misses
plugins\", Reliability).
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
9bdbb3ee95
|
fix(deb): bump nodejs Depends to >= 25; install Node 25 in smoke test (#7754)
Followup to #7752. That PR raised `src/package.json` engines.node to
>=25.0.0 (matching the workspace root) but missed three places that
still encoded the previous Node 22+ floor — so the deb-package CI
broke at sha
|
||
|
John McLear
|
33b616b925
|
chore: align Node version pins with the Node 25+ floor (#7752)
The workspace root declares `engines.node: >=25.0.0` and
`engineStrict: true`, so anyone running Node 22 or 24 is hard-blocked
by pnpm at install time. Three places still referenced the old
floor and were testing / supporting a configuration no real user can
reach:
1. `.github/workflows/backend-tests.yml` Windows matrices (both
`withoutpluginsWindows` and `withpluginsWindows`) still had
`node: [22, 24, 25]`. The Linux jobs were already collapsed to
`[25]`; this collapses the Windows side to match. Drops 4
Windows CI cells per develop push (Node 22 × 2 + Node 24 × 2)
that were exercising an unsupported runtime.
2. `src/package.json` engines.node was `>=22.13.0`. Bumped to
`>=25.0.0` to match the workspace root. `pnpm` floor bumped
from `>=11.0.0` to `>=11.1.2` so the inner package agrees with
the root packageManager pin.
3. `.github/workflows/deb-package.yml` setup-node was pinned to
`node-version: '24'`. Every other setup-node call in the
workflows folder is already on 25; this brings the deb job in
line.
Side benefit: the Windows + Node 24 flake addressed in #7748 is now
moot for develop CI — Node 24 isn't tested at all. The `--exit`
mitigation and node-diagnostic-report capture remain in place on
Windows Node 25 as defence in depth in case the same native-crash
class shows up on a different Node line.
Verified locally:
- cd src && pnpm exec vitest run tests/backend-new/specs/backend-tests-flake-mitigation.test.ts
→ 3 passed (3). The mitigation test counts step blocks (4) and
Windows --exit invocations (2), not matrix dimensions, so the
contract is unchanged.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
7d537f3deb
|
Require Node.js >= 25 (engines, installers, Dockerfile, snap, CI, docs) (#7749)
* docs: bump documented Node.js minimum to 25 Etherpad is moving its supported Node.js floor to >= 25 (CI matrix is already pinned to 25 across all workflows on the node25-corepack-pnpm11 work). Sync the user-facing documentation so the install instructions, requirements section, and plugin metadata example all reflect the new minimum instead of Node 22 / 12.17. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: require Node.js >= 25 (engines, installers, Dockerfile, snap, CI) #7747 added Node 25 *support* but left the floor at Node 22. This commit completes the cutover so the runtime requirement matches the documentation bumped in the previous commit. - package.json: engines.node ">=22.13.0" → ">=25.0.0" - bin/functions.sh, bin/installer.sh, bin/installer.ps1: REQUIRED_NODE bumped to 25 (controls the error message users see when they invoke the installer or pnpm scripts on an older Node) - Dockerfile: base image node:22-alpine → node:25-alpine (×2). Corepack comment updated: Node 25 no longer ships corepack at all, so we install it from npm rather than refreshing a stale signing-key list - snap/snapcraft.yaml: pinned NODE_VERSION 22.22.2 → 25.9.0 and the surrounding design notes rewritten to reflect Node 25 instead of 22 - .github/workflows/*.yml: matrix dropped from [22, 24, 25] to just [25] (anything older now fails engines anyway). Stale comments in build-and-deploy-docs.yml referencing vite 8's 22.12 floor cleaned up - bin/plugins/lib/npmpublish.yml: setup-node 22 → 25 so the plugin template propagated to every ether/* plugin matches the new minimum Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(docker): install pnpm directly on Node 25 (no corepack) node:25-alpine doesn't ship corepack but does pre-install yarn at /usr/local/bin/yarn, so `npm install -g corepack@latest` fails with EEXIST trying to register its yarn shim. Per #7747, end-users install pnpm via plain `npm install -g pnpm` on Node 25 — use the same flow in the Dockerfile (and remove the unused yarn binary so it doesn't sit on PATH inside the image). Drops COREPACK_HOME and the related issue-7687 cache-sharing tweak since there's no corepack shim to share. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
99f8258811
|
Support Node 25 (#7747)
Bumps the workflow Node version (PR matrix → [25], full push matrix stays at [22, 24, 25]) and the pinned pnpm to 11.1.2 with a matching `engines.pnpm` minimum. End-users install pnpm the same way they always have (`npm install -g pnpm` works on Node 25 — only Corepack was dropped from the official Node 25 distribution). Also includes two workflow fixes that were entangled with the Node-version edits in the same files: - `upgrade-from-latest-release.yml` now actually checks out the latest release tag instead of `ref: develop #FIXME`, so the job finally exercises what its name implies. - `installer-test.yml` resolves `ETHERPAD_REPO` / `ETHERPAD_BRANCH` from the PR head when running on a fork, so the smoke test exercises the PR branch rather than the base. Verified end-to-end against `node:25-bookworm-slim` (no corepack): `npm install -g pnpm` → `pnpm i` → `pnpm run build:etherpad` → `pnpm run prod` boots and listens on 9001. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
8dbd917718
|
test(ci): kill Windows + Node 24 backend-test flake; capture native crashes (#7748)
* test(ci): kill Windows + Node 24 backend-test flake; capture native crashes The Backend tests suite has a ~22% silent-failure rate on Windows + Node 24 specifically (Linux 22/24/25 ✓, Windows 22/25 ✓). Two prior PRs instrumented the failure — common.ts handlers (#7663), then an unconditional diagnostics.ts (#7665) — and confirmed it's a hard kill: diagnostics.ts:23-27 documents the matrix, and every recurrence (run 25279692065, 25754938013, 25906496503) shows only `[diag +0ms] diagnostics loaded`, no beforeExit / exit / unhandledRejection / uncaughtException / signal handlers. Process dies 700–900 ms after the last passing test, in a varying spec each time. That's a native crash in V8 / libuv / the tsx loader, not anything reachable from JS. This PR ships two independent attacks at the failure: 1. Mitigation — add --exit to the mocha command in src/package.json. Mocha's default (--exit=false) waits for the event loop to drain after tests complete. The hard kill happens during that drain or the inter-spec transition. With --exit, mocha calls process.exit(failures) directly once the run finishes, closing the cleanup-race window. Linux/Windows-22/25 are green today, so the natural-drain path is not surfacing real leaks worth preserving. Verified locally: `cd src && pnpm test` -> 1121 passing, 0 failing, 23s. 2. Capture — set NODE_OPTIONS in each Backend tests step to --report-on-fatalerror, --report-uncaught-exception, --report-on-signal, --report-compact, plus --report-directory=${{ github.workspace }}/node-report. If Node crashes at the C++ level (segfault, V8 abort, libuv panic) the runtime writes a JSON diagnostic report with the V8 stack, libuv handle table, JS heap state, and OS info. A new "Upload Node diagnostic reports on failure" step (actions/upload-artifact@v7, `if: failure()`, `if-no-files-found: ignore`) uploads that directory as an artifact per matrix cell — the data we have been unable to capture from JS instrumentation alone. If (1) eliminates the flake on the next push to develop, great. If not, (2) finally gives us the crash dump and we can fix the root cause. Touches all four Backend tests jobs (Linux × 2, Windows × 2). The Windows steps now also set `shell: bash` so the same `mkdir -p ...` line works under git-bash; the existing `working-directory: src` is preserved. NODE_OPTIONS is scoped to the test step only, so the existing vitest step is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ci): address Qodo review on PR #7748 Three findings from Qodo's review of the Windows + Node 24 flake fix: 1. (bug) "mocha --exit masks handle leaks". --exit removes the post-suite event-loop drain that surfaces leaked timers / sockets — exactly the class of regression that lowerCasePadIds.ts notes is otherwise visible. Linux/local runs are currently green on natural drain, so dropping that signal everywhere would silence real leaks to fix a Windows-only flake. Fix: scope --exit to Windows only. - Remove --exit from src/package.json's "test" script (shared with local dev + Linux CI; both keep natural-drain behaviour). - Append `pnpm test -- --exit` in just the two Windows backend-test steps so the mitigation only runs where the flake actually lives. 2. (observability) "diagnostics exit-matrix misleading". With --exit on Windows, "only exit fires" becomes the EXPECTED pattern there, not a sign of unexpected process.exit(). Update the matrix comment in tests/backend/diagnostics.ts to spell out: clean drain on Linux/local → beforeExit + exit; Windows under --exit → only exit; "only exit" elsewhere still implies an unexpected process.exit somewhere. 3. (rule violation) "no regression test for the mitigation". Repo convention (see admin-i18n-source-lint.test.ts) is to pin policy-bearing config with a source-lint spec so a future refactor can't silently revert it. Add src/tests/backend-new/specs/backend-tests-flake-mitigation.test.ts: - Asserts every "Run the backend tests" step sets NODE_OPTIONS with the report-on-fatalerror diag flags AND is followed by an Upload Node diagnostic reports step (4 of each in the current matrix). - Asserts exactly 2 Windows jobs invoke `pnpm test -- --exit`. - Asserts the shared mocha "test" script in src/package.json does NOT bake in --exit globally. Verified locally: - cd src && pnpm exec vitest run tests/backend-new/specs/backend-tests-flake-mitigation.test.ts → 3 passed (3). - Stream.ts spec without --exit → 31 passing, diag prints "beforeExit code=0" + "exit code=0" (clean drain restored). - Existing admin-i18n-source-lint suite still passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
dependabot[bot]
|
197f007b4b
|
build(deps): bump actions/dependency-review-action from 4 to 5 (#7729)
Bumps [actions/dependency-review-action](https://github.com/actions/dependency-review-action) from 4 to 5. - [Release notes](https://github.com/actions/dependency-review-action/releases) - [Commits](https://github.com/actions/dependency-review-action/compare/v4...v5) --- updated-dependencies: - dependency-name: actions/dependency-review-action dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
John McLear
|
c7100e0ba4
|
fix(docker): bypass pnpm at runtime to avoid spurious deps-status reinstall (#7718) (#7727)
* chore: ignore /.worktrees/ for local worktree workflows * fix(docker): bypass pnpm at runtime to avoid spurious deps-status reinstall (#7718) pnpm 11's runDepsStatusCheck runs before every `pnpm run …` and decides node_modules is out of sync on container first start under the named- volume layout used by docker-compose (mounting src/plugin_packages). It then spawns `pnpm install --production`, which either prompts to wipe node_modules (tty: true) or aborts with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY (no tty). Reproduced by kimllee in ether/etherpad#7718 with the official etherpad/etherpad:latest image on arm64. Run node directly in CMD instead of going through `pnpm run prod`. The image's node_modules was already verified during build, so the runtime check adds no value. Wrapping in `sh -c 'cd src && exec node …'` keeps WORKDIR consistent for `docker exec` users while making node PID 1 so it receives SIGTERM directly and shuts down cleanly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(docker): regression test for #7718 — boot with named volume on plugin_packages Reproduces the production docker-compose layout from #7718: a named volume on src/plugin_packages and no allocated TTY. Under the previous `CMD ["pnpm", "run", "prod"]`, pnpm 11's runDepsStatusCheck spuriously flagged node_modules out of sync at boot, spawned `pnpm install --production`, and aborted with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY before the HTTP server came up. If the Dockerfile CMD is ever reverted to invoke pnpm at runtime, this step times out waiting for the health endpoint and fails CI. Addresses Qodo review feedback on #7727. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
3113c5096f
|
ci(rate-limit): wait for etherpad readiness before running test (#7726)
* ci(rate-limit): wait for etherpad to be ready before running the test The workflow starts the etherpad container in the background, then runs `pnpm install`, then runs the test. On a warm pnpm-store the install can finish before etherpad is listening on 9001, at which point nginx returns 502 for the test request and the run fails. Recent README-only commits on develop hit this race on three consecutive runs. Poll the nginx-proxied endpoint (port 8081 — also what the test uses) until it stops returning 5xx, with a 2-minute timeout and `docker logs etherpad-docker` on giving up to make diagnosis straightforward. * ci(rate-limit): address Qodo review (nginx logs, tighter timeout) - Name the nginx container so its logs can be captured when the readiness poll times out — previously nginx was started anonymously and a 502 caused by nginx itself (rather than etherpad) would have been hard to diagnose from the workflow log alone. - On timeout also dump `docker ps -a` for container-state visibility. - Tighten the readiness wait: 30 iterations × (1s curl timeout + 1s sleep) gives ~60s budget instead of ~240s, which is still well above observed cold-start time and keeps the failure-fast contract. |
||
SamTV12345
|
fd2f3baf55 | chore: fixed commit path | ||
|
SamTV12345
|
84e8461b69 | chore: update docker write location in values-dev.yaml | ||
|
John McLear
|
fe9727b31e
|
fix(docker): share corepack cache so etherpad user can resolve pnpm (#7689)
* fix(docker): share corepack cache so etherpad user can resolve pnpm (#7687) PR #7674 switched the Dockerfile from `npm install -g pnpm` to corepack and `corepack prepare pnpm@${PnpmVersion} --activate`. The activate step runs as root and writes its lastKnownGood pin into `$COREPACK_HOME`, which defaults to `~/.cache/node/corepack` — i.e. a per-user path. The Dockerfile then drops to `USER etherpad` and later runs `bin/installLocalPlugins.sh`, which invokes `pnpm` as etherpad. With an empty per-user corepack cache and no shared activation file, corepack re-resolves pnpm and (for forks/configs without a `packageManager` pin matching the activated version) can fall back to "latest" from the registry — pulling `pnpm@10.33.4` instead of the requested 11.x and failing the workspace's `engines.pnpm` check. Pin `COREPACK_HOME=/opt/corepack` and chown it to etherpad after the prepare step. Both root and etherpad now share the same lastKnownGood file and tarball cache, so etherpad inherits the activated pnpm without hitting the registry again. Verified end-to-end: - `docker build --target development --build-arg ETHERPAD_LOCAL_PLUGINS=ep_test` with a stub local plugin runs `installLocalPlugins.sh` cleanly: `Done in 16.6s using pnpm v11.0.6`. - `docker run ... pnpm --version` as etherpad reports 11.0.6 from the shared cache — no "Unsupported environment" error. Note: corepack still emits a one-time "about to download" line at runtime because `corepack prepare pnpm@11.0.6` resolves to the highest matching patch (11.0.8) at build time while the project's `packageManager` field pins exactly 11.0.6. That's a follow-up — the download succeeds non-interactively and the engine check passes. Fixes #7687. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(docker): action Qodo PR review (#7687 follow-up) - Replace hard-coded /opt/corepack with ${COREPACK_HOME} in mkdir/chown so the env var stays the single source of truth (Qodo: "COREPACK_HOME path duplication"). - Add a build-test-local-plugin job to .github/workflows/docker.yml that builds the development target with a stub ETHERPAD_LOCAL_PLUGINS so the original failure mode (corepack/pnpm cache invisible across the USER switch) cannot silently regress (Qodo: "COREPACK_HOME fix lacks test"). The job is small — `docker build` only, no run — and uses the shared GHA buildx cache. Verified: same docker build + `docker run pnpm --version` flow on the variable form gives identical output (pnpm 11.0.6 from the etherpad-owned cache). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
SamTV12345
|
0b0883c02b | chore: allow installs on release | ||
|
SamTV12345
|
6c7598d88b | chore: fixed deb package | ||
|
John McLear
|
958590d1c8
|
chore(docker): clear most CVEs in published image (npm/pnpm/uuid + drop curl) (#7674)
* chore(docker): clear most CVEs in published image — npm/pnpm/uuid + drop curl Cuts published-image vulnerabilities from 18 (4H/13M/1L) across 8 packages to 12 (2H/9M/1L) across 3 packages. The remaining three (curl/libcurl, git, busybox) are all upstream Alpine 3.23 packages with "not fixed" status — libcurl is pulled in transitively by git and cannot be removed independently. Changes: - Provision pnpm via corepack instead of `npm install -g pnpm`, then remove the bundled npm. The base image's npm@10.9.7 ships old transitives (picomatch 4.0.3 → CVE-2026-33671/33672, brace-expansion 2.0.2 → CVE-2026-33750) that we don't otherwise need at runtime; corepack handles pnpm directly without npm. Fixes 1H + 1M. - Bump PnpmVersion 10.28.2 → 10.33.2 to align with the rest of the workflow and pull in pnpm's patched bundled brace-expansion (5.0.5 vs 5.0.4). Fixes 1M. - Add `uuid@<14.0.0` → `>=14.0.0` to pnpm.overrides (GHSA-w5hq-g745-h8pq). Fixes 1M. - Drop `curl` from the runtime apk add list and switch HEALTHCHECK to wget (busybox built-in). curl was only invoked by the healthcheck and by dev/CI scripts that don't run in the container. Removes the curl CLI binary; libcurl remains as a git transitive dep, so the `apk/alpine/curl` advisories scout reports against libcurl persist but aren't reachable from any code we ship. As a side-effect this also clears nghttp2 (CVE-2026-27135) which was a curl-CLI dep. - Switch HEALTHCHECK URL from `localhost` to `127.0.0.1` — alpine/musl resolves localhost to ::1 first and Etherpad only binds IPv4. Verified locally: docker build → docker run → healthy → docker scout cves shows 12 CVEs / 3 packages. * fix(docker): refresh corepack before preparing pnpm (Qodo) Node 22's bundled corepack ships a stale signing-key list and can reject newer pnpm releases (nodejs/corepack#612), which would fail the image build at `corepack prepare`. Mirror the snap/snapcraft.yaml workaround: `npm install -g corepack@latest` before activating pnpm, in both adminbuild and build stages. npm is still removed afterwards. * docs(changelog): note docker image dropping curl/npm/npx (Qodo) Address Qodo's "backwards-incompatible change without mitigation" rule violations by documenting the removal in the 2.7.3 breaking-changes section. Operators who exec into the container can apk add curl on demand or use the busybox wget / pnpm already present. * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm * chore: pnpm --------- Co-authored-by: SamTV12345 <40429738+samtv12345@users.noreply.github.com> |
||
|
dependabot[bot]
|
4accea429b
|
build(deps): bump actions/download-artifact from 4 to 8 (#7668)
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4 to 8. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](https://github.com/actions/download-artifact/compare/v4...v8) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: '8' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
25dd8e492e
|
build(deps): bump actions/upload-artifact from 4 to 7 (#7669)
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](https://github.com/actions/upload-artifact/compare/v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
John McLear
|
02e37e0112
|
feat(packaging): publish Etherpad as a Snap (#7558)
* feat(packaging): publish Etherpad as a Snap Adds first-class Snap packaging so Ubuntu / snapd users can install via `sudo snap install etherpad-lite`. - snap/snapcraft.yaml — core24, strict confinement, builds with pnpm against a pinned Node.js 22 runtime. Version is auto-derived from src/package.json so `snap info` tracks upstream release numbering. - snap/local/bin/etherpad-service — launch wrapper that seeds $SNAP_COMMON/etc/settings.json on first run (rewriting the default dirty-DB path to a writable $SNAP_COMMON location) and execs Etherpad via `node --import tsx/esm`. - snap/local/bin/etherpad-healthcheck-wrapper — HTTP probe for external supervisors, falling back to Node if curl isn't staged. - snap/local/bin/etherpad-cli — thin passthrough to Etherpad's bin/ scripts (importSqlFile, checkPad, etc.). - snap/hooks/configure — exposes `snap set etherpad-lite port=<n>` and `ip=<addr>` with validation, restarts the service when running. - snap/README.md — build / install / configure / publish instructions. - .github/workflows/snap-publish.yml — builds on every v* tag, uploads a short-lived artifact, publishes to `edge`, and then promotes to `stable` through a manually-approved GitHub Environment. Requires a one-time `snapcraft register etherpad-lite` plus provisioning of the `SNAPCRAFT_STORE_CREDENTIALS` repo secret (instructions inline). Pad data (dirty DB, logs) lives in /var/snap/etherpad-lite/common/ and survives snap refreshes. The read-only $SNAP squashfs is never written to at runtime. Refs #7529 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): pass --settings flag, env-subst ip/port, 2-space indent Addresses Qodo review feedback on #7558: 1. Settings file ignored: Etherpad's Settings loader reads `argv.settings`, not the `EP_SETTINGS` env var. Without `--settings`, the launcher's seeded $SNAP_COMMON/etc/settings.json is never loaded; Etherpad falls back to <install-root>/settings.json, which lives on the read-only squashfs — so the default dirty-DB path ends up unwritable and the daemon fails to persist pads. Fix: pass `--settings "${SETTINGS}"` to node; drop the EP_SETTINGS export. 2. `snap set` overrides were no-ops: the seeded settings.json carries the template's literal `"ip": "0.0.0.0"` / `"port": 9001` values, which override the env-based defaults Etherpad exposes via ${…} substitution. Users following the README saw the listener stay put after `snap set etherpad-lite port=…`. Fix: after copying the template on first run, rewrite the top-level `ip` and `port` lines to `"${IP:0.0.0.0}"` / `"${PORT:9001}"`. Use `0,/…/` anchors so the `dbSettings.port` entry further down stays literal. 3. Indentation: reflow the new shell scripts from 4-space to 2-space to match the repo style rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): default seeded settings to sqlite, not dirty settings.json.template's own comment says dirty is for testing only. A Snap install is the "not testing" case — shipping it by default means every `sudo snap install etherpad-lite` starts on a DB the project explicitly recommends against. Rewrite the postinstall sed to switch dbType: "dirty" → "sqlite" and point filename at $SNAP_COMMON/var/etherpad.db. sqlite is already shipped in-tree via ueberdb2 → rusty-store-kv (prebuilt napi-rs binary, no build deps), so this works under strict confinement with zero snap.yaml changes. Only affects first-run seeding; existing $SNAP_COMMON/etc/settings.json is never touched on refresh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): rename to "etherpad", glob tag filter, harden cli - Snap is registered as `etherpad` (the project's only name) — drops the legacy `etherpad-lite` from the name, app, paths, install dir, configure hook, README and workflow artifact. The daemon app shares the snap name, so `snap install etherpad` exposes a bare `etherpad` command; the bin/ passthrough is now `etherpad.cli`. - snap-publish.yml: GitHub Actions tag filters use globs, not regex. The prior `v?[0-9]+.[0-9]+.[0-9]+` pattern would never match a real release tag (Qodo review). Replace with two glob entries covering `vX.Y.Z` and `X.Y.Z`. - etherpad-cli: reject path-traversal in the `<bin-script>` arg (anything containing `/`, `..`, or empty) and add a default `*)` case so files with unsupported extensions fail loud instead of silently exiting 0 (Qodo review). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): unbreak build — refresh corepack, drop pnpm prune Two issues hit on the first real `snapcraft pack` of this recipe: - `corepack prepare pnpm@10.33.0 --activate` failed with `Cannot find matching keyid` because Node 22.12's bundled corepack ships a stale signing-key list and rejects newer pnpm releases (nodejs/corepack#612). Refresh corepack itself via npm before preparing pnpm. - `pnpm prune --prod` is interactive on workspace projects: it asks "The modules directories will be removed and reinstalled from scratch. Proceed? (Y/n)" and deadlocks on stdin under sudo + tee. Replace it with the explicit "wipe node_modules + prod reinstall" pattern, which is non-interactive, faster (pnpm resolves the prod graph from its CAS cache), and byte-identical in result. Verified locally: `snapcraft pack --destructive-mode` produces `etherpad_2.6.1_amd64.snap` end-to-end in ~3 min. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): unbreak runtime — tsx resolution, var/ writability, env Three runtime crashes surfaced when actually installing the built snap under strict confinement. Fixed each, plus a smoke-test script. - `tsx` is in the `src` workspace's node_modules under pnpm hoisting, not at the snap install root. The wrapper now `cd "${APP_DIR}/src"` and uses bare `--import tsx` (matching `bin/cleanRun.sh`); the prior `--import tsx/esm` triggered ERR_REQUIRE_CYCLE on Etherpad's mixed CJS/ESM source tree. - Etherpad's plugin installer writes `var/installed_plugins.json` via __dirname-relative paths, which resolve to absolute paths inside the read-only snap squashfs (EROFS). snap layouts can't intercept paths inside `$SNAP`, so replace the shipped `var/` dir with a symlink to `/var/snap/etherpad/common/etherpad-app-var/` (auto-created by the wrapper on first run). Persistent state survives `snap refresh`. - Drop the unused `EP_SETTINGS` and `EP_DATA_DIR` env vars from the app's `environment:` block. Etherpad's settings loader doesn't read them — it reads `argv.settings`, which the wrapper already passes via `--settings`. They were producing `[WARN] settings - Unknown Setting` noise on every start. Add `snap/tests/smoke.sh`: rebuild + install + configure test port 9003 + assert listener + curl /health + tail logs. Local verified output: HTTP 200, body {"status":"pass","releaseId":"2.6.1"}, server logs `Etherpad is running` on `http://0.0.0.0:9003/`. .gitignore now excludes destructive-mode build outputs (parts/, stage/, prime/, .craft/, *.snap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(snap): wrapper unit tests, PR CI build, expanded docs Coverage in snap/tests/ (47 assertions, ~5s, no snapd/sudo/network): - test-snapcraft-yaml.sh: required keys, name validity, daemon-app matches snap name, no etherpad-lite regression, env-var whitelist. - test-cli.sh: path-traversal rejection, .ts/.sh dispatch, default-case rejection, no-args usage. - test-configure.sh: port (1-65535) and ip (v4/v6) validation via mocked snapctl. - test-service-bootstrap.sh: first-run seeding from settings.json.template, sed rewrite of dbType/filename/ip/port, writable-dir creation, snapctl override propagation to node env, idempotency on second run, default fallbacks. - run-all.sh: bash -n syntax check on every wrapper + hook, then sources each test file and reports totals. All assertions use port 9003 (project test convention). CI in .github/workflows/snap-build.yml: - Triggers on PR / push-to-develop touching snap/, settings.json.template, or the workflow itself. - Job 1 wrapper-tests: runs run-all.sh. - Job 2 snap-pack: snapcraft pack --destructive-mode, uploads .snap as PR artifact for sideload. - Stays separate from snap-publish.yml (tag-triggered, store-bound). snap/README.md fully rewritten: - User-facing usage, install, configure - Architecture: file layout, var/-symlink rationale, settings.json rewrite rationale, double-pnpm-install rationale, daemon-name-shares- snap-name rationale - Three test layers with exactly when/why to run each - Dev workflow loop - Publishing maintainer setup - Troubleshooting for every failure mode hit during this PR (EROFS, tsx not found, ERR_REQUIRE_CYCLE, snap-store-down, pnpm prune hang) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(snap): replace dead snapcraft.io/docs/releasing-to-the-snap-store link That URL now 404s. Point at the canonical documentation.ubuntu.com locations instead, broken out into the specific pages a maintainer actually needs: - Register a snap (to claim the name) - snapcraft export-login (to generate the SNAPCRAFT_STORE_CREDENTIALS secret) - Publishing how-to index (root index for everything else) Same fix in the snap-publish.yml header comment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
b8d1c8a192
|
ci(docs): build on PRs and pin Node 22 (Qodo follow-up to #7640) (#7645)
* ci(docs): build on PRs and pin Node 22 (Qodo follow-up to #7640) Qodo flagged two reliability gaps on the oxc-minify fix that landed in #7640: 1. The Deploy Docs to GitHub Pages workflow only ran on push to develop, so a PR that broke `pnpm run docs:build` was not caught until after merge — exactly how the dead-link regression in #7546 escaped. Add a pull_request trigger that runs the same build but skips the deploy/upload steps via `if: github.event_name == 'push'`. Also include the workflow file itself in the path filter so changes to it are exercised on PR. 2. oxc-minify@0.128.0 requires Node ^20.19.0 || >=22.12.0, but the workflow did not pin Node and the repo declared engines.node >=22.0.0 with engineStrict: true — a runner image (or local dev) on Node 22.0–22.11 would refuse to install. Pin Node 22 in the docs workflow with actions/setup-node@v6 (matching the rest of CI), and bump engines.node to >=22.12.0 so the project's engineStrict gate matches the actual minimum. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(docs): split build and deploy so PR runs do not hit pages env protection The previous attempt put `if: github.event_name == 'push'` on individual deploy steps but kept the single job's `environment: github-pages` binding. Environment protection rules reject any non-develop ref (including `refs/pull/N/merge`), so the runner failed the entire job at creation time before any step could execute: Branch "refs/pull/7645/merge" is not allowed to deploy to github-pages due to environment protection rules. Split into two jobs: `build` runs on every trigger (PR + push) and uploads the artifact only on push, `deploy` depends on `build`, runs only on push, and is the only job bound to the github-pages environment. Standard GHA pages-deploy pattern; PR builds never attempt to enter the protected environment. * docs: align Node minimum references with bumped engines.node (Qodo round 2 on #7645) Qodo flagged that engines.node moved from >=22.0.0 to >=22.12.0 in this PR but documentation still claimed the old requirement. Sync the three places that pinned a specific minimum: - README.md installation requirements (>= 22 → >= 22.12) - doc/npm-trusted-publishing.md publish prerequisites (>=22.0.0 → >=22.12.0, with oxc-minify cited as the driver) - CHANGELOG.md 2.7.3 breaking-changes entry (22 → 22.12, with the same oxc-minify justification) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
4704d80e82
|
ci: test ep_font_color and ep_hash_auth in with-plugins matrix (#7639)
* ci: add ep_font_color and ep_hash_auth to plugin test matrix These are the #12 and #14 most-installed Etherpad plugins on npm (last 30d) and were the only top-15 plugins not exercised by the withpluginsLinux / withpluginsWindows / Playwright with-plugins jobs. Adding them broadens coverage of the plugin loader against two real-world hooks: aceEditorCSS / aceAttribsToClasses (ep_font_color) and authenticate / handleMessage (ep_hash_auth). ep_hash_auth's authenticate hook is a no-op unless a Basic auth header is sent and a matching settings.users[user].hash exists, so it falls through cleanly with the default test settings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(change_user_color): close users popup before opening chat The "Own user color is shown when you enter a chat" spec leaves the users popup open after picking a color, then calls showChat(). In the with-plugins matrix the popup overlaps #chaticon and intercepts pointer events, so the click in showChat() is retried until the 90s timeout (× 5 retries ≈ 7m), failing both Firefox and Chrome with-plugins jobs. Toggle the users button off and wait for popup-show to drop before clicking the chat icon, matching the close pattern used in a11y_dialogs.spec.ts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
bbd29683d9
|
ci(frontend-tests): exclude ep_cursortrace + un-flake 30 of 31 #7611 skips (#7630)
* test(playwright): wait for editor editability in goToNewPad/goToPad #editorcontainer.initialized fires after padeditor.init resolves but before ace flips the inner body from `class="static"` / contentEditable=false to editable. Under WITH_PLUGINS load in Firefox that flip can lag long enough that an immediate click + keyboard.type runs against a still-static body and is silently dropped — the body keeps showing the default welcome text and never sees our input. Most of the specs that currently carry `test.skip(WITH_PLUGINS)` markers (#7611) are racing exactly this flip. Block in goToNewPad / goToPad until the inner #innerdocbody is `contenteditable="true"`, so every spec starts from a known-ready editor without each having to add its own ad-hoc waits. Value-driven: exits as soon as ace flips the attribute, no fixed delay. Refactored into a private waitForEditorReady() helper so goToNewPad and goToPad share a single source of truth. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip bold.spec under WITH_PLUGINS The two skipped tests fail because clicking the bold toolbar button right after selectAllText is intercepted by the #toolbar-overlay div (same root cause that needed force:true in clearAuthorship and ep_align). Add force:true to the click and drop the test.skip(WITH_PLUGINS) markers. The keypress variant doesn't click a toolbar button — it relies on the editor being editable when keyboard.press fires. The previous commit (waitForEditorReady in goToNewPad) covers that. Proof-of-concept un-skip; if CI confirms both pass, will expand the same pattern to the rest of the #7611 skip set. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): make bold.spec robust to Firefox + WITH_PLUGINS The previous attempt at un-skipping these tests added force:true on the toolbar click but left the legacy selectAllText + keyboard.type sequence in place. Firefox under WITH_PLUGINS load racily drops keystrokes from per-key events, leaving an empty selection that the bold-on-click and Ctrl+B branches both no-op'd against — the asserts then timed out 5 retries deep with no <b> element. Replace the selectAllText + keyboard.type prelude with the standard clearPadContent + writeToPad pair. writeToPad uses insertText (one input event for the whole string) which is the same fix that unblocked ep_align in #7625. Verified locally on Firefox + WITH_PLUGINS=1: 2/2 pass in 15s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip 4 writeToPad-only specs under WITH_PLUGINS These four specs were marked test.skip(WITH_PLUGINS) for "flaky in with-plugins suite" but only use writeToPad / clearPadContent / goToNewPad — no direct keyboard.type, no toolbar button clicks. The flake was the editor not being ready when the test's first interaction fired (now covered by waitForEditorReady in goToNewPad/goToPad earlier in this branch) plus writeToPad's switch to insertText (#7625). - urls_become_clickable.spec.ts (file-level skip) - unaccepted_commit_warning.spec.ts - undo_clear_authorship.spec.ts - timeslider_follow.spec.ts Just removing the skip lines is enough; no other changes needed. Verified locally on Firefox + WITH_PLUGINS=1: all 40 tests across the four specs pass in 3m1s. urls_become_clickable contributes the bulk (37 tests via parameterised describes). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip page_up_down and timeslider_line_numbers under WITH_PLUGINS Both specs use writeToPad + keyboard.press for Page Up/Down, End, arrow keys, and the like — no per-character keyboard.type, no toolbar button clicks. The flake was the editor not being ready when the spec's first interaction fired (now covered by waitForEditorReady earlier in this branch) plus writeToPad's switch to insertText (#7625) for the multi-line setup. - page_up_down.spec.ts (3 skips) - timeslider_line_numbers.spec.ts (1 skip) Verified locally on Firefox + WITH_PLUGINS=1: 5/5 tests pass. enter.spec.ts deliberately left skipped — its Enter-in-a-loop test (line 33) drops keypresses under load and needs a value-driven per-iteration verify, separate change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip chat/list_wrap/clear_authorship; re-skip undo_clear_authorship Three more files cleared after the editor-ready helper landed: - chat.spec.ts (2 skips) — both clicks target settings-popup checkboxes, not toolbar buttons; the toolbar-overlay isn't in play, so just dropping the skips is enough. - clear_authorship_color.spec.ts (1) — uses the existing clearAuthorship helper, which already runs with force:true. - list_wrap_indent.spec.ts (1) — adds force:true to the .buttonicon-insertorderedlist click that fires after selectAllText (same pattern as bold.spec). Reverts the un-skip on undo_clear_authorship.spec.ts: that one spawns two browser contexts and races against User B's writeToPad landing in the second pad. Hit a real flake locally where User B's text never appeared. Needs a per-user "wait for text to commit" before the assertion. Re-add the skip until that fix is in. Verified locally on Firefox + WITH_PLUGINS=1: 16 passed across the three un-skipped files (one undo_clear_authorship retry flaked, hence the revert). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip alphabet/delete/select_focus_restore under WITH_PLUGINS - alphabet.spec.ts (1) — swapped page.keyboard.type for writeToPad - delete.spec.ts (1) — same swap - select_focus_restore.spec.ts (1) — left keyboard.type in place (the test specifically verifies that focus returns to the editor after a toolbar select change; replacing with writeToPad would re-focus the body via a click and mask the bug being asserted). Editor-ready wait alone is enough here. Verified locally on Firefox + WITH_PLUGINS=1: 3/3 pass in 23s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip bold_paste + undo_redo_scroll under WITH_PLUGINS - bold_paste.spec.ts (1) — already used writeToPad; just dropping the skip is enough now that the editor-ready helper landed. - undo_redo_scroll.spec.ts (2) — replaced the `for (45 lines) { keyboard.type; keyboard.press('Enter') }` loop with a single writeToPad of `lines.join('\\n') + '\\n'`. writeToPad drives input via insertText (one input event per line) which Firefox under WITH_PLUGINS load handles without dropping events. The Ctrl+Z scroll-to-caret behaviour the test asserts is unchanged — each line still lands in its own changeset for the undo module to reverse. Verified locally on Firefox + WITH_PLUGINS=1: bold_paste passes clean; undo_redo_scroll passes via the existing per-spec `retries: 2` config (the scroll timing race exists pre-change and is what motivates the retries). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip unordered_list 'enter for the new line' under WITH_PLUGINS - Add force:true on the .buttonicon-insertunorderedlist click to bypass #toolbar-overlay (same pattern as clearAuthorship and bold.spec). - Replace the keyboard.type('line 1'); keyboard.press('Enter'); keyboard.type('line 2'); keyboard.press('Enter'); sequence with a single writeToPad('line 1\\nline 2\\n') — insertText per line + Enter between, which Firefox under WITH_PLUGINS load handles without dropping events. The trailing newline preserves the final Enter the original spec relied on. Verified locally on Firefox + WITH_PLUGINS=1: passes in 8s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip all 4 ordered_list tests under WITH_PLUGINS - issue #4748 + #1125: add force:true on .buttonicon-insertorderedlist clicks (toolbar-overlay interception after selection); collapse the per-line keyboard.type + keyboard.press('Enter') sequences into single writeToPad calls with embedded newlines. - issue #5160 and #5718 already used force:true and writeToPad throughout; just dropping the skip is enough now that the editor-ready helper landed. Verified locally on Firefox + WITH_PLUGINS=1: 11 passed (4 ordered_list + 5 unordered_list, plus 2 sub-describes). 1m24s total. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip all 4 indentation tests under WITH_PLUGINS Same pattern as bold/ordered_list/unordered_list: - force:true on .buttonicon-indent / .buttonicon-bold / .buttonicon-outdent clicks (toolbar-overlay interception after a text selection). - Replace per-line keyboard.type + keyboard.press('Enter') sequences with single writeToPad calls using \\n separators. - Replace single-character keyboard.type calls (':', '(', '[', '{{') with keyboard.insertText for consistency. The keypress and indent/outdent button tests were already passing without WITH_PLUGINS skips — only the four tests that race the toolbar click + typing sequence were skipped. With force:true and writeToPad they're stable. Verified locally on Firefox + WITH_PLUGINS=1: 12 tests pass across indentation, ordered_list, unordered_list, list_wrap_indent (matched by the indent grep). 1m11s total. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip enter.spec 'enter is always visible' under WITH_PLUGINS The test fired 15 keypress('Enter') calls in a tight loop with no per-iteration verify. Under Firefox + WITH_PLUGINS load the editor's input pipeline can't always keep up while plugin hooks are warming, so a few presses get dropped and the final `expect(div.count).toBe(numberOfLines + originalLength)` fails with too few lines. Add a value-driven `expect(div).toHaveCount(originalLength + i + 1)` after each press. The loop only advances once the editor has acknowledged the previous Enter, so dropped events become slow events instead of lost ones. Verified locally on Firefox + WITH_PLUGINS=1: passes in 11s (would have been 1.5m timeout previously). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip undo_clear_authorship under WITH_PLUGINS The two-user test was racing on User B's keyboard.type('Hello from User B') and 'Still connected!' — Firefox + WITH_PLUGINS load drops keystrokes from per-key events, leaving the second pad with truncated text that the body1 round-trip assertion never matches. Replace both keyboard.type calls with keyboard.insertText (single input event). Cannot use writeToPad here because the test relies on the caret position established by the preceding End + Enter — a writeToPad would re-click the body and reset focus. Verified locally on Firefox + WITH_PLUGINS=1: both tests pass clean in 30s (previously failed all retries at 1m+ each). The test.describe.configure({retries: 2}) is kept as belt-and-braces for the multi-context server propagation race that this test exercises legitimately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip collab_client 'bug #4978 regression test' under WITH_PLUGINS The test's replaceLineText helper used keyboard.type(newText) to insert the replacement string after a Backspace clear. Firefox under WITH_PLUGINS load drops keystrokes from per-key events, leaving the line with truncated text that the cross-context assertions (body1.toHaveText(user2Text), body2.toHaveText(user1Text)) never match. Switch the type to keyboard.insertText (single input event) — same fix that unblocked ep_align in #7625 and the other typing-races in this branch. The selectText + Backspace + insertText pattern still exercises the legitimate collab race the test asserts (concurrent edits over the COLLABROOM). Verified locally on Firefox + WITH_PLUGINS=1: passes in 15s. This was the last of the 31 test.skip(WITH_PLUGINS, '#7611') markers in src/tests/frontend-new/specs/. The branch goal of zero #7611 skips is met. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): use stable l10n selector for OL toolbar button Qodo flagged the .first() call in #4748's setup as DOM-order dependent: a future plugin that adds another element carrying the .buttonicon-insertorderedlist class would silently change which button the test clicks. Switch to button[data-l10n-id='pad.toolbar.ol.title'] (the localizationId declared in src/node/utils/toolbar.ts), which is unique to the core ordered-list toolbar entry. Drop the now-unnecessary .first(). The class-based locator remains in #5160, #5718, and the indent/ outdent sub-describes; those don't strict-mode-match more than one element today, but a follow-up could swap them too for consistency if reviewers want. Verified locally on Firefox + WITH_PLUGINS=1: passes in 7s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): tighten writeToPad Enter delivery + fix toolbar overlay regressions Three fixes for the failures that surfaced once #7630 ran in CI on Firefox + WITH_PLUGINS at the full matrix: 1. **writeToPad** now value-waits per Enter and retries up to 3 times if the editor doesn't acknowledge a new line. Long multi-line writes (e.g. timeslider_follow's #4389 setup with ~120 newlines) were dropping Enters faster than the previous single-press loop tolerated. The retry surfaces the canonical "expected N, got M" timeout if all 3 attempts fail. 2. **unordered_list.spec.ts**: every `.buttonicon-*` toolbar click now uses {force: true}. Two of the un-skipped tests intermittently missed the click under load because #toolbar-overlay intercepts pointer events after a text selection (same pattern as bold, ep_align, et al.). Body clicks (clicks inside the iframe pad body) are unaffected and stay as plain `.click()`. 3. **timeslider_follow.spec.ts** "regression test for #4389": re-skipped under WITH_PLUGINS with a specific note. The 120-Enter setup races plugin load even with the new writeToPad retry — re-press attempts overshoot the exact line count when a "dropped" Enter eventually lands. Needs a fundamentally different setup approach (REST API import, clipboard paste, etc.) to un-skip reliably; out of scope here. Net: 30 of the original 31 #7611 skips remain removed (was 31/31 before; the one re-skip is a documented known-aggressive case). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): revert writeToPad per-Enter retry — overshoots cause more failures The per-Enter value-wait + retry I added in fc45d71e5 was meant to catch dropped Enters in long multi-line writes, but in CI it made things worse: when a "dropped" Enter eventually landed during the retry's short poll window, the next iteration's exact line-count expectation was off by one and the retry loop overshot, breaking tests that previously passed (urls_become_clickable, language, inner_height all hit toHaveCount mismatches that didn't exist before). Revert to the simpler insertText + bare keyboard.press('Enter') loop. Tests with extreme line counts (timeslider_follow #4389, ~120 Enters) stay re-skipped from the prior commit; everything else accepts the same intermittent flake the helper exhibited before this fix attempt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): re-skip 8 tests that need deeper rework to un-skip Honest scope adjustment after CI surfaced load-dependent failures that local single-run verification missed. The previous batches worked at low concurrency but flake at the full Playwright matrix under WITH_PLUGINS: - bold_paste.spec.ts — clipboard / paste race between specs - collab_client.spec.ts (bug #4978) — multi-context cross-pad propagation under load - enter.spec.ts (enter is always visible) — 15-Enter loop drops presses faster than the per-iteration value-wait can recover - timeslider_follow.spec.ts (content as it's added) — 66 sequential Enters across 6 writeToPad calls - undo_clear_authorship.spec.ts (describe-level) — multi-context; the cross-pad text-arrival assertion races - undo_redo_scroll.spec.ts (describe-level) — 45-line writeToPad setup; scroll-position assertion needs stable layout - unordered_list.spec.ts (Keeps unordered list on enter) — toolbar click + writeToPad with embedded newline races All carry inline comments explaining the specific load issue and referencing #7611 so a follow-up that introduces a REST-driven or clipboard-paste setup mechanism can target them concretely. Net: 23 of 31 #7611 skips removed (74%). The deferred 8 share two underlying limitations that need infrastructure work: 1. No reliable way to drive >10 sequential Enters under load without occasional drops 2. No reliable cross-context propagation wait helper Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins: Firefox×HALF-A + Firefox×HALF-B One CI run, both halves of the standard plugin set, both on Firefox (which is the project that reliably trips the flake we're chasing). Playwright Firefox with plugins → HALF A: ep_align, ep_author_hover, ep_cursortrace, ep_font_size, ep_headings2 Playwright Chrome with plugins → HALF B: ep_markdown, ep_readonly_guest, ep_set_title_on_pad, ep_spellcheck, ep_subscript_and_superscript, ep_table_of_contents (job runs --project=firefox here too) Decision matrix on next CI: - Both fail → load alone is the cause; deeper rework needed. - Only A fails → culprit is in HALF A (5 candidates). - Only B fails → culprit is in HALF B (6 candidates). - Both pass → flake threshold sits between 5–6 plugins; the culprit is whichever 2-plugin pair from the full set tips the load above threshold; iterate. Revert this commit before merging — it's purely a CI probe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 2: A1 (align,author_hover) vs A2 (cursortrace,font_size,headings2) Iteration 1 isolated to HALF A. Splitting: Playwright Firefox with plugins → A1: ep_align, ep_author_hover Playwright Chrome with plugins → A2: ep_cursortrace, ep_font_size, ep_headings2 (still --project=firefox) Decision matrix: - Both fail → load alone tips it; ≥2 of these 5 are needed. - Only A1 fails → culprit is ep_align or ep_author_hover. - Only A2 fails → culprit is ep_cursortrace, ep_font_size, or ep_headings2. - Both pass → flake threshold is between 2 and 3 plugins from A, revisit splitting (could be a specific pair). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 3: A2a (cursortrace) vs A2b (font_size, headings2) Iteration 2 isolated to A2 (cursortrace+font_size+headings2). Iter 3 singles out ep_cursortrace: Playwright Firefox with plugins → A2a: ep_cursortrace Playwright Chrome with plugins → A2b: ep_font_size, ep_headings2 (still --project=firefox) Decision matrix: - Only A2a fails → ep_cursortrace is the culprit (1 plugin alone tips it). - Only A2b fails → culprit is ep_font_size or ep_headings2. - Both fail → load tips at >=1 plugin from this set; investigate each individually. - Both pass → load tips at >=3 plugins; revisit splitting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 4 (confirm): all-minus-cursortrace Iter 3 isolated to ep_cursortrace alone. Confirming by running the inverse — every other plugin in the standard set, no ep_cursortrace — on TWO Firefox runs in parallel: Playwright Firefox with plugins → align, author_hover, font_size, headings2, markdown, readonly_guest, set_title_on_pad, spellcheck, subscript_and_superscript, table_of_contents Playwright Chrome with plugins → same 10 plugins (still --project=firefox per probe) Both pass → ep_cursortrace is conclusively the culprit. Either fails → load is the cause and the bisection mis-attributed (would need to investigate why iter 3 cursortrace-only failed: maybe a flaky one-off). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(frontend-tests): exclude ep_cursortrace from with-plugins set Bisected via 4 CI iterations on this branch. ep_cursortrace's `aceEditEvent` hook (static/js/main.js in the plugin) fires on every keyboard event — handleClick, handleKeyEvent, idleWorkTimer — and unconditionally sends a `cursorPosition` socket message via `pad.collabClient.sendMessage` per call. Under the test harness's writeToPad bursts (insertText + Enter loops) that stream of socket messages saturates the editor's input pipeline in Firefox specifically, causing intermittent keystroke drops and the entire class of #7611 flakiness this PR was originally chasing. Confirmation runs: - 11-plugin set including ep_cursortrace → fails on Firefox - HALF B (5 plugins, no cursortrace) → passes - HALF A (5 plugins, with cursortrace) → fails - A1 (align, author_hover) — no cursortrace → passes - A2 (cursortrace, font_size, headings2) → fails - A2a (cursortrace alone, 1 plugin) → fails - A2b (font_size, headings2, no cursortrace) → passes - 10-plugin set, all minus ep_cursortrace → passes (×2 jobs) Drop ep_cursortrace from the frontend-tests.yml plugin set and restore all the un-skips that this PR pessimistically re-skipped during the load-symptom whack-a-mole. The plugin itself needs a debounce/throttle around its socket send before it can come back into the test set; tracked separately in the ep_cursortrace repo. Backend tests / docker / etc remain on the original 11-plugin set since they don't trip the same input-pipeline race. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
0a2facb3fc
|
ci(packaging): publish signed apt repository to etherpad.org/apt (closes #7610) (#7624)
* ci(packaging): publish signed apt repository to etherpad.org/apt (closes #7610) Adds an `apt-publish` workflow job that turns the existing `.deb` build artefacts into a signed apt repository hosted at: https://etherpad.org/apt/ End-user install on any Debian/Ubuntu/Mint: curl -fsSL https://etherpad.org/key.asc \ | sudo gpg --dearmor -o /usr/share/keyrings/etherpad.gpg echo "deb [signed-by=/usr/share/keyrings/etherpad.gpg] \ https://etherpad.org/apt stable main" \ | sudo tee /etc/apt/sources.list.d/etherpad.list sudo apt update && sudo apt install etherpad `apt upgrade` works going forward — every tagged release republishes the repo metadata. Change type: patch (CI/distribution; no production behaviour change). ## Why etherpad.org/apt and not ether.github.io/etherpad/apt ether/etherpad's GitHub Pages is already configured as build-from-workflow on `develop` with CNAME `docs.etherpad.org`, and a repo can only have one Pages source. Pushing the apt repo to a gh-pages branch would either be ignored (Pages is reading from the docs workflow) or, if Pages were switched to it, would kill the docs site. ether/ether.github.com is a separate Next.js site that already deploys etherpad.org and serves `public/` verbatim, so cross-pushing the apt repo into `public/apt/` lands it at the canonical Etherpad URL with no infrastructure conflicts. ## What this PR ships 1. `apt-publish` job in `.github/workflows/deb-package.yml`. Runs after `release` on `v*` tag pushes: - Clones ether/ether.github.com over SSH using a deploy key. - Wipes site/public/apt/ and rebuilds it from the per-arch .deb artefacts using apt-ftparchive. - Signs Release + emits InRelease/Release.gpg using the keypair in APT_SIGNING_KEY. - Drops key.asc into site/public/key.asc. - Asserts both per-arch .debs are present before the wipe takes effect — refuses to publish a partial / empty repo if an artefact is missing or renamed. - Commits and pushes to master; the site repo's existing build pipeline picks it up. 2. `packaging/apt/key.asc` — Etherpad APT Repository public key, fingerprint 6953FA0C6431F30347D65B03AF0CD687D51A6E63. Served at https://etherpad.org/key.asc after the next release. 3. `packaging/apt/generate-signing-key.sh` — one-shot helper that generated the keypair, kept for documented future rotation. 4. `packaging/README.md` — apt-repo install recipe is now the recommended path. ## Required secrets before the next tagged release Two secrets on ether/etherpad before the next `v*` tag push: - APT_SIGNING_KEY — ASCII-armoured private key for the Etherpad APT Repository keypair (long key id AF0CD687D51A6E63), generated with packaging/apt/generate-signing-key.sh. - SITE_DEPLOY_KEY — SSH private key. The public half registered as a deploy key with WRITE access on ether/ether.github.com. If either is missing the job fails fast with a clear error. ## What this PR does not change - The release job still attaches both versioned (etherpad_<v>_<arch>.deb) and stable-aliased (etherpad-latest_<arch>.deb) artefacts to the GitHub Release. Anyone pulling from releases/latest/download/etherpad-latest_amd64.deb keeps working. - The build-job smoke test (start under systemd, /health, purge) is unchanged. - docs.etherpad.org is untouched; this PR never pushes to gh-pages. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(packaging): emit unindented Release headers + tighten artefact glob Two corrections from a fresh Qodo review of the rebased apt-publish job: 1. The dists/${SUITE}/Release heredoc was indented with the workflow's YAML scope, which means the resulting file had 10-space-prefixed field lines (` Origin: Etherpad`). apt parsers reject any leading whitespace on header fields per RFC 822 / Debian control format, so the entire suite would have failed to parse on `apt update` even before checksums were appended. Replace the heredoc with `printf '%s\n' ...` so the indentation is entirely under workflow control and impossible to break with a future YAML re-indent. 2. Tighten the artefact glob from `etherpad_*_amd64.deb` to `etherpad_[0-9]*_amd64.deb`. The hyphen-separator distinction (etherpad_<v>_… vs etherpad-latest_…) already kept the alias out of the array — Qodo's analysis of a duplicate-Packages bug was incorrect. But pinning to a leading-digit version segment makes the contract explicit and defends against any future alias that accidentally lands on `dist/etherpad_<word>_<arch>.deb`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
SamTV12345
|
c55007361c
|
chore: updated node to supported 22,24,25 (#7628)
* chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: upgrade deb * chore: upgrade dockerfile * chore: use explicit node * chore: use node 22 * chore: use node 22 |
||
|
dependabot[bot]
|
421869daec
|
build(deps): bump actions/upload-artifact from 4 to 7 (#7612)
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](https://github.com/actions/upload-artifact/compare/v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
SamTV12345
|
74d1715c1b
|
chore: updated clients to esm (#7627) | ||
|
John McLear
|
1eea9de08c
|
ci: run frontend tests with /ether plugin set (closes #7608) (#7609)
* ci: run frontend tests with /ether plugin set (closes #7608) Mirrors backend-tests.yml's withpluginsLinux: installs the same 11 ep_* plugins (ep_align, ep_author_hover, ep_cursortrace, ep_font_size, ep_headings2, ep_markdown, ep_readonly_guest, ep_set_title_on_pad, ep_spellcheck, ep_subscript_and_superscript, ep_table_of_contents) and runs Playwright Chromium + Firefox against them. Re-introduces frontend-with-plugins coverage that was lost in commit |
||
|
dependabot[bot]
|
020829a72e
|
build(deps): bump softprops/action-gh-release from 2 to 3 (#7613)
Bumps [softprops/action-gh-release](https://github.com/softprops/action-gh-release) from 2 to 3. - [Changelog](https://github.com/softprops/action-gh-release/blob/master/CHANGELOG.md) - [Commits](https://github.com/softprops/action-gh-release/compare/v2...v3) --- updated-dependencies: - dependency-name: softprops/action-gh-release dependency-version: '3' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
2149cfe9a0
|
build(deps): bump actions/download-artifact from 4 to 8 (#7614)
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 4 to 8. - [Commits](https://github.com/actions/download-artifact/compare/v4...v8) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-version: '8' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
John McLear
|
0b40bfc784
|
feat(packaging): add Debian (.deb) build via nfpm with systemd unit (v2) (#7583)
* feat(packaging): add Debian (.deb) build via nfpm with systemd unit First-class Debian packaging for Etherpad, producing etherpad_<version>_<arch>.deb artefacts for amd64 and arm64 from a single nfpm manifest. Installing the package gives users: - /opt/etherpad with a prebuilt, self-contained node_modules/ — no pnpm required at runtime, just `nodejs (>= 20)`. - etherpad system user/group, created via `adduser` in preinst. - /etc/etherpad/settings.json seeded from the template on first install, preserved across upgrades, removed on `purge`. Seed rewrites dbType from the template's dev-only `dirty` default to `sqlite`, pointed at /var/lib/etherpad/etherpad.db so fresh installs get an ACID-safe DB without manual config. sqlite is shipped by ueberdb2 (rusty-store-kv), so no additional apt deps are needed. - /var/lib/etherpad owned by etherpad:etherpad, writable under the hardened unit's ProtectSystem=strict. - /lib/systemd/system/etherpad.service — hardened unit (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, RestrictAddressFamilies) with Restart=on-failure. - /usr/bin/etherpad CLI wrapper running `node --import tsx/esm`. CI (.github/workflows/deb-package.yml) triggers on v* tags, builds both arches via native runners (ubuntu-latest + ubuntu-24.04-arm), smoke-tests the amd64 package end-to-end (install → verify sqlite default → systemctl start → curl /health → purge → confirm user removed), and attaches the artefacts to the GitHub Release. Re-introduces the work from #7559 (reverted in #7582) with two corrections: 1. Package name and all installed paths use `etherpad`, not `etherpad-lite` — matches the repo rename. Kept replaces/conflicts on `etherpad-lite` so any dev builds of the reverted PR upgrade cleanly. 2. Default dbType is `sqlite`, not `dirty`. The template's own comment says dirty is for testing only; shipping it by default to everyone who runs `apt install etherpad` is the wrong tradeoff for a production package. Publishing to an APT repo (Cloudsmith, Launchpad PPA, self-hosted reprepro) is intentionally out of scope — needs a governance decision on who holds the signing key. Recipes are documented in packaging/README.md. Refs #7529, #7559, #7582 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(packaging): address PR review — startup crashes, supply chain, Node LTS Addresses Qodo and SamTV12345 review feedback on #7583: - postinstall: symlink /opt/etherpad/var → /var/lib/etherpad/var so ProtectSystem=strict doesn't block runtime writes (var/js, installed_plugins.json, etc.). Existing ReadWritePaths covers it. - postinstall: seed installed_plugins.json with ep_etherpad-lite so checkForMigration() does not spawn `pnpm ls` on first boot — pnpm is not a runtime dep, and the bundled node_modules already contains every shipped plugin. Prevents network plugin installs at first run. - postremove: clean up the new var symlink on remove. - workflow: verify nfpm .deb sha256 against upstream checksums.txt before sudo dpkg -i (defense in depth). - workflow: bump Node 22 → 24 (current LTS, per SamTV12345). The deb Depends stays at nodejs (>= 20) to match Etherpad's engines.node. - workflow: smoke-test now asserts the var symlink and seeded installed_plugins.json exist post-install. - workflow: publish stable etherpad-latest_{amd64,arm64}.deb aliases alongside the versioned files in the GitHub Release. - README: bump Node guidance to 24, document /releases/latest URL, link to engines.node floor. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(packaging): tsx CJS hook, plugin paths writable, glob tag triggers Addresses second-round Qodo review on #7583: - bin/etherpad: switch from `--import tsx/.../esm` to `--require tsx/cjs`. server.ts uses `exports.start = ...` which throws under the ESM loader; the prod script in src/package.json uses tsx/cjs for the same reason. - postinstall: symlink /opt/etherpad/src/plugin_packages → /var/lib/etherpad/plugin_packages and chgrp /opt/etherpad/src/node_modules to etherpad with mode 2775. Otherwise admin-UI plugin install EACCESes — those are the dirs LinkInstaller writes to. - systemd unit: add /opt/etherpad/src/node_modules to ReadWritePaths so symlink creation by the etherpad user is allowed under ProtectSystem=strict. plugin_packages is already covered via the symlink into /var/lib/etherpad. - postremove: clean up the new plugin_packages symlink on remove. - workflow: tag filters were `v[0-9]+.[0-9]+.[0-9]+`, but Actions tag filters are globs, not regex. `[0-9]+` matches one character, so multi-digit tags like v2.10.0 would never trigger. Switch to `v*.*.*` / `v*.*.*-*`, matching handleRelease.yml. - workflow smoke test now asserts plugin_packages symlink target, ownership of plugin_packages and node_modules. - test-local.sh: new script that builds the .deb and runs the same smoke test in a throwaway systemd-enabled Docker container, so failures are caught before pushing. - README: document test-local.sh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(packaging): test-local.sh — fix cgroups v2, add --no-systemd mode - systemd-in-docker on cgroups v2 needs --cgroupns=host and a writable /sys/fs/cgroup mount; the previous :ro version booted to nothing. - New --no-systemd mode: drops the systemd container in favour of plain ubuntu:24.04 + manual launch under the etherpad user. Validates the postinstall, wrapper, plugin paths, and /health without depending on the host's systemd-in-docker setup. Use it when --privileged systemd containers don't boot on your kernel/docker combo. - On systemd container exit the script now dumps the last 50 log lines and points at --no-systemd as the fallback. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(packaging): test-local.sh — reuse cached image in --no-systemd If ubuntu:24.04 isn't on disk and the registry is unreachable, fall back to whichever ubuntu/debian image is already cached (e.g. the jrei/systemd-ubuntu image we pulled for the systemd path). Avoids a registry round-trip on flaky networks. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: handle spawn errors in run_cmd; deb-package install order + offline-safe test src/node/utils/run_cmd.ts: Without `proc.on('error', ...)` a spawn failure (e.g. ENOENT for a missing binary) is emitted as an unlistened 'error' event, which Node treats as an uncaught exception that bypasses the awaiting try/catch and kills the process. The .deb hits this on first boot because plugins.ts spawns `pnpm --version` for a startup log line and pnpm isn't a runtime dep — Etherpad logs "Starting" then immediately stops. Reject the promise on 'error' so the existing try/catch in the caller actually catches it. packaging/scripts/postinstall.sh: chown /var/lib/etherpad/plugin_packages AFTER `cp -a` from the staged tree — `cp -a` preserves source (root) ownership and was re-rooting the directory we'd just chowned to etherpad. Same ordering the var symlink block already used. packaging/test-local.sh: Run `CI=1 pnpm install --frozen-lockfile` before staging so the package is built from a fresh, lockfile-consistent tree (matches CI). Fixes spurious "Cannot find module 'X'" failures from stale local symlinks pointing at out-of-date pnpm store paths. End-to-end test now passes: postinstall asserts pass, /health returns 200, dpkg --purge cleans up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: gitignore packaging build artefacts; drop accidental commit Drop packaging/etc/settings.json.dist that snuck into the previous commit (generated at build time by test-local.sh / CI from settings.json.template). Add /staging/, /dist/, /packaging/etc/ to .gitignore so they don't recur. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(plugins): downgrade missing-pnpm log from ERROR to debug The startup IIFE that logs the pnpm version is informational only. pnpm is a dev-only dependency: admin-UI plugin install goes through live-plugin-manager directly, and plugin migration is short-circuited when var/installed_plugins.json is present (e.g. on packaged installs). A missing pnpm on PATH is therefore expected on hardened deployments and shouldn't surface as a red ERROR in journalctl. Detect ENOENT specifically and log at debug; treat other errors (permission denied, etc.) as warnings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(packaging): smoke deb on PRs + backend test for run_cmd spawn errors CI gap: deb-package.yml only fired on v* tag pushes, so a PR that broke the .deb wasn't caught until release time. Wire it to PRs and develop pushes via a paths filter covering packaging files and the runtime files Etherpad needs at first boot. The release job already gates on `if: startsWith(github.ref, 'refs/tags/v')` so PR runs won't try to publish. Test gap: the run_cmd.ts spawn-error fix (commit |
||
|
SamTV12345
|
a05bb7d7b3
|
chore: added release notes for 2.7.1 (#7604)
* chore: added release notes for 2.7.1 * chore: don't cache node_modules due to cas |
||
|
John McLear
|
de5feb2eb5
|
Revert "feat(packaging): add Debian (.deb) build via nfpm with systemd unit (…" (#7582)
This reverts commit
|
||
|
John McLear
|
6bb879ed03
|
feat(packaging): add Debian (.deb) build via nfpm with systemd unit (#7559)
* feat(packaging): add Debian (.deb) build via nfpm with systemd unit First-class Debian packaging for Etherpad, producing signed-ready etherpad-lite_<version>_<arch>.deb artefacts for amd64 and arm64 from a single nfpm manifest. Installing the package gives users: - /opt/etherpad-lite with a prebuilt, self-contained node_modules/ — no pnpm required at runtime, just `nodejs (>= 20)`. - etherpad system user/group, created via `adduser` in preinst. - /etc/etherpad-lite/settings.json seeded from the template on first install, preserved across upgrades, removed on `purge`. - /var/lib/etherpad-lite owned by etherpad:etherpad, with the default dirty-DB retargeted there so ProtectSystem=strict works. - /lib/systemd/system/etherpad-lite.service — hardened unit (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, RestrictAddressFamilies) with Restart=on-failure. - /usr/bin/etherpad-lite CLI wrapper running `node --import tsx/esm`. CI (.github/workflows/deb-package.yml) triggers on v* tags, builds both arches via native runners (ubuntu-latest + ubuntu-24.04-arm), smoke-tests the amd64 package end-to-end (install → systemctl start → curl /health → purge → confirm user removed), and attaches the artefacts to the GitHub Release. Publishing to an APT repo (Cloudsmith, Launchpad PPA, self-hosted reprepro) is intentionally out of scope — needs a governance decision on who holds the signing key. Recipes are documented in packaging/README.md. Refs #7529 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(deb): fail smoke test on /health timeout, tighten default-file perms, 2-space indent Addresses Qodo review feedback on #7559: 1. Smoke test false-positive: the `for` loop polling /health never failed the job if the endpoint stayed down — `curl && break || sleep 2` keeps returning 0 from the trailing `sleep`, so `set -e` never trips. CI could attach a broken .deb to a release. Fix: track success explicitly and exit 1 (plus dump journald logs for diagnostics) when the service never becomes healthy. 2. /etc/default/etherpad-lite was world-readable (0644). systemd loads it via `EnvironmentFile=…`, and Etherpad supports ${ENV_VAR}-substitution for secrets (DB_PASSWORD etc.), so any local user could read anything admins drop there. Fix: install the conffile as root:etherpad 0640 — only root and the service user can read it. 3. Indentation: reflow maintainer scripts from 4-space to 2-space to match the repo style rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
053f6d8343
|
fix(#7570): bundle DB drivers, add regression CI (#7572)
* docs: design spec for issue #7570 (ueberdb2 driver bundling) Spec for the upstream ueberDB fix (move 10 drivers back from optional peer deps to dependencies) plus downstream etherpad-lite safety net (explicit driver list + build-test-db-drivers CI job covering all 10 via presence check and MySQL+Postgres smoke tests). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: implementation plan for issue #7570 ueberdb2 driver bundling Covers upstream ueberDB PR (move drivers from optional peer deps back to dependencies, publish 5.0.46) and downstream etherpad-lite PR (bump ueberdb2, defensive driver list, build-test-db-drivers CI job with presence + MySQL + Postgres stages gating publish). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(#7570): bundle DB drivers, add regression CI - Bump ueberdb2 to ^5.0.47 (upstream ueberDB PR #939 re-bundles drivers as real dependencies instead of optional peer deps, fixing the class of Docker-prod "Cannot find module" failures). - Declare all 10 ueberdb2 DB drivers as direct src dependencies as a defensive safety net against a future upstream drift. - Add build-test-db-drivers CI job that blocks the publish job: * all-10-drivers presence check in the built prod image * end-to-end MySQL smoke (reproduces the #7570 repro) * end-to-end Postgres smoke Any stage failure blocks Docker Hub / GHCR publish. Supersedes #7571. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ci): run driver presence test from src/ so node_modules resolves The presence test ran node from the default cwd (/opt/etherpad-lite), but the drivers are installed under /opt/etherpad-lite/src/node_modules by the monorepo workspace. Adding `-w /opt/etherpad-lite/src` makes Node resolve modules from src/node_modules where pnpm places them. Matches how the production container itself runs: `pnpm run prod` is invoked from src/ (cross-env + node --require tsx/cjs node/server.ts). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
c2e69388d9
|
ci: publish Docker images to GHCR alongside Docker Hub (#7569)
* ci: publish Docker images to GHCR alongside Docker Hub Adds ghcr.io/ether/etherpad as a second publish target on release tags, reusing the existing docker/metadata-action step so the same SemVer tags (e.g. 2.6.1, 2.6, 2, latest) are pushed to both registries. Motivation: downstream consumers (Helm charts in particular) hit Docker Hub anonymous pull rate limits. GHCR has no such limits and the workflow already runs with GITHUB_TOKEN, so this is additive with no new secrets required. Docker Hub remains the primary/canonical source; GHCR is a mirror. Note: this only affects future release tags. The 2.6.1 tag already on Docker Hub will need to be mirrored separately (e.g. via skopeo) if downstream needs it on GHCR before the next release. * address qodo review: scope packages:write to publish job, document GHCR Two fixes from the qodo code review on #7569: 1. Overprivileged PR token (security). The original change set 'packages: write' at workflow level, which meant pull_request runs (whose Test step executes PR-controlled code) also inherited push access to GHCR. Splits the workflow into two jobs: - build-test: runs on pull_request and push with contents:read only. Does the single-arch load+test as before. - publish: needs build-test, runs only on push with packages:write. Does the multi-arch build-and-push, Docker Hub description update, and ether-charts bump. Docker Hub login is also now gated by job-level 'if' (same effect as the previous step-level 'if'). 2. Docs miss GHCR option. Updates doc/docker.md and README.md to document the GHCR mirror alongside Docker Hub with equivalent pull examples, so downstream users discovering via docs can choose the mirror to avoid Docker Hub rate limits. |
||
|
John McLear
|
3ccf0b1c04
|
ci(security): restrict GITHUB_TOKEN permissions in update-plugins workflow (#7557)
Adds an explicit `permissions: contents: read` block to update-plugins.yml. Cross-repo work (cloning ether/ep_* repos, pushing updates, merging Dependabot PRs) is authenticated via secrets.PLUGINS_PAT, so the default GITHUB_TOKEN only needs read access for actions/checkout. Addresses CodeQL code-scanning alert #115 ("Workflow does not contain permissions"). Matches the pattern already used by the other workflows under .github/workflows/. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |