ci: sample the snap build monthly, not only when somebody edits it

[PathGao]

test_snap.yml is path-filtered to snapcraft.yaml, so it catches us breaking the snap build. It cannot catch snapcraft breaking it — and that is the failure that actually happened.

v2.6.11  2026-06-03   snapcraft 8.14.5   →  Revision 15 released to stable
v2.6.12  2026-07-13   snapcraft 9.0.1    →  Environment validation failed …
                                             'rustup' not found

The Snap Store served 2.6.11 for three months and six versions. snap install snapcraft --classic installs whatever the store serves that day; it went from 8.14.5 to 9.0.1 between two releases, and the 9.x rust plugin refused a snapcraft.yaml nobody had touched.

No commit here was involved, so no path filter could ever have fired. The workflow added today would have watched it happen and said nothing.

The change

schedule:
  - cron: '0 6 1 * *'

Once a month is the sampling rate for a tool that changes on its own timetable rather than on ours. The pack is ~6 minutes now that #579 made it repackage the release's .deb instead of compiling — twelve runs a year is not a budget question. The point is that a snapcraft 10 lands on a scheduled run rather than on a release.

What it costs to be honest about

A scheduled failure reaches whoever GitHub notifies for scheduled workflows, not a pull request author. That is worse than red CI and much better than a green release. If it stops being read, the fix is to make it louder rather than to delete it — the alternative is already on the record, above.

Scheduled runs only fire on the default branch, which is the right target: master's snapcraft.yaml is what the next release will use.

Tests

Asserted as "there is a schedule", not as a particular cron — how often is a judgement, having any sampling at all is not.

Checked by mutation; removing the schedule: block fails it:

✖ the snap build is sampled on a schedule, not only when we edit it
  nothing runs the snap build unless somebody edits it

npm test — 983 pass.

Where this sits

This is the second of the two blind spots outside Dependabot's reach. Dependabot watches package.json, Cargo.toml and uses:; nothing watches runs-on:, snap install snapcraft, or linuxdeploy-plugin-gtk@master. #584 samples the third on every pull request that builds. This samples the second monthly. The first is manual and #583's assertion at least makes it all-or-nothing.

🤖 Generated with Claude Code

[PathGao]

Closing with Dependabot (#600): scheduled and automated dependency work is being taken out, and version updates go back to being manual.

The gap it named is unchanged and worth writing down rather than losing. test_snap.yml is path-filtered to snapcraft.yaml, so it catches us breaking the snap build and cannot catch snapcraft breaking it — which is what happened: snap install snapcraft --classic went 8.14.5 → 9.0.1 between v2.6.11 and v2.6.12, the 9.x rust plugin refused a file nobody had touched, and the Snap Store served 2.6.11 for three months and six versions. No commit was involved, so no path filter could have fired.

Whoever hits that shape again: this is what a schedule was for.