This is not exactly an issue for the CodeDeploy Agent itself, but rather for the product API. Anyway, I am posting it here since I hope it will make it way into the CodeDeploy product team and I don't know a better place to try. So:
When calling the CodeDeploy API to trigger a new deployment from build pipelines (GitHub Actions, in my case, if that matters), it may happen that a CreateDeployment call fails with a DeploymentLimitExceededException because another deployment is currently running.
In this case, all you can do with the JavaScript SDK is to call the waitFor method to... well... wait for the current deployment to finish and then try again.
Now, with long-running deployments and/or frequent commits, this effectively makes different builds race for the next deployment to happen. The result might not be what you would expect, regarding the order of deployments as well as the final (last) deployment made.
My suggestion is to add a new, optional parameter to the CreateDeployment call that can pass some kind of identifier. The API could reject CreateDeployment calls with a dedicated error code if this parameter is not monotonically increasing with regard to the last deployment created (or the currently active deployment?).
With this, things like CI build sequence numbers, build start timestamps or similar could be used to make sure we deploy "in order", possibly skipping deployments if they have been "overtaken" by newer ones.
This is not exactly an issue for the CodeDeploy Agent itself, but rather for the product API. Anyway, I am posting it here since I hope it will make it way into the CodeDeploy product team and I don't know a better place to try. So:
When calling the CodeDeploy API to trigger a new deployment from build pipelines (GitHub Actions, in my case, if that matters), it may happen that a
CreateDeploymentcall fails with aDeploymentLimitExceededExceptionbecause another deployment is currently running.In this case, all you can do with the JavaScript SDK is to call the
waitFormethod to... well... wait for the current deployment to finish and then try again.Now, with long-running deployments and/or frequent commits, this effectively makes different builds race for the next deployment to happen. The result might not be what you would expect, regarding the order of deployments as well as the final (last) deployment made.
My suggestion is to add a new, optional parameter to the
CreateDeploymentcall that can pass some kind of identifier. The API could rejectCreateDeploymentcalls with a dedicated error code if this parameter is not monotonically increasing with regard to the last deployment created (or the currently active deployment?).With this, things like CI build sequence numbers, build start timestamps or similar could be used to make sure we deploy "in order", possibly skipping deployments if they have been "overtaken" by newer ones.