I'm using aws cloudformation deploy
in a CI/CD pipeline with the option --no-fail-on-empty-changeset
. This allows the pipeline to deploy all stacks, no matter if there was a change to the template or parameters.
However, aws cloudformation deploy
with the option --no-fail-on-empty-changeset
does create a change set which goes to state FAILED
with reason The submitted information didn't contain changes. Submit different information to create a change set.
. The problem is, that the failed change set does not get deleted. Therefore, hundreds of change sets pile up. Resulting in an LimitExceededException
(ChangeSet limit exceeded for stack ...
) after a while.
In my opinion, aws cloudformation deploy
with option --no-fail-on-empty-changeset
should delete change sets, that failed because of an empty change set. Or there should at least be an option to do so.
I've reproduced this issue and can see how this would be less than ideal. My only concern with automatically deleting the failed change set is that it's technically a breaking change and I don't know if there are potentially customers relying on the failed change set being present.
@sanathkr Any thoughts on how to handle this?
@joguSD Thanks for looking into this. I agree, that others might rely on the current behaviour. Although, that is not very likely. The change set does not contain any valuable information for debugging, in this scenario.
To support users who rely on the current behavior while at the same time solving the problem for others, a new command line argument could be added (say, --cleanup-on-failure
). The default behavior could remain the same as it does now. The new argument would only be relevant in cases where --no-fail-on-empty-changeset
is also specified.
There is a post explaining this in more detail fwiw: https://cloudonaut.io/aws-cli-cloudformation-deploy-limit-exceeded/
Most helpful comment
To support users who rely on the current behavior while at the same time solving the problem for others, a new command line argument could be added (say,
--cleanup-on-failure
). The default behavior could remain the same as it does now. The new argument would only be relevant in cases where--no-fail-on-empty-changeset
is also specified.