Hello,
I keep getting messages from the client saying their website isn’t updating. I log into the Cleavr and see this:
I have to manually cancel all deployments and start a new deployment as it “freezes”. This is not ideal as I’m not always on hand to trigger a manual deployment.
What is triggering multiple deployments here?
The CMS editors editing multiple pages in quick succession. For example quick copy changes.
Unfortunately, right now there is no solution for such “real time deployments on every keystrokes” use case with Cleavr. We will go back to the whiteboard and talk about how to handle such a use case.
Also, let me ask you a question - in this scenario where there is a chance of firing multiple unnecessary small deployments, what is your expectation? Will you be fine just doing one deployment for a bunch of changes in one batch?
It’s hard to say a one-size fit’s all solution. I know personally that since the updates are coming from the CMS and when multiple are editing it’s hard to prevent duplicate fires to the build endpoint. So my preferred solution would be to automatically cancel any deployments currently in any status other than “error” or “complete” such as “waiting”, “building” and start a new deployment. The very latest deployment will also include all the information in the previous deployment so it makes the deployment it’s waiting on obsolete.
However, I understand this may not be a desirable solution for everyone.
And the issue on our side isn’t that Cleavr can’t handle multiple deploymens, but the fact that we are firing multiple connections and your server is literally blocking Cleavr from pushing another deployment script. This is, ironically, a security measure put in by Cleavr itself. Yep, Cleavr made sure when attempting too many SSH logins, the new requests are just dropped (not denied but dropped), including for Cleavr itself 
This is what we had but users had good reasons to have them queued and not cancelled, including me.
I can already think of a couple of ways to improve this so give us some time and we will resolve this in a way it works for everyone. I’m sorry that in the meantime, you have to deal with this manually. I’d suggest disabling deployment hook for now and deploying it at the very end.
