refactor(self-routine): collapse to a single weekly cron firing all jobs#282
Merged
refactor(self-routine): collapse to a single weekly cron firing all jobs#282
Conversation
Previously each routine had its own cron (Mon 03:00 for branch cleanup, daily 04:00 for stale PRs, Wed 04:30 for stale issues, Sun 05:00 for labels sync, monthly 1st 06:00 for workflow runs cleanup). That produced fragmented "stale-pr ran at 04:00, then branch cleanup at 03:00 next Monday, then..." noise across the Actions tab. Switch to a single cron — `0 3 * * 1` (Mon 03:00 UTC) — that fires the whole workflow once a week. Every job's schedule gate is now just `github.event_name == 'schedule'`, so all routines run together in the same run. Why this is fine: - actions/stale and the cleanup composites are idempotent — items that don't meet the threshold are listed and skipped, no side effect. - A weekly cadence for stale-pr (instead of daily) is acceptable for this volume; if a faster PR cycle is needed later, add a second cron with a job-level `if` gating only `stale_pr`. - Per-routine triggers other than schedule are unchanged: `branch_cleanup_merged` still fires on every merged PR, `labels_sync` still fires on `push` to main when `.github/labels.yml` changes, and every job remains dispatchable individually via `workflow_dispatch`.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughReplaced multiple cron triggers with a single weekly Monday schedule and removed job guards that matched exact Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
lerian-studio
added
size/XS
Contributor
🔍 Lint Analysis
|
Contributor
🛡️ CodeQL Analysis ResultsLanguages analyzed: ✅ No security issues found. 🔍 View full scan logs | 🛡️ Security tab |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/self-routine.yml:
- Around line 5-10: The current workflow cron "0 3 * * 1" runs only weekly which
reduces stale-pr.yml's effective throughput because operations_per_run remains
60 (previously refreshed daily); either change the cron back to a daily schedule
(e.g., the previous cron expression) so operations_per_run resets each day, or
increase the weekly budget in this wrapper to operations_per_run × 7 (e.g., 420)
so the aggregate weekly capacity matches the prior daily behavior—update the
cron string "0 3 * * 1" or the operations_per_run value in stale-pr.yml
accordingly and ensure any related schedule entries (lines referenced around
68-73) are adjusted consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5a689a03-31f1-4a5c-b1a3-c5963c1376e3
📒 Files selected for processing (1)
.github/workflows/self-routine.yml
When the cron was daily, `operations_per_run: 60` (reusable default) refreshed every 24h — effectively ~420 ops/week. Collapsing to a single weekly cron meant the same 60-op cap applied to a full week of backlog, so any repo with >60 candidates would have items drift past the stale and close windows. Override the input on schedule events to 420 in both `stale_pr` and `stale_issue` jobs of `self-routine.yml`. The expression is conditional so manual `workflow_dispatch` runs keep the leaner 60-op default, which is appropriate for an interactive sanity-check. Reusable defaults are unchanged — external consumers that drive `stale-pr.yml` / `stale-issue.yml` directly are free to keep daily schedules with 60 ops/run.
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/self-routine.yml:
- Around line 90-93: The scheduled `stale_issue` job's operations_per_run was
changed to conditionally use 420 for scheduled runs; revert this so
`stale_issue` keeps the previous weekly budget by setting operations_per_run to
the constant 60 (i.e., remove the schedule conditional and use 60) so the
`operations_per_run` key for the `stale_issue` job remains 60; locate the
`operations_per_run` entry for the `stale_issue` workflow job and replace the
conditional expression with the literal 60.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0738c65c-13fd-410c-a8fc-c421fc265e4c
📒 Files selected for processing (1)
.github/workflows/self-routine.yml
…L rationale comments Per CodeRabbit's correctness note on PR #282 and the no-yaml-comments project rule, two changes: - `stale_issue` no longer overrides `operations_per_run`. Stale issues were already scheduled weekly before the unified-cron refactor (the prior cron was `30 4 * * 3`), so the 60-op default already maps to weekly throughput. Bumping it to 420 would have expanded the scheduled mutation budget 7x without justification — stale_pr was the only side that needed the bump (it was daily before). - The inline rationale comments on the `operations_per_run` lines are removed in line with the project's no-`# why` policy for workflow YAML — the rationale belongs in the commit message, not in the file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub Actions Shared Workflows
Description
Each routine had its own cron expression, producing fragmented runs scattered across the Actions tab — branch cleanup at Mon 03:00, stale PRs daily at 04:00, stale issues Wed 04:30, labels sync Sun 05:00, workflow runs cleanup monthly at 06:00. Hard to skim.
Collapse to a single weekly cron —
0 3 * * 1(Monday 03:00 UTC) — that fires the entire workflow once a week. Every job's schedule gate becomes justgithub.event_name == 'schedule', so all routines now run together in the same run.Why this is fine
actions/staleand the cleanup composites are idempotent. Items that don't meet the threshold are listed and skipped — no side effect from running more often than strictly needed.ifgating onlystale_pr.branch_cleanup_mergedstill runs on every merged PR,labels_syncstill runs onpushto main when.github/labels.ymlchanges, and every job is still dispatchable individually viaworkflow_dispatch.routine.Type of Change
featfixperfrefactor: Internal restructuring with no behavior changedocsci: Changes to self-CI (workflows under.github/workflows/that run on this repo)choretestBREAKING CHANGEBreaking Changes
None. Self-* file, internal-only.
Testing
@developor the beta tagCaller repo / workflow run: validated via the next scheduled Monday 03:00 UTC firing — expected: a single workflow run that contains every routine job side-by-side.
Related Issues
Closes #
Summary by CodeRabbit