September 2026 - notifications

[xwiki/xwiki-platform] 9334a1: XWIKI-24172: RecycleBinIT#restore is flickering (#...
by XWiki Notifications 21 Sep '26

21 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 9334a11ea9b0163985b9201117377a3bd3ec6ef7 https://github.com/xwiki/xwiki-platform/commit/9334a11ea9b0163985b920111737… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-21 (Mon, 21 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-docker/src/test/it/org/xwiki/flamingo/test/docker/RecycleBinIT.java M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-pageobjects/src/main/java/org/xwiki/flamingo/skin/test/po/AttachmentsPane.java Log Message: ----------- XWIKI-24172: RecycleBinIT#restore is flickering (#6465) * The test uploaded an attachment with setFileToUpload(), which is asynchronous and returns immediately, and then went straight on to open the "More actions" menu to delete the page. When the upload completes, attachments.js reacts to xwiki:html5upload:done by refreshing the attachments live data and then rewriting the "Attachments" entry of that same "More actions" menu, in which tmAttachments and tmActionDelete are siblings. The menu was thus being rewritten while the test clicked through it, the Delete click could be lost, and the subsequent clickYes() then found no confirmation button on what was still the view page. * Wait for the upload notification and for the attachments count to be refreshed before deleting. The count is the last thing that chain writes, so waiting for it proves the menu rewrite is over; the upload notification alone is not enough since it is shown before the live data refresh, which is a network round trip and is exactly the race window. * Add AttachmentsPane#waitForNumberOfAttachments() for this, so that any other test uploading an attachment before using the "More actions" menu can rely on it. * Verified on chrome / mysql latest / tomcat 11-jdk25, the only configuration in which the test fails on the CI (2 failures out of 12 runs there over the last 28 days, 0 out of 539 elsewhere). Co-authored-by: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[xwiki/xwiki-platform] 497eca: XWIKI-24172: RecycleBinIT#restore is flickering
by XWiki Notifications 21 Sep '26

21 Sep '26

Branch: refs/heads/XWIKI-24172-recyclebin-restore-flicker Home: https://github.com/xwiki/xwiki-platform Commit: 497ecaf6ed52d54972859d02403426757e8e9d1f https://github.com/xwiki/xwiki-platform/commit/497ecaf6ed52d54972859d024034… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-21 (Mon, 21 Sep 2026) Changed paths: M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-docker/src/test/it/org/xwiki/flamingo/test/docker/RecycleBinIT.java M xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-pageobjects/src/main/java/org/xwiki/flamingo/skin/test/po/AttachmentsPane.java Log Message: ----------- XWIKI-24172: RecycleBinIT#restore is flickering * The test uploaded an attachment with setFileToUpload(), which is asynchronous and returns immediately, and then went straight on to open the "More actions" menu to delete the page. When the upload completes, attachments.js reacts to xwiki:html5upload:done by refreshing the attachments live data and then rewriting the "Attachments" entry of that same "More actions" menu, in which tmAttachments and tmActionDelete are siblings. The menu was thus being rewritten while the test clicked through it, the Delete click could be lost, and the subsequent clickYes() then found no confirmation button on what was still the view page. * Wait for the upload notification and for the attachments count to be refreshed before deleting. The count is the last thing that chain writes, so waiting for it proves the menu rewrite is over; the upload notification alone is not enough since it is shown before the live data refresh, which is a network round trip and is exactly the race window. * Add AttachmentsPane#waitForNumberOfAttachments() for this, so that any other test uploading an attachment before using the "More actions" menu can rely on it. * Verified on chrome / mysql latest / tomcat 11-jdk25, the only configuration in which the test fails on the CI (2 failures out of 12 runs there over the last 28 days, 0 out of 539 elsewhere). Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications

1 0

[[email protected]][Issue] Updates for XWIKI-24172: RecycleBinIT#restore is flickering
by XWiki Notifications 20 Sep '26

20 Sep '26

1 0

[[email protected]][Issue] Updates for XWIKI-25026: AutoSaveIT#autoSavesOnlyOnceWhenTwoClientsEdit is flickering
by XWiki Notifications 20 Sep '26

20 Sep '26

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/tags/v1.12.17 Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 37d9e7: [Misc] Release 1.12.17
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: 37d9e7df5b00eff4984955425d0fe3ffdfaacaee https://github.com/xwiki/xwiki-dev-llm/commit/37d9e7df5b00eff4984955425d0fe… Author: github-actions[bot] <41898282+github-actions[bot](a)users.noreply.github.com> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json Log Message: ----------- [Misc] Release 1.12.17 * content edits only (no capability added or removed) To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/heads/ci-check-closed-flicker-issues Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 2f6f65: [Misc] Make the CI sweep notice a flicker the team...
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: 2f6f65a238da63a26452a49672f074569c0c293c https://github.com/xwiki/xwiki-dev-llm/commit/2f6f65a238da63a26452a49672f07… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/okf/servers/jira.md M xwiki/scripts/jira-flickers.mjs M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs Log Message: ----------- [Misc] Make the CI sweep notice a flicker the team already fixed The sweep could tell that a test was flickering, but not that a fix for it already existed on another branch, so it offered to file an issue for a flicker JIRA had tracked and closed months earlier. * Wire the closed-flicker lookup into the sweep as `jiraClosed`. The lookup existed in jira-flickers.mjs and was never called, so §5's "if the flicker matches a closed issue, comment on it" rule had no data to fire on. * Withhold `flickerGroup` when a closed issue names the test, which is what actually stops the duplicate being filed. * Carry `fixVersions`, so the report can tell "the fix never shipped on this branch" (a backport candidate for xwiki-backport) from "it shipped here and did not hold" (comment on the issue, never a new one). * Page the JIRA search. The closed flickers are past 270 and the single request asked for 200, so the tail was dropped silently — a lookup that answers "no issue" for a test that has one. * Answer with the newest issue when a test has been filed more than once, and list the earlier keys. JIRA returns an unordered page and the Map kept whichever arrived last, which on NavigationPanelAdministrationIT meant answering with a 2024 issue whose fix shipped everywhere instead of the 2026 one that did not, i.e. reporting a live backport gap as settled. * Record the two JQL traps on the "Flickering Test" field in the OKF, and the rule that not every branch is a backport target. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 4b531c298512073d3cb4d1876a7be02c95d2dd47 https://github.com/xwiki/xwiki-dev-llm/commit/4b531c298512073d3cb4d1876a7be… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/okf/servers/jira.md M xwiki/scripts/jira-flickers.mjs Log Message: ----------- [Misc] Keep the flicker-lookup traps out of the always-loaded JIRA file okf/servers/jira.md is read whenever any JIRA topic comes up, and its declared scope is access, when to file at all, and the Component / Affects / Fix Version conventions. JQL quirks on one custom field and a de-duplication rule for a lookup are not that, and every session filing an ordinary bug was paying for them. * Move the two "Flickering Test" JQL traps into the header of jira-flickers.mjs, which is the file you are reading if you are about to get them wrong, and which costs nothing until you open it. Both consumers of the join (xwiki-ci-check, xwiki-release-test-triage) already go through it. * Leave one routing line in jira.md: use the shared module rather than writing the query. Routing is what actually prevents the mistake; the detail is not. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: bee59b824b17c6531b59fd1fff2abc7bf7725fb4 https://github.com/xwiki/xwiki-dev-llm/commit/bee59b824b17c6531b59fd1fff2ab… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/skills/xwiki-knowledge/SKILL.md Log Message: ----------- [Misc] Gate OKF additions on who reads the file, not on the topic The EXTEND checklist guarded `instructions/xwiki-org.md` as "the always-on file", but had no notion that some OKF *topic* files are themselves hot. That is the hole this PR's own first draft fell into: JQL quirks from one CI lookup went into okf/servers/jira.md because they were "about JIRA", and every session filing an ordinary bug paid for them. * Add a gate pricing an addition against the file's readers: does someone doing the ordinary thing this file is for need it? * Extend "Right home" with the case that produced it — a trap a shared script already handles belongs in that script's header, with at most a routing line in the OKF, because two copies drift and the prose one goes stale. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 03e58f6ed4e2c01df5d546c4a4bba701804f7998 https://github.com/xwiki/xwiki-dev-llm/commit/03e58f6ed4e2c01df5d546c4a4bba… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/okf/processes/release.md M xwiki/scripts/jira-flickers.mjs M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs Log Message: ----------- [Misc] Say each of these rules once, in the file that owns it Self-review of this PR against the gate it adds: it stated the same thing in several places, and duplicated a policy that already had a home. * Move the "never name the unsupported LTS line in a public artifact" rule into the release.md bullet that already owns the branch policy — it was missing from the OKF, and I had written a second, worse copy of the whole policy into the CI-sweep skill. That skill now states only what follows from it there. * Drop the repeated "which is how a duplicate gets filed" rationale: once, in the module header that exists to say why to use it. * Drop the second jiraClosed comment in ci-check.mjs; SKILL.md §3 is where the field is explained and the declaration already points there. * Put `earlier` on every entry, so a caller need not know whether the field or the summary fallback answered. * Look the group's issue up once instead of twice. * "four branches have run it" was this week's number, not a rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: d44e5a59e53616984832276b1847ea8923cf9add https://github.com/xwiki/xwiki-dev-llm/commit/d44e5a59e53616984832276b1847e… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/okf/processes/release.md M xwiki/okf/servers/jira.md M xwiki/scripts/jira-flickers.mjs M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs M xwiki/skills/xwiki-knowledge/SKILL.md Log Message: ----------- Merge pull request #166 from xwiki/ci-check-closed-flicker-issues [Misc] Make the CI sweep notice a flicker the team already fixed Compare: https://github.com/xwiki/xwiki-dev-llm/compare/eba126929781...d44e5a59e536 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 03e58f: [Misc] Say each of these rules once, in the file t...
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/heads/ci-check-closed-flicker-issues Home: https://github.com/xwiki/xwiki-dev-llm Commit: 03e58f6ed4e2c01df5d546c4a4bba701804f7998 https://github.com/xwiki/xwiki-dev-llm/commit/03e58f6ed4e2c01df5d546c4a4bba… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/okf/processes/release.md M xwiki/scripts/jira-flickers.mjs M xwiki/skills/xwiki-ci-check/SKILL.md M xwiki/skills/xwiki-ci-check/tools/ci-check.mjs Log Message: ----------- [Misc] Say each of these rules once, in the file that owns it Self-review of this PR against the gate it adds: it stated the same thing in several places, and duplicated a policy that already had a home. * Move the "never name the unsupported LTS line in a public artifact" rule into the release.md bullet that already owns the branch policy — it was missing from the OKF, and I had written a second, worse copy of the whole policy into the CI-sweep skill. That skill now states only what follows from it there. * Drop the repeated "which is how a duplicate gets filed" rationale: once, in the module header that exists to say why to use it. * Drop the second jiraClosed comment in ci-check.mjs; SKILL.md §3 is where the field is explained and the declaration already points there. * Put `earlier` on every entry, so a caller need not know whether the field or the summary fallback answered. * Look the group's issue up once instead of twice. * "four branches have run it" was this week's number, not a rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] bee59b: [Misc] Gate OKF additions on who reads the file, n...
by XWiki Notifications 20 Sep '26

20 Sep '26

Branch: refs/heads/ci-check-closed-flicker-issues Home: https://github.com/xwiki/xwiki-dev-llm Commit: bee59b824b17c6531b59fd1fff2abc7bf7725fb4 https://github.com/xwiki/xwiki-dev-llm/commit/bee59b824b17c6531b59fd1fff2ab… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-20 (Sun, 20 Sep 2026) Changed paths: M xwiki/skills/xwiki-knowledge/SKILL.md Log Message: ----------- [Misc] Gate OKF additions on who reads the file, not on the topic The EXTEND checklist guarded `instructions/xwiki-org.md` as "the always-on file", but had no notion that some OKF *topic* files are themselves hot. That is the hole this PR's own first draft fell into: JQL quirks from one CI lookup went into okf/servers/jira.md because they were "about JIRA", and every session filing an ordinary bug paid for them. * Add a gate pricing an addition against the file's readers: does someone doing the ordinary thing this file is for need it? * Extend "Right home" with the case that produced it — a trap a shared script already handles belongs in that script's header, with at most a routing line in the OKF, because two copies drift and the prose one goes stale. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0