ci-success omits e2e-gtk-wayland and e2e-gtk-wayland-drag

[charliek]

Found by the plan-023 adversarial review of ci.yml (2026-08-09). Pre-existing and deliberately left out of that plan's scope, because changing the required-check set is a repo-policy decision.

The gap

ci-success is the single required check on main (and release.yml's ci-gate refuses to release unless it is green on the tagged commit). Its needs list is:

needs: [changes, rust-lint, harness-unit, themes-parity, rust-build,
        swift-mac, gtk-build, iced-build-e2e, iced-release, e2e-gtk, e2e-mac]

Two e2e lanes that exist as jobs are not in it:

• e2e-gtk-wayland
• e2e-gtk-wayland-drag

So two of the five e2e lanes can fail without the required check noticing. The drag lane is the only automated coverage of the cage+uinput Wayland pointer-drag guard — the tier that cannot run in Docker and needs a real kernel with /dev/uinput.

Why it is worth deciding rather than just fixing

Adding them is a two-place edit (needs and the separately-maintained results string — they are not derived from each other, which is its own latent trap). But it also makes them blocking, and the Wayland lanes are the most environment-sensitive in the suite. Making a flaky lane required is how a release gets blocked at a bad moment. That is an owner call, not a mechanical one.

Options:

1. Add both to ci-success. Strongest guarantee; accepts their flake risk on the release path.
2. Add e2e-gtk-wayland only, leave the uinput drag lane advisory — it is the most environment-dependent of the two.
3. Leave as-is and document it, so the next person reading the required-check list knows the omission is deliberate rather than an oversight.

Related, already fixed

The same review found a live greenwash one level up: changes was in needs but omitted from the results string, so a failure in the job that gates every other job skipped them all and ci-success went green with nothing built. Fixed in the plan-023 release-smoke PR — same class as the #306 abandoned incident the step's own comment describes.

That fix is the reason this one is worth looking at: the needs/results duplication means membership has to be maintained twice, and it has already drifted twice.

Refs

• .github/workflows/ci.yml — ci-success (needs + the results string), e2e-gtk-wayland, e2e-gtk-wayland-drag
• .github/workflows/release.yml — ci-gate, which trusts this check
• Plan 023 §D5 item 5

[charliek]

Half of this landed in #329 (plan 024, W-B), and the other half turned out to need its own issue.

Done: e2e-gtk-wayland is now in ci-success and its continue-on-error is gone. e2e-gtk's own real-input continue-on-error went with it — that job was already in ci-success, so a soft step inside it made the required gate only a partial one. Membership is derived from toJSON(needs) now, so adding the job was a one-line change instead of two hand-synced lists.

Not done, deliberately: e2e-gtk-wayland-drag stays out. Re-measuring reliability from the step logs — the only signal that survives continue-on-error, since both the job conclusion and the REST API's step conclusion report success regardless — showed 3 of 21 main runs failing with FAIL (real-input required): window_metrics returned no window size. Tracked with the evidence and two candidate causes in #328.

Leaving this open for you to decide whether to close it now and let #328 carry the remainder, or keep it as the umbrella.

[charliek]

Closing via PR #357: the e2e-gtk-wayland and e2e-gtk-wayland-drag jobs no longer exist — the GTK UI and its CI jobs were removed. The successor concern (the new iced Wayland drag lane being outside ci-success) is tracked in #336.