ci(drift): run drift on demand, and move the cron to the morning #533
No reviewers
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea!533
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-532-drift-dispatch-and-morning-cron"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Closes #532. Follow-up to #525 and PR #531.
The gap
drift.ymlhad three triggers and no way to start a run by hand. Its two cron-only jobs could therefore never be exercised on demand.git-matrixshipped in PR #531 without ever having executed, and its first run would also be the first time anything mountedmadtea-gitcache. A mistake in the mount, the source build, or the signature check would have failed with nobody watching.The cron also reported at the wrong end of the day.
17 4 * * *UTC is 22:17 local for me, so a red drift result landed late at night and was read the next morning at the earliest.What changes
workflow_dispatchis now a trigger, andgit-matrixruns on it as well as onschedule. The check can be started from the Actions tab instead of waiting a day.17 4 * * *to0 13 * * *, so the result lands at the start of the working day.Actions cron is UTC only, so the local time shifts by an hour across a daylight-saving change: 07:00 in summer, 06:00 in winter. The comment says so, rather than leaving the reader to work it out.
Why dispatch is safe here
A dispatch needs write access on the repository, so it is a trusted event in the same class as
pushandschedule. The cache-mount expression already keys on!= 'pull_request'and treats it as trusted, which stays correct.forgejo-smokeis the one job worth checking before widening a trigger, because it needs a host Docker socket. It is gated onvars.RUN_FORGEJO_SMOKE == 'true' && github.event_name != 'pull_request', and a dispatch satisfies the second clause. The repository defines no Actions variables at all, so the first clause is false and that job stays skipped. It remains unreachable from a fork PR, which is the property its comment protects.govulncheckstays cron-only. Widening it was not part of the ask, andci.ymlalready runs it on every push and PR.Verification
The workflow parses, and the gates resolve as intended:
I am triggering a dispatch run straight after this merges, which is the first real execution of the git matrix.
Closes #532