Repository navigation
Conversation
…days The "Guard: only run on 4th Thursday" step ended with `exit 0` when the date did not match. That only ends the guard step; the job continues and the "Post message to Slack" step still runs. This is why the reminder was posted on both Thu Jan 22 and Fri Jan 23 2026 (00:15 UTC), after which the workflow was disabled. The cron also listed a weekday (`4`) together with a day-of-month range. cron ORs those two fields when both are restricted, so the schedule fired on every day 22-28 and additionally on every Thursday of the month, which is what put the guard on the critical path in the first place. - Make the guard write `post=true|false` to `$GITHUB_OUTPUT` and gate the Slack step on `steps.guard.outputs.post == 'true'`. Manual `workflow_dispatch` runs keep posting unconditionally, as before. - Drop the weekday from the cron so the schedule only fires on the 22nd-28th of the meeting months; the guard picks the Thursday. - Parse the day of month in base 10 so `08`/`09` are not treated as octal by `[[ ... -lt ... ]]` (which would fail the step under `set -e` on a manual run on those days). The schedule stays in UTC to match the meeting, which is fixed at 00:00 UTC. Fixes cncf#153 Signed-off-by: Aman Bansal <amanbn@icloud.com>
|
/kind bug |
github-actions
Bot
added
kind/bug
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Needs approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
🟢 Approval recommended
The focused workflow changes address unintended posts, preserve manual behavior, and have no unresolved findings.
0 open findings
What changed in this PR
Fixes the Glossary WG Slack reminder so scheduled runs post only on the fourth Thursday of meeting months, while preserving manual posting and UTC timing.
Changes:
- Removes the weekday restriction from cron to avoid extra runs.
- Gates Slack posting on the guard’s output, except for manual runs.
- Parses day-of-month values in base 10.
| File | Description |
|---|---|
.github/workflows/scheduled-slack-glossary-maintainers.yaml |
Corrects scheduling, guard output, and Slack posting conditions. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Problem
The Glossary WG Slack reminder posted on Thu Jan 22 and Fri Jan 23 2026 (both at 00:15 UTC), and the workflow has been disabled since. Two things in the workflow cause that:
exit 0when it is not the 4th Thursday. That only ends the guard step; the job keeps going and the "Post message to Slack" step runs anyway. So every scheduled run posts, whatever the date.0 0 22-28 1,3,5,7,9,11 4restricts both day-of-month and day-of-week. cron ORs those two fields when both are set, so the schedule fires on every day from the 22nd to the 28th and on every Thursday of the month. That is why there was a run on Friday the 23rd for the guard to (fail to) stop.Fix
post=true|falseto$GITHUB_OUTPUT, and the Slack step is gated withif: github.event_name == 'workflow_dispatch' || steps.guard.outputs.post == 'true'. Manual runs keep posting unconditionally, as they did before.[[ "08" -lt 22 ]]is an error in bash (value too great for base), which would fail the guard underset -eon a manual run on the 8th or 9th.Everything stays in UTC, which matches the meeting (fixed at 00:00 UTC), so there is no DST drift. That was the concern raised on #162.
Testing
I ran the guard's
run:block withdatestubbed for a set of dates and checked$GITHUB_OUTPUT:post=truepost=falsepost=truepost=falsepost=false, no bash errorThe workflow is currently disabled in the Actions tab (
disabled_manually, 2026-01-23), so it will need to be re-enabled after this merges. The next scheduled window is Thu Nov 26 2026.Fixes #153