refactor: Update most frequently updating groups to run on Thursdays #3323
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -8,8 +8,8 @@ | |||||
| // Schedule Renovate to run during off-peak hours | ||||||
| schedule: ['after 6am and before 10am on Monday, Wednesday, Friday'], | ||||||
|
|
||||||
| prConcurrentLimit: 12, | ||||||
| prHourlyLimit: 8, | ||||||
| timezone: 'Europe/Rome', | ||||||
|
|
||||||
| // Commit and PR customization | ||||||
|
|
@@ -74,6 +74,7 @@ | |||||
| matchUpdateTypes: ['digest', 'patch', 'minor'], | ||||||
| matchManagers: ['npm'], | ||||||
| matchBaseBranches: ['main'], | ||||||
| schedule: ['* 5-12 * * 4'], // 5:00 am am to 12:00 pm Every Thursday | ||||||
|
Member
There was a problem hiding this comment. What time zone is this in? 5am to 12pm in PST is 2pm to 9pm which is later than we would like for this to run
Contributor
Author
There was a problem hiding this comment. If I recall the timezone is specified at the top of the file. It's Rome time.
Contributor
There was a problem hiding this comment. Indeed the TZ is Rome. You have a typo in the comment. Also consider using a human readable version of the schedule example: schedule: ['after 6am and before 10am on Thursday'],
Contributor
Author
There was a problem hiding this comment. Is there a particular reason we're using Rome? Why not switch it to UTC?
Contributor
Author
There was a problem hiding this comment.
I was basically looking at other schedules in the file. A lot of them seem to be morning Rome time.
Contributor
Author
There was a problem hiding this comment. Given the time zone, 5am to noon Rome time would be 8 PM the previous day to 3 AM PST. Should we leave that? Should I change it to later? What's the preference here?
Contributor
There was a problem hiding this comment.
I do not have any strong preference here, I would however though maybe suggest to reduce the time window (ie: to maybe 10am), as other if the caretaker is in EMEA and they merge a PR at 11am, there is a chance that a new PR will be open on the same day with more changes. So maybe use time same time as the global.
Contributor
There was a problem hiding this comment.
Suggested change
|
||||||
| }, | ||||||
|
|
||||||
| // ============================================================================ | ||||||
|
|
@@ -90,6 +91,7 @@ | |||||
| { | ||||||
| groupName: 'bazel dependencies', | ||||||
| matchManagers: ['bazel', 'bazel-module'], | ||||||
| schedule: ['* 5-12 * * 4'], // 5:00 am am to 12:00 pm Every Thursday | ||||||
|
Contributor
There was a problem hiding this comment. NIT: consider using a human readable version
Contributor
Author
There was a problem hiding this comment. I was following the renovate documentation, which says cron is the recommendation. Apparently the human readable version is from a deprecated dependency.
Contributor
Author
There was a problem hiding this comment. Here's the direct quote from the documentation: "Renovate supports the standard Cron syntax, as well as deprecated support for a subset of Later syntax. We recommend you always use Cron syntax, due to its superior testing and robustness. Config support questions are no longer accepted for Later syntax problems - you will be recommended to use Cron instead." https://docs.renovatebot.com/configuration-options/#schedule
Contributor
There was a problem hiding this comment. Interesting, I was not aware that this was deprecated, and usefully deprecations are highlighted in the dashboard/logs.
Contributor
There was a problem hiding this comment.
Suggested change
|
||||||
| }, | ||||||
|
|
||||||
| // Group GitHub Actions workflow | ||||||
|
|
||||||
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 should leave this to 4, as otherwise we'll have a lot of PRs opening at the same moment which might slow down the github action, due to the post-install tasks and also potentially overload a bit CI in the target repo.