The smoke test could not fail, and other people's eyes

Four fixes, two of them serious, three of them found by the session porting
this into subscriptions.

1. THE SMOKE TEST COULD NOT FAIL. `wp eval-file` runs the file through eval()
   INSIDE A METHOD, so the top level is function scope. `$wc_edm_failures = 0`
   at the top and `global $wc_edm_failures` in the helper were two different
   variables: the helpers incremented the real global, the verdict read the
   local, and the local was always zero.

   Measured rather than reasoned. A deliberately false assertion added to the
   unmodified file:

       FAIL  DELIBERATE FAILURE — this run must go red
       All assertions passed on WordPress 7.1 with WooCommerce 11.1.0.
       EXIT=0

   and with the fix, the same forced failure:

       FAIL  DELIBERATE FAILURE — this run must go red
       1 assertion(s) failed on WordPress 7.1.
       EXIT=1

   The FAIL lines always printed, so failures found by reading the output were
   real finds. What was broken is the CI gate: a regression on either forge
   would have gone green. Four lines at the top now prove the counter reaches
   the verdict before anything relies on it — this is the one file whose whole
   job is to be able to go red, so it checks that it can.

2. `git ls-files` QUOTES NON-ASCII PATHS. "TESTMILJØ.md" comes back as the
   literal string "TESTMILJ\303\230.md", which matches no pattern in
   .distignore, so the file is kept — an internal document walking into the
   release zip with nothing said. Fixed in ci/dist-files.sh and in
   ci/static.sh's trailing-?> check, which had the same bug and would have
   silently skipped the file it exists to check. Verified by adding such a
   filename and watching it be excluded. `done < <(...)` rather than a pipe, or
   the loop runs in a subshell and the failure counter stops incrementing.

3. THE FEED CACHE WAS SIX HOURS, and Kristian hit it: a release published and
   his shop shown nothing. The reasoning ("WordPress checks twice a day") was
   wrong. WordPress gates its own check by screen in wp_update_plugins() — one
   minute on Dashboard → Updates, one hour on Plugins, 2–12 hours in the
   background — so WordPress is already the rate limiter and a longer cache
   only hides releases underneath it. Fifteen minutes now, pinned by an
   assertion.

4. The wp_update_plugins() assertion made a real HTTP request, because the
   force-check tests had just deleted the transient. It passed only because
   this feed repo is public, which made it measure the environment rather than
   the code. Re-primed first.

ci_in_container() replaces the inline docker plumbing in ci_php(), taken from
the subscriptions port: the script goes in as a file rather than interpolated
into `sh -c`, and --entrypoint sh matters for images whose entrypoint swallows
its arguments.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
kristianwind
2026-09-16 13:18:22 +02:00
co-authored by Claude Opus 5
parent 48119f2034
commit a1f6e54f9d
7 changed files with 156 additions and 38 deletions
+17 -3
View File
@@ -34,10 +34,24 @@ class WC_EDM_Updater {
const TRANSIENT = 'wc_edm_release_feed';
/**
* How long that cache lives. WordPress checks for updates twice a day; a
* shorter window would only add requests, a longer one would delay a fix.
* How long that cache lives.
*
* Six hours, originally, on the reasoning that WordPress checks twice a
* day anyway. That reasoning was wrong, and the symptom was a shop that
* had just been told a new version existed and was shown nothing.
*
* WordPress does not check twice a day when somebody is looking. It gates
* its own check by screen — one minute on Dashboard → Updates, one hour on
* the Plugins screen, twelve hours in the background (wp_update_plugins(),
* switch on current_filter()). This filter only runs when that check runs,
* so WordPress is already the rate limiter, and a cache longer than its
* cadence does nothing but hide new releases underneath it.
*
* Fifteen minutes is left only to absorb a burst — several calls in one
* request, or other code calling wp_update_plugins() with extra stats,
* which bypasses the gate above.
*/
const TTL = 6 * HOUR_IN_SECONDS;
const TTL = 15 * MINUTE_IN_SECONDS;
/**
* Hook into the update check for our own host only.