You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dual plugin generation (lines 57-60, 135-141, 425-439, 476-488): Add configuration for previous_stable.zip alongside new_release.zip. The script should now generate two versions of each plugin per cycle - one from the develop branch (new_release) and one from the trunk branch (previous_stable). This requires adding new config properties for the previous stable zip names, updating the cloneOrUpdatePlugin() method to accept a branch parameter, modifying moveZipToPlugin() to accept a custom target name, and updating configureForTestSuite() to set the previousStableZip property. The main cycle in runCycle() needs to be restructured to generate both zips sequentially with a git clean -fdx between them to prevent build artifact contamination.
WordPress update before tests (lines 68-69, 241-253, 486): Add a config flag UPDATE_WORDPRESS and create a new updateWordPress() method that runs npx wp-env start --update to update WordPress to the latest version before running tests. This should be called in the cycle after updating the E2E repo but before running tests. If the update fails, it should log the error but not stop the test execution.
Smart test results cleanup (lines 307-362): Modify the deleteOldTestResults() method to only delete passed test results older than 7 days while keeping failed results indefinitely. This requires checking each old result directory for a cucumber-report.json file, calling analyzeCucumberReport() to determine if tests passed or failed, and only deleting directories where all tests passed. The cleanup should log how many passed vs failed reports were processed.
Error handling improvements needed:
Lines 489-499: Add null check for resultTimestamp before attempting to analyze the cucumber report to prevent null pointer exceptions when no test results are saved
Line 195: Change error message from hardcoded "No WP Rocket ZIP file found" to use this.pluginName for proper plugin-agnostic messaging
Lines 135-141: Add git checkout <branch> before git reset --hard origin/<branch> to ensure the repository is actually on the correct branch when updating existing clones
Lines 476-488: Add git clean -fdx between generating the two plugin versions to remove build artifacts and prevent contamination
Configuration changes:
Add WP_ROCKET_PREVIOUS_STABLE_ZIP and BACKWPUP_PREVIOUS_STABLE_ZIP constants to specify the output filenames for trunk-based builds
Add UPDATE_WORDPRESS: true flag to enable/disable WordPress updates (can be set to false via environment variable if needed)
Keep 7-day retention for passed reports (changed from 4 days for all reports)
Approach: Implement all changes inside auto-e2e.js only, per @Miraeld's note. Full spec at .TemporaryItems/Issues/auto-e2e/issues/11-spec.md.
Effort: L · Risk: MEDIUM · Complexity: HIGH
Key decisions / findings from re-reading the current code and the live wp-rocket-e2e repo:
Confirmed wp-media/wp-rocket and wp-media/backwpup-pro both have live trunk and develop branches — dual-build as scoped is safe to implement.
wp-rocket-e2e gained a new PluginBuilder/APVM build system (utils/plugin-builder.ts, added 2026-07-07 — after this issue's comment) that already knows about previous_stable.zip / new_release.zip filenames for WP Rocket, triggered via E2E_WPR_PREV_REF / E2E_WPR_NEW_REF env vars in its own BeforeAll hook. Since auto-e2e.js won't set those env vars, there's no runtime collision — but it's worth the team's awareness that two independent systems now target the same filenames.
Needs a decision before implementation starts: the issue's literal suggestion for WP update (npx wp-env start --update) starts a local Docker WordPress environment. This repo has no .wp-env.json anywhere, and the actual test target is a remote, SSH-accessible server (already used by getSiteVersions() via runRemoteWpCli()). Recommendation: implement updateWordPress() using the existing runRemoteWpCli('core update') helper instead — same non-fatal-on-failure behavior, but it actually reaches the system under test. See "Implementation Options" in the spec for both options side by side.
Minor, non-blocking: wp-rocket-e2e's new PluginBuilder does not define a "previous stable" build for BackWPUp, and no BackWPUp feature currently tests upgrades. The issue still explicitly asks for BACKWPUP_PREVIOUS_STABLE_ZIP; recommend implementing it anyway for parity/forward-compatibility (cheap), but flagging that it's currently unconsumed.
Test plan: No test framework/CI exists in this repo (no package.json); verification is a manual smoke test on a live dedicated test server (full details in the spec's "Smoke test scenario" section) — run one full cycle and confirm both zips are built from the correct branches, WP update runs (or fails non-fatally) before tests, and cleanup only deletes passed results older than 7 days.
Dual plugin generation (new_release from develop + previous_stable from trunk) — largest/riskiest slice, ships last
Team: please confirm (a) whether to proceed with 4 separate PRs as above, and (b) the WP-update mechanism decision (Option 2B recommended) before implementation starts.
Activity
Miraeld commentedon Dec 5, 2025
Nothing to do with wp-rocket-e2e repo,
But everything has to be done in https://github.com/wp-media/auto-e2e
Dual plugin generation (lines 57-60, 135-141, 425-439, 476-488): Add configuration for
previous_stable.zipalongsidenew_release.zip. The script should now generate two versions of each plugin per cycle - one from thedevelopbranch (new_release) and one from thetrunkbranch (previous_stable). This requires adding new config properties for the previous stable zip names, updating thecloneOrUpdatePlugin()method to accept a branch parameter, modifyingmoveZipToPlugin()to accept a custom target name, and updatingconfigureForTestSuite()to set thepreviousStableZipproperty. The main cycle inrunCycle()needs to be restructured to generate both zips sequentially with agit clean -fdxbetween them to prevent build artifact contamination.WordPress update before tests (lines 68-69, 241-253, 486): Add a config flag
UPDATE_WORDPRESSand create a newupdateWordPress()method that runsnpx wp-env start --updateto update WordPress to the latest version before running tests. This should be called in the cycle after updating the E2E repo but before running tests. If the update fails, it should log the error but not stop the test execution.Smart test results cleanup (lines 307-362): Modify the
deleteOldTestResults()method to only delete passed test results older than 7 days while keeping failed results indefinitely. This requires checking each old result directory for acucumber-report.jsonfile, callinganalyzeCucumberReport()to determine if tests passed or failed, and only deleting directories where all tests passed. The cleanup should log how many passed vs failed reports were processed.Error handling improvements needed:
resultTimestampbefore attempting to analyze the cucumber report to prevent null pointer exceptions when no test results are savedthis.pluginNamefor proper plugin-agnostic messaginggit checkout <branch>beforegit reset --hard origin/<branch>to ensure the repository is actually on the correct branch when updating existing clonesgit clean -fdxbetween generating the two plugin versions to remove build artifacts and prevent contaminationConfiguration changes:
WP_ROCKET_PREVIOUS_STABLE_ZIPandBACKWPUP_PREVIOUS_STABLE_ZIPconstants to specify the output filenames for trunk-based buildsUPDATE_WORDPRESS: trueflag to enable/disable WordPress updates (can be set to false via environment variable if needed)Mai-Saad commentedon Sep 20, 2026
Note
Generated by the AI delivery pipeline (grooming-agent · claude-sonnet-5).
Grooming Plan — Issue #11
Approach: Implement all changes inside
auto-e2e.jsonly, per @Miraeld's note. Full spec at.TemporaryItems/Issues/auto-e2e/issues/11-spec.md.Effort: L · Risk: MEDIUM · Complexity: HIGH
Key decisions / findings from re-reading the current code and the live
wp-rocket-e2erepo:wp-media/wp-rocketandwp-media/backwpup-proboth have livetrunkanddevelopbranches — dual-build as scoped is safe to implement.wp-rocket-e2egained a newPluginBuilder/APVM build system (utils/plugin-builder.ts, added 2026-07-07 — after this issue's comment) that already knows aboutprevious_stable.zip/new_release.zipfilenames for WP Rocket, triggered viaE2E_WPR_PREV_REF/E2E_WPR_NEW_REFenv vars in its ownBeforeAllhook. Sinceauto-e2e.jswon't set those env vars, there's no runtime collision — but it's worth the team's awareness that two independent systems now target the same filenames.npx wp-env start --update) starts a local Docker WordPress environment. This repo has no.wp-env.jsonanywhere, and the actual test target is a remote, SSH-accessible server (already used bygetSiteVersions()viarunRemoteWpCli()). Recommendation: implementupdateWordPress()using the existingrunRemoteWpCli('core update')helper instead — same non-fatal-on-failure behavior, but it actually reaches the system under test. See "Implementation Options" in the spec for both options side by side.wp-rocket-e2e's newPluginBuilderdoes not define a "previous stable" build for BackWPUp, and no BackWPUp feature currently tests upgrades. The issue still explicitly asks forBACKWPUP_PREVIOUS_STABLE_ZIP; recommend implementing it anyway for parity/forward-compatibility (cheap), but flagging that it's currently unconsumed.Test plan: No test framework/CI exists in this repo (no
package.json); verification is a manual smoke test on a live dedicated test server (full details in the spec's "Smoke test scenario" section) — run one full cycle and confirm both zips are built from the correct branches, WP update runs (or fails non-fatally) before tests, and cleanup only deletes passed results older than 7 days.PR Splitting Plan (effort = L)
zipPlugin()error message,cloneOrUpdatePlugin()checkout-before-reset fix,runCycle()null-deref guard onresultTimestamp/reportAnalysisdeleteOldTestResults()rewriteUPDATE_WORDPRESSconfig +updateWordPress()method + wiring intorunCycle()cloneOrUpdatePlugin(branch)parameterization,cleanCloneDir(),moveZipToPlugin(zipPath, targetName),configureForTestSuite(), fullrunCycle()restructuring, README updateTeam: please confirm (a) whether to proceed with 4 separate PRs as above, and (b) the WP-update mechanism decision (Option 2B recommended) before implementation starts.
fix: capture new-release commit hash before switching to trunk build
Mai-Saad commentedon Sep 20, 2026
Note
Generated by the AI delivery pipeline (orchestrator · Claude Sonnet 5).
PR: #21 | Status: READY FOR REVIEW