ci: Schedule GitHub workflows to daily run to detect failures due to upgraded dependencies or environments. #583
Conversation
WalkthroughThe pull request introduces scheduled triggers for multiple GitHub workflows, allowing them to run automatically every day at 00:15 UTC. The workflows affected include Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
.github/workflows/clp-core-build-macos.yaml (1)
30-32: Consider adding failure notifications for scheduled runs, ehSince these runs are meant to catch environment-related breakages, it would be beneficial to:
- Add a notification step (e.g., using Slack or email) specifically for scheduled run failures
- Consider implementing a status check that aggregates results across all daily workflow runs
This ensures the team is promptly notified of any issues without having to actively monitor the workflows.
Would you like me to provide an example implementation of failure notifications?
.github/workflows/clp-execution-image-build.yaml (1)
14-16: The schedule configuration looks good, with a thoughtful delay.The cron expression "15 0 * * *" is well-chosen:
- Daily runs at 00:15 UTC will help detect environment-related breakages early
- The 15-minute offset from midnight helps avoid peak load times on GitHub Actions
Consider monitoring the increased GitHub Actions usage and associated costs from these daily runs. You might want to:
- Set up GitHub Actions budget alerts
- Track workflow run times and costs
- Review the necessity of daily runs after a few months of data collection
.github/workflows/clp-core-build.yaml (1)
26-28: Consider adding a timeout to prevent workflow overlap.Since this is a complex workflow with multiple jobs, consider adding a timeout to ensure that long-running workflows don't overlap with the next day's scheduled run.
Add the following timeout configuration at the workflow level:
name: "clp-core-build" +# Prevent long-running workflows from overlapping with next day's scheduled run +timeout-minutes: 300 on:
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
.github/workflows/clp-core-build-macos.yaml(1 hunks).github/workflows/clp-core-build.yaml(1 hunks).github/workflows/clp-docs.yaml(1 hunks).github/workflows/clp-execution-image-build.yaml(1 hunks)
🔇 Additional comments (3)
.github/workflows/clp-docs.yaml (1)
6-8: Well-implemented schedule with thoughtful timing consideration!
The 15-minute delay after midnight UTC is a smart choice to avoid competing with other workflows that typically run at exact hours. This helps prevent resource contention and improves reliability.
.github/workflows/clp-core-build-macos.yaml (1)
30-32: The scheduling configuration looks good, eh!
The cron schedule "15 0 * * *" is well-chosen:
- Runs daily at 00:15 UTC, providing consistent monitoring
- The 15-minute offset helps avoid GitHub's peak load at midnight
- Aligns with the PR's objective of detecting environment-related breakages early
Let's verify the scheduling consistency across all workflows:
✅ Verification successful
Scheduling configuration is consistent across all workflows, eh!
All GitHub Actions workflow files have identical scheduling:
- Same cron expression "15 0 * * *" for daily runs at 00:15 UTC
- Consistent comments explaining the 15-minute delay strategy
- Applied uniformly across core builds, docs, linting, and execution image workflows
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if all workflows have consistent scheduling
# Expected: All workflows should have the same cron schedule
echo "Checking scheduling consistency across workflows..."
rg -A 2 'schedule:' .github/workflows/
Length of output: 1388
.github/workflows/clp-core-build.yaml (1)
26-28: LGTM! Well-designed schedule configuration.
The scheduled trigger is properly configured to run daily at 00:15 UTC. The 15-minute delay after midnight is a thoughtful addition to avoid peak load periods on GitHub Actions.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
.github/workflows/clp-execution-image-build.yaml (1)
14-16: Monitor GitHub Actions minutes consumption.Daily runs will increase your GitHub Actions minutes usage. Consider implementing a monitoring strategy to track consumption and ensure you stay within limits.
Would you like me to help create a workflow to monitor Actions minutes usage?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
.github/workflows/clp-core-build-macos.yaml(1 hunks).github/workflows/clp-core-build.yaml(1 hunks).github/workflows/clp-docs.yaml(1 hunks).github/workflows/clp-execution-image-build.yaml(1 hunks).github/workflows/clp-lint.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- .github/workflows/clp-lint.yaml
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/clp-core-build-macos.yaml
- .github/workflows/clp-core-build.yaml
- .github/workflows/clp-docs.yaml
🔇 Additional comments (1)
.github/workflows/clp-execution-image-build.yaml (1)
14-16: Consider targeting specific branches for scheduled runs.
The schedule trigger looks good and the 15-minute offset is a thoughtful addition to avoid peak load times. However, scheduled workflows run on the default branch only. If you need to run this on other branches, you'll need to specify them explicitly in the workflow.
Let's verify the branch configuration:
LinZhihao-723
changed the title
* ffi: Add support for serializing/deserializing auto-generated and user-generated schema tree node IDs. (y-scope#557) Co-authored-by: kirkrodrigues <[email protected]> * clp: Add missing C++ standard library includes in IR parsing files. (y-scope#561) Co-authored-by: kirkrodrigues <[email protected]> * log-viewer-webui: Update `yscope-log-viewer` to the latest version (which uses `clp-ffi-js`). (y-scope#562) * package: Upgrade dependencies to resolve security issues. (y-scope#536) * clp-s: Implement table packing (y-scope#466) Co-authored-by: wraymo <[email protected]> Co-authored-by: Kirk Rodrigues <[email protected]> Co-authored-by: wraymo <[email protected]> * log-viewer-webui: Update `yscope-log-viewer` to the latest version. (y-scope#565) * ci: Switch GitHub macOS build workflow to use macos-13 (x86) and macos-14 (ARM) runners. (y-scope#566) * core: Add support for user-defined HTTP headers in `NetworkReader`. (y-scope#568) Co-authored-by: Lin Zhihao <[email protected]> Co-authored-by: Xiaochong Wei <[email protected]> * chore: Update to the latest version of yscope-dev-utils. (y-scope#574) * build(core): Upgrade msgpack to v7.0.0. (y-scope#575) * feat(ffi): Update IR stream protocol version handling in preparation for releasing the kv-pair IR stream format: (y-scope#573) - Bump the IR stream protocol version to 0.1.0 for the kv-pair IR stream format. - Treat the previous IR stream format's versions as backwards compatible. - Differentiate between backwards-compatible and supported versions during validation. Co-authored-by: kirkrodrigues <[email protected]> * fix(taskfiles): Trim trailing slash from URL prefix in `download-and-extract-tar` (fixes y-scope#577). (y-scope#578) * fix(ffi): Correct `clp::ffi::ir_stream::Deserializer::deserialize_next_ir_unit`'s return value when failing to read the next IR unit's type tag. (y-scope#579) * fix(taskfiles): Update `yscope-log-viewer` sources in `log-viewer-webui-clients` sources list (fixes y-scope#576). (y-scope#580) * fix(cmake): Add Homebrew path detection for `mariadb-connector-c` to fix macOS build failure. (y-scope#582) Co-authored-by: kirkrodrigues <[email protected]> * refactor(ffi): Make `get_schema_subtree_bitmap` a public method of `KeyValuePairLogEvent`. (y-scope#581) * ci: Schedule GitHub workflows to daily run to detect failures due to upgraded dependencies or environments. (y-scope#583) * docs: Update the required version of task. (y-scope#567) * Add pr check workflow --------- Co-authored-by: kirkrodrigues <[email protected]> Co-authored-by: Junhao Liao <[email protected]> Co-authored-by: Henry8192 <[email protected]> Co-authored-by: Devin Gibson <[email protected]> Co-authored-by: wraymo <[email protected]> Co-authored-by: wraymo <[email protected]> Co-authored-by: Xiaochong(Eddy) Wei <[email protected]> Co-authored-by: Xiaochong Wei <[email protected]> Co-authored-by: haiqi96 <[email protected]>
…upgraded dependencies or environments. (y-scope#583)
Description
After realizing things will break weekly due to gh-action environment upgrades, we decided to schedule our gh workflows to run every midnight so that we know sth is broken.
Validation performed
Ensure workflows passed.
Summary by CodeRabbit
clp-core-build-macos,clp-core-build,clp-docs, andclp-execution-image-build.clp-lintworkflow for clarity regarding the scheduling.These enhancements improve automation and ensure timely execution of builds and documentation processes.