Is it possible to limit "when" a deployment gets executed?
E.g. we have plans that get triggered by Pull Requests. They get deployed to either staging or production, depending on the branch that was merged (develop/master).
The plan to staging (develop branch) can deploy whenever merges happen, as it is the staging, and meh.
To production I want to limit deployments by time and day. No deployments to production (master branch) should be done on Friday/Saturday/Sunday and other days no deployments should be done after 15:00 or before 08:30.
The effect I want to achieve is that if a merge is done to master that it should be queued for the first allowed day after the allowed time.
E.g. A merge done to the master branch should be queued for Monday 08:30 or when an agent is available.
Unfortunately scheduled deployments are not available yet, though in increasingly high demand - please watch and vote for the following related issues to guide Atlassian's roadmap in this regard:
Hi, that is very unfortunate indeed.
However, issue BAM-13517, would that not already be possible if you use a Release branch and/or tags combined with scheduling via the cronjob option? You'd then allow the deployment only on a new Tag (instead of a merge of a Pull Request for example). It would check & deploy this at the cronjob's' scheduled time.
BAM-13819 Would indeed also be nice.
Next to that would be my issue. I would like deployments to happen as work is approved via merge of Pull Request, but only within the 08:30 to 15:00 window, Monday to Thursday. If Merges happen outside that window, then they would need to be queued for the next available window.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There are certainly a couple of alternatives and/or workarounds, though most seem to come with their own constraints in turn, see for example:
The latter specifically mentions a trigger that's based on a tag, and then refers to another issue, though I do not fully understand how this would cover a tag based trigger:
Either way, right now we seem to be stuck with working around the status quo one way or another ...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.