-
Notifications
You must be signed in to change notification settings - Fork 18
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
Scheduled deploys #476
Scheduled deploys #476
Conversation
'_error -> configForm.globalError.map(_.withMessage("Please select deployment stage")) | ||
) | ||
@b3.text(configForm("schedule"), '_label -> "Schedule expression") | ||
<p>This should be a weird Quartz cron expression |
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.
Be good to give a (couple of) example(s) here. Most teams will be doing similar things and the docs are pretty dense.
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.
Done. Think one 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.
There are a few traps we talked about here, which could happen by accident or deliberately:
- people scheduling it too frequently
- scheduling overnight/weekends
- everyone scheduling at the same time
If the feature proves useful, we'll probably need to address some or all of these.
I think it would be useful for this to default to excluding bank holidays. Avoiding Monday and Friday fixes for most, but there is still Christmas day, Boxing Day and New Years day. Also, is the time UTC or Europe/London? |
Bank holiday exclusions can certainly be added later if desired but isn't something I'm interested in for the first cut. We should clarify the behaviour. My expectation would be that it is local time, but I suspect it relies on the default JVM timezone and is likely to be GMT. |
@adamnfish @davidfurey this is a first pass so things like bank holiday etc. good to add once we know it's valuable. We are going for a soft launch (i.e. probably not shouting about it at first). I'm planning on testing on Discussion once merged for a while as it's a good candidate project - several apps which hardly ever get deployed. good question about timezone. I agree with @sihil let's check, but it's almost certainly GMT. |
As guessed, Riff-Raff currently runs in UTC. I've just pushed another commit that allows the user to explicitly select the timezone that the schedule should run in. It defaults to the timezone of the users browser (provided they have a reasonably modern browser). When the quartz schedule is configured we provide the timezone. Seems to work based on a brief test in Kiev. |
I think this is ready to ship. Would be glad of a review / 👍whenever someone has time. |
@sihil I can 👍 but given we paired on it, another would also be good. |
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.
Pulled this together this afternoon with @nicl
This introduces scheduled deploys to Riff-Raff. This allows you to configure a project to deploy automatically according to a pre-determined schedule.
The aim of scheduled deploys is to have a mechanism for automatically updating AMIs even when a project is not actively being worked on.
Some details:
Possible future improvements:
This is currently running and enabled in CODE.
Before merging:
After merging:
scheduledDeployment.enabled=true
in PRODscheduledDeployment.enabled=true
in CODEScheduling screen:
Deploy is run by a "scheduled deploy" user: