ci: stop pinning pnpm to v10 (fixes 6h frontend-test timeout)

[JohnMcLear]

Problem

Every Node.js Package run on this repo has been cancelled at the 6-hour job limit since ~May — including the current Dependabot checkout bump #89. The frontend job runs the full core test-ui suite, and every spec (the plugin's own define.spec.ts and core specs like a11y_dialogs/rtl_url_param) fails identically:

page.waitForSelector: Test timeout of 90000ms exceeded.
waiting for locator('iframe[name="ace_outer"]') to be visible

The editor iframe never renders, so all ~hundreds of specs burn 90s × retries until the job is cancelled.

Root cause

The workflows pin pnpm/action-setup to version: 10, but Etherpad core declares packageManager: pnpm@11.1.2. The CI log shows the forced downgrade:

Switching pnpm from v11.7.0 to v10.34.3...

Under that mismatch the backgrounded pnpm run dev server's lazy frontend build never produces a working editor bundle (the curl / readiness probe still passes because the landing page doesn't need the build), so every pad load times out.

This is not caused by #89's actions/checkout v6→v7 bump — that PR is just the latest victim. Verified by correlation across the fleet: every ether/* plugin that reads etherpad's pin via package_json_file (ep_align, ep_font_color, ep_headings2, ep_font_size, ep_cursortrace …) passes its frontend job in ~4 min; ep_define is the only one still on version: 10 and the only one cancelled at 6h. Locally, the editor loads fine with ep_define installed under pnpm 11.

Fix

Match the rest of the fleet:

• frontend / backend jobs (core checked out at ./etherpad-lite): package_json_file: ./etherpad-lite/package.json
• publish job (core checked out at repo root): drop version: and let action-setup auto-detect

After this lands, rebase #89 (@dependabot rebase) and it should go green.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

PR Summary by Qodo

CI: Use Etherpad’s pnpm packageManager pin instead of forcing v10
🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

Description

• Stop forcing pnpm v10 in CI to prevent frontend test runs from stalling.
• Read pnpm version from Etherpad core package.json for frontend/backend jobs.
• Let publish workflow auto-detect pnpm from the root core checkout.

Diagram

graph TD
  FE["Frontend tests job"] --> SETUP["pnpm/action-setup@v6"] --> COREPKG["etherpad-lite/package.json"]
  BE["Backend tests job"] --> SETUP --> COREPKG
  PUB["Publish job"] --> SETUP --> ROOTPKG["root package.json"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Explicitly pin pnpm to 11.x in workflows

• ➕ More obvious at-a-glance which pnpm version CI uses
• ➕ Avoids relying on action auto-detection behavior
• ➖ Requires manual updates whenever Etherpad core bumps pnpm
• ➖ Reintroduces drift risk between core and plugin CI

2. Centralize pnpm version in a shared CI variable

• ➕ Single place to update pnpm version for all jobs
• ➕ Avoids needing different paths for different checkouts
• ➖ Still duplicates Etherpad core’s source of truth
• ➖ Easy to forget to update when core changes packageManager

Recommendation: The current approach (use pnpm/action-setup package_json_file for the ./etherpad-lite checkout and auto-detect for the root checkout) is the best fit: it keeps CI aligned with Etherpad core’s declared packageManager pin and avoids future version drift without adding another version source to maintain.

Files changed (3) +2 / -3

Bug fix (1) +1 / -1

frontend-tests.ymlStop pinning pnpm v10 in frontend CI job +1/-1

Stop pinning pnpm v10 in frontend CI job

• Switches pnpm/action-setup to read the pnpm version from etherpad-lite/package.json instead of forcing v10. This prevents the pnpm version drift that caused the dev server build to never produce a working editor bundle in CI.

.github/workflows/frontend-tests.yml

Other (2) +1 / -2

backend-tests.ymlRead pnpm version from checked-out Etherpad core +1/-1

Read pnpm version from checked-out Etherpad core

• Replaces the hardcoded pnpm v10 install with packageManager-based detection via etherpad-lite/package.json. Keeps backend CI aligned with the core’s pnpm pin to avoid mismatched tooling.

.github/workflows/backend-tests.yml

npmpublish.ymlLet publish workflow auto-detect pnpm version +0/-1

Let publish workflow auto-detect pnpm version

• Removes the pnpm v10 pin so pnpm/action-setup can auto-detect from the repo-root checkout. Ensures publish uses the pnpm version implied by the checked-out core package metadata.

.github/workflows/npmpublish.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Publish pnpm not pinned 🐞 Bug ☼ Reliability

Description

In the npm publish workflow, pnpm/action-setup no longer specifies a pnpm version or a
package_json_file, so the exact pnpm version used by the publish job is not pinned by this repo’s
configuration. This can lead to non-reproducible publishes and unexpected future failures when pnpm
behavior changes (especially with pnpm i --frozen-lockfile).

Code

.github/workflows/npmpublish.yml[R34-37]

      - uses: pnpm/action-setup@v6
        name: Install pnpm
        with:
-          version: 10
          run_install: false

Evidence

The pnpm setup step in the publish workflow has no version and no package_json_file, so the
workflow itself no longer pins which pnpm version will be used. Additionally, this repo’s
package.json does not declare packageManager, so the repository cannot self-describe the intended
pnpm version.

.github/workflows/npmpublish.yml[30-38]
package.json[1-29]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The publish workflow installs pnpm without specifying `version` or `package_json_file`, so the pnpm version is not explicitly controlled by this repository.

## Issue Context
The job later runs `pnpm i --frozen-lockfile`, which is sensitive to pnpm version/lockfile semantics.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[30-38]
- package.json[1-29]

## Suggested fix
Choose one deterministic approach:
1) Add a `packageManager` field to this repo’s `package.json` (e.g., `"packageManager": "pnpm@11.1.2"`) and update the workflow to set `package_json_file` to this repo’s `package.json` (place the pnpm setup step after the checkout of this repo).
2) Alternatively, keep the current step order but explicitly set `package_json_file: ./package.json` to make it clear which checkout’s `package.json` is used for pnpm selection.
3) Or explicitly pin `version: <desired pnpm version>` in the workflow.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Misleading pnpm comment 🐞 Bug ⚙ Maintainability

Description

The publish workflow still contains a comment describing issues when requesting pnpm 10.x via
pnpm/action-setup, but this PR removed the version: 10 pin. This inconsistency can mislead future
maintainers debugging CI/publish behavior.

Code

.github/workflows/npmpublish.yml[R34-37]

      - uses: pnpm/action-setup@v6
        name: Install pnpm
        with:
-          version: 10
          run_install: false

Evidence

The workflow no longer pins pnpm to v10 in the pnpm/action-setup step, but the later comment still
explicitly references requesting version 10.x and associated failure modes.

.github/workflows/npmpublish.yml[34-37]
.github/workflows/npmpublish.yml[76-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A comment in the publish workflow refers to requesting `version: 10.x` from pnpm/action-setup, but the workflow no longer requests pnpm 10.

## Issue Context
This is now misleading documentation in the CI pipeline.

## Fix Focus Areas
- .github/workflows/npmpublish.yml[72-80]
- .github/workflows/npmpublish.yml[34-37]

## Suggested fix
Either:
- Update the comment to reflect the new pnpm selection approach (auto-detect / package_json_file / pinned version), or
- Remove the comment block if it no longer applies.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---