feat: Add test step to check etherpad works offline

[Gared]

This PR adds a test case for this issue: #7911
to make sure etherpad is able to start up without network access

[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 (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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

PR Summary by Qodo

CI: Add regression step to verify Etherpad boots with no network access
🧪 Tests ⚙️ Configuration changes 🕐 10-20 Minutes

Walkthroughs

Description

• Add CI regression step to start Etherpad with --network none.
• Poll container healthcheck until healthy or timeout, then fail CI on regression.
• Ensure offline container logs are captured and resources cleaned up.

Diagram

graph TD
  A["GitHub Actions: docker.yml"] --> B["Step: run Etherpad offline"] --> C["docker run --network none"] --> D["Container: test-offline"] --> E{"Health status?"}
  E -->|"healthy"| F["Mark ok=1"] --> G["docker rm -f"] --> H["Pass step"]
  E -->|"starting"| I["sleep 2s & retry"] --> E
  E -->|"unexpected / exited"| J["print logs"] --> G
  G --> K{"ok==1?"}
  K -->|"no"| L["Fail job"]
  K -->|"yes"| H

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disconnect network after start (docker network disconnect)

• ➕ Lets the container perform initial setup that may require DNS before enforcing offline mode
• ➕ Can test runtime resilience to network loss in addition to offline boot
• ➖ Does not specifically guarantee 'boot from cold start with no network'
• ➖ Adds complexity (requires a user-defined network and extra steps)

2. Host-level egress blocking in CI (iptables/firewalld)

• ➕ More closely simulates hard egress policies, including non-Docker traffic
• ➕ Can validate that nothing escapes via alternate interfaces
• ➖ Higher CI risk and flakiness; needs privileged runner permissions
• ➖ Harder to scope to a single container/test

Recommendation: Keep the current docker run --network none approach: it directly asserts the regression goal (Etherpad can boot without network) with minimal CI complexity. If future issues require also validating behavior under mid-run network loss, add a separate step using docker network disconnect rather than weakening this cold-start offline assertion.

File Changes

Tests (1)

docker.yml Add CI regression step to boot Etherpad with disabled Docker networking +26/-0

Add CI regression step to boot Etherpad with disabled Docker networking

• Introduces a new workflow step that runs the built Etherpad image with '--network none' and tails logs for debugging. The step polls the container health status for up to ~120 seconds, cleans up the container, and fails the job if it never becomes healthy or exits unexpectedly.

.github/workflows/docker.yml

---