You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, thanks for the work you've done on this project (and for open sourcing it)!
Would you consider adding support for providing the Time Zone as part of the pool_config variable?
For context, we want to keep a pool of runners ready during office hours, but we'd currently need to convert the pool_config[*].schedule_expression to UTC and update that whenever the clocks change (e.g., I'm in the UK, where the start/end of "British Summer Time" changes every year).
My current workaround is to define the aws_scheduler_schedule resources outside the GitHub runners module and trigger the pool Lambda, but that has a couple of issues:
It relies on implementation details of your module, so may break in the future (specifically, the payload to pass to the pool function)
At least one pool_config expression is required, otherwise the pool resources aren't created
Proposal
Add an optional time_zone property to the pool_config variable
Replace the use of aws_cloudwatch_event_rule in the pool module with aws_scheduler_schedule (and a single aws_scheduler_schedule_group and aws_iam_role), setting schedule_expression_timezone if necessary.
Alternatively, dynamically switch between aws_cloudwatch_event_rule and aws_scheduler_schedule, depending on whether the time_zone is set. This would increase the complexity of the module, but would avoid making any changes to existing users.
If you'd consider accepting one of these as a PR, I can look at implementing one of them.
The text was updated successfully, but these errors were encountered:
For us within Philips, this is not much of issue. I can see where the suggestion will help reduce arbitrary code to workaround this issue. Any contributions are more than welcome!
janslow
added a commit
to janslow/terraform-aws-github-runner
that referenced
this issue
Aug 13, 2024
Fixesgithub-aws-runners#4056
Replaces the `aws_cloudwatch_event_rule` in the `pool` module (which only support UTC) with `aws_scheduler_schedule`, which supports arbitrary time zones via the `schedule_expression_timezone` attribute.
The AWS EventBridge Scheduler is a drop in replacement for scheduler based AWS EventBridge Rules ([see AWS blog post](https://aws.amazon.com/blogs/compute/introducing-amazon-eventbridge-scheduler/)), including the expression syntax and pricing.
The timezone can be set via the `schedule_expression_timezone` property via the main module or `multi-runners` module.
Uh oh!
There was an error while loading. Please reload this page.
Hey, thanks for the work you've done on this project (and for open sourcing it)!
Would you consider adding support for providing the Time Zone as part of the
pool_config
variable?For context, we want to keep a pool of runners ready during office hours, but we'd currently need to convert the
pool_config[*].schedule_expression
to UTC and update that whenever the clocks change (e.g., I'm in the UK, where the start/end of "British Summer Time" changes every year).Workaround
Unfortunately, AWS EventBridge Rules (currently used to trigger the pool function) don't support time zones, but AWS EventBridge Scheduler does. This feature is a drop-in replacement for EventBridge Rules (including the cron expression) and the same price.
My current workaround is to define the
aws_scheduler_schedule
resources outside the GitHub runners module and trigger the pool Lambda, but that has a couple of issues:pool_config
expression is required, otherwise the pool resources aren't createdProposal
time_zone
property to thepool_config
variableaws_cloudwatch_event_rule
in thepool
module withaws_scheduler_schedule
(and a singleaws_scheduler_schedule_group
andaws_iam_role
), settingschedule_expression_timezone
if necessary.Alternatively, dynamically switch between
aws_cloudwatch_event_rule
andaws_scheduler_schedule
, depending on whether thetime_zone
is set. This would increase the complexity of the module, but would avoid making any changes to existing users.If you'd consider accepting one of these as a PR, I can look at implementing one of them.
The text was updated successfully, but these errors were encountered: