fix: read a schedule the way the dialect says to write one #6

Merged
day01 merged %!d() commits from %!s() into %!s() 2026-08-12 13:03:28 +00:00
Owner

on.schedule is a sequence of cron entries, because a schedule says when it fires rather than what it fires for. Every trigger was read as a mapping, so a workflow spelled exactly as the dialect prescribes was refused, and the control plane would have turned away every scheduled workflow there is. The runner’s own compatibility.yml is one of them.

Found by bumping the runner’s compiler pin to the revision the control plane already uses, per D017: the runner pinned a revision seven commits behind, and its own workflows stopped modelling on the newer one. That is the drift the single-pin rule exists to catch.

A schedule now reads as the sequence it is, with no branch or path filter to take from it. A shape that is not a sequence is still refused rather than guessed at.

The trigger tests move to a file of their own; there are enough of them now that they were pushing the model tests past the line limit.

`on.schedule` is a sequence of cron entries, because a schedule says when it fires rather than what it fires for. Every trigger was read as a mapping, so a workflow spelled exactly as the dialect prescribes was refused, and the control plane would have turned away every scheduled workflow there is. The runner’s own `compatibility.yml` is one of them. Found by bumping the runner’s compiler pin to the revision the control plane already uses, per D017: the runner pinned a revision seven commits behind, and its own workflows stopped modelling on the newer one. That is the drift the single-pin rule exists to catch. A schedule now reads as the sequence it is, with no branch or path filter to take from it. A shape that is not a sequence is still refused rather than guessed at. The trigger tests move to a file of their own; there are enough of them now that they were pushing the model tests past the line limit.
day01 added 1 commit 2026-08-12 11:16:21 +00:00
		`on.schedule` is a sequence of cron entries, because a schedule says when it
fires rather than what it fires for. Every trigger was read as a mapping,
so a workflow spelled exactly as the dialect prescribes was refused, and the
control plane would have turned away every scheduled workflow there is. The
runner's own compatibility workflow is one of them.

A schedule now reads as the sequence it is, with no branch or path filter to
take from it. A shape that is not a sequence is still refused rather than
guessed at.

The trigger tests move to a file of their own; there are enough of them now
that they were pushing the model tests past the line limit.
	
day01 merged commit 18c11e04c3 into %!s() 2026-08-12 13:03:28 +00:00
day01 deleted branch fix/read-a-schedule-the-way-it-is-written 2026-08-12 13:03:29 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: syncode/workflow#6