chore(release): park the non-functional ep_etherpad npm publish

[JohnMcLear]

PR Summary by Qodo

Park ep_etherpad npm publish workflow behind explicit confirm input
⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

Walkthroughs

User Description

Why

While cutting 3.3.0 the npm-publish step (releaseEtherpad.yaml) failed with E404 PUT https://registry.npmjs.org/ep_etherpad. Investigating why we publish it at all, the answer is: no functional reason.

• ep_etherpad has 0 dependents on npm, and nothing in this repo depends on it.
• Plugins import ep_etherpad-lite resolved from the local core install; plugin CI clones ether/etherpad rather than npm install-ing core.
• Etherpad is run via git clone / Docker / zip / snap — never npm install.
• The publish has been failing because ep_etherpad 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 all shipped fine without it.

The 3.3.0 release itself is complete (GitHub Release, tags, docs, Docker, snap); only this orphaned publish was "failing".

What this does

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, with a guard step that fails fast with a clear message instead of the confusing 404.
• Document the status in the workflow header and the AGENTS.MD → Releasing section (npm publish marked PARKED / skip for a normal release).

Nothing is deleted — this is the package owner's call. @SamTV12345, since you own the ep_etherpad npm package: do you want to (a) finish the trusted-publisher config (npmjs.com → ep_etherpad → Settings → Trusted Publisher → repo ether/etherpad, workflow releaseEtherpad.yml) to revive it, or (b) drop the workflow entirely? Parked pending your decision.

🤖 Generated with Claude Code

AI Description

• Gate the ep_etherpad npm publish workflow behind an explicit confirm: true input.
• Fail fast with a clear “PARKED” message when confirmation is not provided.
• Document that npm publish is not part of the standard release process.

Diagram

graph TD
  A["Maintainer"] --> B["releaseEtherpad workflow_dispatch"] --> C{"confirm=true?"}
  C -- "No" --> D["Guard step: fail fast"]
  C -- "Yes" --> E["Publish steps"] --> F[("npm registry: ep_etherpad")]

  subgraph Legend
    direction LR
    _actor["Actor"] ~~~ _dec{"Decision"} ~~~ _ext[("External system")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Configure npm OIDC trusted publisher and keep publishing

• ➕ Restores parity between GitHub releases and npm package versions
• ➕ Keeps an option for consumers that might rely on npm in the future
• ➖ Requires npm package owner action and ongoing maintenance
• ➖ Still publishes a package that currently has no demonstrated consumers

2. Remove the workflow entirely

• ➕ Eliminates a recurring failure mode and maintenance overhead
• ➕ Clarifies release process by removing dead steps
• ➖ Harder to reintroduce quickly if an external consumer appears
• ➖ Loses historical/intent context unless documented elsewhere

3. Move publish behind an environment protection gate (in addition to confirm)

• ➕ Adds a second, auditable safeguard (required reviewers)
• ➕ Prevents accidental runs even if confirm is toggled
• ➖ More GitHub configuration complexity
• ➖ Still doesn’t solve the trusted-publisher prerequisite

Recommendation: Parking behind an explicit confirm: true input is the best interim approach: it prevents accidental failures while preserving the workflow pending the npm owner’s decision. Longer-term, either (a) complete trusted-publisher setup if npm publish is desired, or (b) remove the workflow to reduce release surface area.

File Changes

Documentation (1)

AGENTS.MD Document npm publish as parked and skippable for normal releases +1/-1

Document npm publish as parked and skippable for normal releases

• Updates the release checklist to state that npm publishing the core as 'ep_etherpad' is parked, non-load-bearing, and currently fails due to missing trusted publisher configuration. Provides clear instructions to skip it for normal releases and notes how to revive or remove it.

AGENTS.MD

---

Other (1)

releaseEtherpad.yml Mark workflow as parked and require explicit confirm to run publish +32/-0

Mark workflow as parked and require explicit confirm to run publish

• Adds a prominent header explaining why the ep_etherpad npm publish is non-functional and not part of standard releases. Introduces a required boolean 'confirm' workflow_dispatch input and a guard step that fails fast with a clear error message unless explicitly confirmed.

.github/workflows/releaseEtherpad.yml

---

[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]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. YML/YAML naming mismatch 🐞 Bug ⚙ Maintainability

Description

The workflow file is releaseEtherpad.yml but the workflow display name and documentation also
refer to releaseEtherpad.yaml, creating ambiguous instructions for humans (dispatching vs.
configuring trusted publishing) and increasing operator error risk. Align the identifiers (or
explicitly document the difference between workflow file name vs workflow display name) to avoid
misconfiguration.

Code

.github/workflows/releaseEtherpad.yml[R15-20]

+# actually publish, the npm owner of `ep_etherpad` (samtv12345) must first
+# configure a trusted publisher: npmjs.com -> ep_etherpad -> Settings ->
+# Trusted Publisher -> repo `ether/etherpad`, workflow `releaseEtherpad.yml`.
+# Decision pending: finish that config, or remove this workflow. See AGENTS.MD.
name: releaseEtherpad.yaml
permissions:

Evidence

The workflow comment instructs configuring a trusted publisher for workflow releaseEtherpad.yml
while the workflow display name is releaseEtherpad.yaml; AGENTS.MD also references
releaseEtherpad.yaml while later mentioning releaseEtherpad.yml, demonstrating inconsistent
identifiers in the operator-facing guidance.

.github/workflows/releaseEtherpad.yml[15-20]
AGENTS.MD[214-235]

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 workflow header and AGENTS.MD use both `releaseEtherpad.yml` and `releaseEtherpad.yaml`, while the workflow’s display `name:` is `releaseEtherpad.yaml` and the file path is `releaseEtherpad.yml`. This ambiguity can cause operator confusion (e.g., when searching for the workflow to dispatch vs. when configuring trusted publishing).

## Issue Context
- GitHub Actions has both a workflow **file name** (path under `.github/workflows/`) and a workflow **display name** (`name:`).
- Your documentation and header comment currently mix these two identifiers.

## Fix Focus Areas
- .github/workflows/releaseEtherpad.yml[15-20]
- AGENTS.MD[214-235]

## Recommended change
Pick one of these approaches:
1) **Make naming consistent**: change the workflow display name to match the file, e.g. `name: releaseEtherpad.yml` or `name: releaseEtherpad`.
2) **Clarify explicitly** in both the workflow header and AGENTS.MD:
  - The workflow **file** is `.github/workflows/releaseEtherpad.yml` (used for trusted publisher configuration)
  - The workflow **display name** shown in the Actions UI is `releaseEtherpad.yaml` (used when humans look it up)
3) **Rename the file** to `.github/workflows/releaseEtherpad.yaml` (and update any references) if you want file and display name to match.

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

---