Continuous delivery can schedule deployments without a DeploySpec

[benlangfeld]

If a stack is provisioned with continuous delivery enabled, or continuous delivery is enabled shortly thereafter, it's quite possible for the continuous delivery routine to run on the stack prior to the DeploySpec being cached, particularly when the git repo is large and slow to clone.

This results not only in the max_commits default value being used and a deployment of a potentially very old commit being triggered, but there's no guarantee that the deployment job will wait for a DeploySpec, and it may run using the default with potentially very poor results.

Our proposal is for continuous delivery to be delayed until a DeploySpec can be cached. The idea would be to consider any empty DeploySpec to be insufficient for continuous delivery to operate.

Would this change be accepted?

[casperisfine]

Right, for a long time the assumption was that not having a cached_deploy_spec is fine because the deploy spec is parsed again during the deploy job.

However you got a point about settings such as max_commits which have an impact before the deploy is triggered.

Would this change be accepted?

As long as it doesn't over complicate things, yeah for sure. Out of the top of my head it's simply another pre-condition check so it should be simple enough.