Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: acda60a5b3aedca5d01f11a6ffd71fdcbcedd65a https://github.com/xwiki/xwiki-dev-llm/commit/acda60a5b3aedca5d01f11a6ffd71f... Author: Vincent Massol <[email protected]> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs Log Message: ----------- [Misc] Stay quiet about an Environment Tests run that used stale jars * Add `stale-snapshot` to `fixState`. The Environment Tests job builds only the test modules it was given and takes the rest of its WAR from the last snapshot deployed to Nexus, so a commit carrying a test *and* the production code that test needs is red there until the next deployment — with stack-trace line numbers read from the old file, which is exactly what a defect in the new test looks like. * Bound the snapshot by build revisions rather than by parsing a log: XWiki's CI runs Maven without transfer progress, so no build log names a resolved artifact (measured on Environment Tests `#1377`: 192 KB of step console, no download line, and the wfapi node log serves only a 10 KiB tail anyway). Two `buildRevision` calls and one compare, no Nexus call, no `consoleText`. * Take the revision of the most recent *completed* main build that had started when the environment build did — an upper bound, since a build still running has deployed nothing. Erring detects less, which is the direction a detector that buys silence must fail in. Not the last *green* one: platform's main job has been `FAILURE` on every build for days, the quality gate running after the deploy, so a green one would date the snapshot to last week. * Require one commit in that gap to touch the failing test class *and* a production file. A test change here and a production change there is an ordinary pair of commits, and reading it as the trap would silence a real breakage on a coincidence. Page objects and the docker test framework are not production: the job builds those. * Evaluate it before the forward-fix and in-flight gates. It is the only value of the three that says the test was never broken, and reporting a fix for it implies there was something to fix. * Set it only for a test failing in the environment job alone — the main job builds everything from source, so a test red there is red for real — which needs the new `failingJobs` field, `window.job` naming only the job that saw it break first. And only where the incident's first bad build is the build being examined: one that survived the next run met jars that had caught up. Verified against xwiki-platform/master, where Environment Tests `#1377` started 13 minutes after a commit that pushed `VersionIT` and `XWikiHibernateVersioningStore` together, and the incident that S1 reported as "possibly fixed already" now reads as the trap it is. The two blocknote flickers pass every guard and stay `null`, no commit in the gap naming them. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Commit: b4d19df9ddb9a9e73e475b9bd1b1cb5f718958c8 https://github.com/xwiki/xwiki-dev-llm/commit/b4d19df9ddb9a9e73e475b9bd1b1cb... Author: Vincent Massol <[email protected]> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs Log Message: ----------- Merge pull request #153 from xwiki/ci-check-stale-snapshot [Misc] Stay quiet about an Environment Tests run that used stale jars Compare: https://github.com/xwiki/xwiki-dev-llm/compare/e26dfc84128b...b4d19df9ddb9 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications