Closed yeikel closed 1 year ago
@timtebeek Should this be a separate recipe instead? That's also a possibility
I'm looking at https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule & trying to see how people would configure a recipe that does not result in a predictable cron expression. Would you suggest we support the non-standard syntax @yearly, @monthly, @weekly, @daily and @hourly
?
And what usages do you see for such a recipe? I'm thinking it'd be limited to large organizations, running their own workers, or calling their own services before they start to care about load spreading like this. Do you see any other uses?
Perhaps I've just not worked as much in large organizations, but I'd like to be reasonable sure the recipes or options we add are likely to be used, before we build and maintain them going forward. Hope you agree, and appreciate the help as always!
I'm looking at https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule & trying to see how people would configure a recipe that does not result in a predictable cron expression. Would you suggest we support the non-standard syntax
@yearly, @monthly, @weekly, @daily and @hourly
?And what usages do you see for such a recipe? I'm thinking it'd be limited to large organizations, running their own workers, or calling their own services before they start to care about load spreading like this. Do you see any other uses?
Perhaps I've just not worked as much in large organizations, but I'd like to be reasonable sure the recipes or options we add are likely to be used, before we build and maintain them going forward. Hope you agree, and appreciate the help as always!
This is exactly the scenario.
We configured the stale action in hundreds of repositories but we have a limited set of private runners. If all these jobs start at the same time, we'll effectively take all the resources to run a low-priority job like this one. It is not uncommon to have this set up for another type of scheduled actions
Would you suggest we support the non-standard syntax @yearly, @monthly, @weekly, @daily and @hourly ?
We can't do this because this is not supported by Github Actions
Good to have the use case clear.
Would you suggest we support the non-standard syntax https://github.com/Yearly, @monthly, @Weekly, @daily and @hourly ?
We can't do this because this is not supported by Github Actions
I know GitHub does not support that, but how would you imagine we configure the recipe to use whatever recurrence schedule the user wants? I suppose those pseudo-standard terms could be helpful there, unless you have other ideas.
Good to have the use case clear.
Would you suggest we support the non-standard syntax https://github.com/Yearly, @monthly, @Weekly, @daily and @hourly ?
We can't do this because this is not supported by Github Actions
I know GitHub does not support that, but how would you imagine we configure the recipe to use whatever recurrence schedule the user wants? I suppose those pseudo-standard terms could be helpful there, unless you have other ideas.
What I imagined is that we would generate a random cron expression if no input is given
Sounds OK to me; happy to look over a contribution and work out the final details from there, if you or anyone else is up for it. :)
Sounds OK to me; happy to look over a contribution and work out the final details from there, if you or anyone else is up for it. :)
Looking more into your comments above, it might make more sense to allow the user to support the @monthly, @Weekly, @daily, and @hourly syntax instead of a purely random expression
For example, in the main use case I explained above, users might want to add a "random" expression simply to share the resources evenly rather than a fully random expression
Dependabot does something similar to this given we enter one of the non-standard expressions:
Dependabot randomly assigns a time to apply all the updates in the configuration file.
Glad we're on the same page! :)
@timtebeek Feel free to assign this to me
While trying to add a cron trigger across an organization, there are situations where it would be better to set a random expression rather than fixed as a random expression would allow for better resource utilization
Example:
An organization with 100 repos with the same cron expression will trigger 100 jobs in parallel