test(gate): activate every activatable plugin, not just book-club#239
Conversation
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAggiunto un nuovo blocco di test end-to-end (Phase 19.5) in tests/full-test.spec.js che valida l'attivazione di tutti i plugin inattivi tramite l'admin panel, verificando successo della risposta API e stato is_active nel DB per ciascun plugin. ChangesTest attivazione plugin
Estimated code review effort: 1 (Trivial) | ~5 minuti 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…t just book-club The book-club activation failure (#233) reached a real install because the gate never activated the plugin. The same blind spot exists for every other bundled plugin, and for any added in the future. Add a check to plugin-integrity.spec.js (test 6) that enumerates the plugins from the DB and activates every one that isn't active yet, asserting its onActivate/ ensureSchema succeeds (a failure comes back from the activate endpoint as {success:false,"Schema activation failed for: <table>"}) and that it ends up active. The list is read from the DB, so a plugin added later is covered automatically. This lives in plugin-integrity rather than full-test on purpose: it's a dedicated, plugin-focused spec that already runs post-install AND post-upgrade in both CI and scripts/reinstall-test.sh (Test A + Test B), and it isn't hostage to full-test's 20-phase serial chain. The three external-API plugins (discogs/deezer/musicbrainz) are excluded — test 4 already documents that their onActivate throws offline, so they stay opt-in.
f66b016 to
656655b
Compare
…ner's full-test's todayISO()/futureISO() built the date from new Date()'s local fields, i.e. in the runner's timezone. CI runners are UTC; the app validates reservation start dates against DateHelper::today() in the app timezone (Europe/Rome by default). When CI runs late in the UTC day, UTC "today" is Rome's yesterday, so the server rejects the reservation as past_date and Phase 15.2 "Request loan" fails — a real, time-of-day-dependent flake unrelated to any code change (it passes when CI runs earlier in the UTC day). Three consecutive 23:xx-UTC runs reproduced it 3/3. Format both dates in Europe/Rome via Intl so the test's "today" matches the server's regardless of the runner clock. Verified: at 23:30 UTC the helper now returns Rome's date (next calendar day) instead of the UTC day.
|
Bundled a second, unrelated fix into this branch because it was blocking the CI from ever going green: |
The book-club activation failure (#233) reached a real install because the gate never activated the plugin. The same blind spot exists for every other bundled plugin, and for any added in the future.
Adds test 6 to
plugin-integrity.spec.js: it enumerates the plugins from the DB and activates every one that isn't active yet through the real/admin/plugins/{id}/activateendpoint, assertingonActivate/ensureSchemasucceeds (a failure comes back as{success:false, "Schema activation failed for: <table>"}) and that it ends up active. The list is read from the DB, so a plugin added later is covered automatically.Why plugin-integrity and not full-test: it's a dedicated, plugin-focused spec that already runs post-install AND post-upgrade in both CI and
scripts/reinstall-test.sh(Test A + Test B), and it isn't hostage to full-test's 20-phase serial chain.The three external-API plugins (discogs/deezer/musicbrainz) are excluded — test 4 already documents that their
onActivatethrows when the CI host is offline, so they stay opt-in. (An earlier draft of this PR tried to activate all inactive plugins inside full-test; that would have failed on exactly those three.)