Add a weekly CI run - #2059
Add a weekly CI run#2059darbyjohnston merged 1 commit into
Conversation
What the build stands on moves whether or not the code does. Runner images are replaced, the compilers and Python versions on them change, and the dependencies fetched during the build release new versions. Today that is found by whichever pull request happens along next, and its author has to work out that the failure is nothing to do with their change before anyone can start on the real one. A run every Monday morning meets it first, at seventeen minutes past rather than on the hour, since GitHub delays scheduled runs when many of them come due at once. It is the same workflow rather than a smaller one on purpose: a weekly run that covered less than a pull request does could not tell anyone what a pull request is about to hit. Manual runs are allowed too, for when there is reason to look without waiting a week. A weekly run and a push to main share a concurrency group, since both are the default branch, so one cancels the other. That is left alone: they test the same commit against the same environment, so whichever finishes answers the same question. Signed-off-by: Darby Johnston <darbyjohnston@yahoo.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2059 +/- ##
=======================================
Coverage 83.52% 83.52%
=======================================
Files 182 182
Lines 13533 13533
Branches 1255 1255
=======================================
Hits 11303 11303
Misses 2057 2057
Partials 173 173
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
Great idea. Good note about setting the time and Github delaying scheduled runs. |
|
Awesome! I wonder if we want to have the same
This way we can land PRs without needing to future proof them against the bleeding edge all the time which can be tough (keep having to ping contributors to rebase etc). What do you think? |
|
I think that sounds reasonable, though we should probably have more frequent OTIO releases so the adapters don't fall behind. |
|
I’m all for it! Quarterly releases! :) |
|
One thing to keep in mind is that Github automatically disables scheduled actions for repos that are inactive for 60 days. Some of the less frequently updated adapters may fall under that. |
|
Does GitHub reenable them automatically when a project gets active contributions again? |
|
No, you gotta manually re-enable them. There are ways around it, but they're either kinda sloppy or require extra monitoring. There's this Keepalive Action that just makes dummy commits if nothing happens for 45 days. Others add heartbeat pings to the end of their scheduled actions that call home to a monitoring service and setup alerts if one goes stale and doesn't check in. |
dc83665
into
AcademySoftwareFoundation:main
5 participants
Having a regularly scheduled CI run will help us spot issues with the GH runners, for example the upcoming Ubuntu 26.04 upgrade. This PR adds a weekly CI run for the main branch, and the ability to trigger a run manually.
🤖 Generated with Claude Code using Claude Opus 5