-
Notifications
You must be signed in to change notification settings - Fork 684
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
schedule regular build and test #1373
Conversation
.github/workflows/build_and_test.yml
Outdated
@@ -4,6 +4,8 @@ on: | |||
branches: ["master", "dev"] | |||
pull_request: | |||
branches: ["dev"] | |||
schedule: | |||
- cron: '0 0 * * *' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
run build at 00:00 every day.
@tigercosmos I'm not sure we need a daily build. If CI breaks we usually know it from existing PRs... |
@seladb That's the issue. We need to have a PR to know if the CI is broken, but we don't have PR every day. When the CI is broken, the PR usually needs to wait for the CI fixed, which is inefficient. |
I'm not sure it's really needed because if there's no PR then there's no need to fix CI 🙂 |
@seladb For certain issues, such as the recent one with CMake, having regularly scheduled builds enables us to identify such issues sooner. |
@seladb @tigercosmos It is good to know if something is broken but fast response can also make some things more complicated. Think about the latest breaking change in CMake. If we saw this on day one, we might think we should change something to fix instead of waiting CMake to fix their problem 🤔. Even if we know something is broken with scheduled workflows, we should still wait some time before changing something in library, I think. Currently PcapPlusPlus is active enough to check workflows because every week there are more than one PRs. But I have a question, why only My biggest concern is workflow time. Currently we have lots of runners (and we should have them because pcpp is multi-platform) and they consume a bit of time to run (Looks like 3min - 15min) and we rely on GitHub actions, so we don't have a custom queue or priority queue etc. Because concurrency limits in GitHub it might consume more time to run workflows when there is ongoing PRs. So instead of every day maybe just trigger every week? So even if there is no PR for a while, we can check the situation. |
@egecetin I only added Regarding your concern about the execution time, I don't think it is an issue, we only occupy the CI 10 minutes a day, and we don't have many PRs that need to run CI in a day. But I am also fine to have one run per week. |
Maybe we should just run the packaging CI once a week or so? 🤔 |
I'm ok for both run all CI or just packaging only. It is up to you 👍. |
.github/workflows/auto_update.yml
Outdated
@@ -2,7 +2,7 @@ name: Auto Update | |||
|
|||
on: | |||
schedule: | |||
- cron: '10 10 15 * *' | |||
- cron: '0 0 * * 0' # Run every Sunday at midnight |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't want to run auto_update
on a weekly basis, once a month is enough...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, let me change it
@seladb should be ready for review. |
schedule a build every day. In case the CI is broken unexpectedly.