ci: run conformance on changes that affect it, not on a weekly clock #79

Merged

yuris merged 1 commit from ci/conformance-triggers into main

2026-08-21 03:53:39 +00:00

yuris commented

2026-08-21 03:49:29 +00:00

Owner

This PR touches a path in the filter, so a conformance run appearing on it is the test of the trigger.

Nothing in this job drifts on its own (server, CLI, chromium and bob are pinned through flake.lock), so the weekly cron could only ever fire against an unchanged tree. Replaced with path-filtered push and pull_request triggers. This PR touches a path in the filter, so a conformance run appearing on it is the test of the trigger.

yuris added 1 commit

2026-08-21 03:49:29 +00:00

ci: run conformance on changes that affect it, not on a weekly clock

ci / ci (pull_request) Successful in 20s

Details

conformance / conformance (pull_request) Successful in 2m53s

Details

62b3e7784a

The cron called itself a drift check against the pinned server version, which
cannot happen: the server, CLI, chromium and bob are all pinned through
flake.lock. Nothing moves without a commit, and #16's evidence came from
manual dispatches, not from the schedule.

What a schedule could still catch is build.defold.com or the runner rotting
underneath us. That shows up on the next real run regardless, with a change
to blame it on, instead of a Monday-morning red X against an unchanged tree.

Path-filtered push and pull_request triggers replace it, so the tier that
covers stdb/init.lua actually gates the commits that touch it. Everything
else keeps paying ci.yml's 20 seconds and nothing more.

yuris merged commit 38f14c758b into main

2026-08-21 03:53:39 +00:00

yuris referenced this pull request from a commit

2026-08-21 03:53:40 +00:00

ci: run conformance on changes that affect it, not on a weekly clock (#79)

~~yuris referenced this pull request 2026-08-21 03:53:51 +00:00~~

HTML5 conformance in CI: prove Chromium runs in the job container #16