Skip to content

Bug: "No changes to deploy" is inappropriately treated as an error condition. #8017

Open
@garretwilson

Description

@garretwilson

Description:

If the SAM CLI tries to deploy a template that does not result in any changes, it appropriately skips the deployment. However it reports this as an error by returning a non-zero error code 1 from the CLI. This breaks automation scripts that need to deploy several stacks, but abort if there is an error with one of them.

If there are no changes to deploy, that is not an error! Nothing has gone wrong. Everything is functioning correctly. Treating this is an error state is incorrect and harmful, and breaks automation scripts.

If an automation script needs to make sure that a list of five stacks are updated, it needs to check whether the deployment succeeded, and abort if a deployment failed. For example, the deployment may fail if there is a syntax error in the SAM template YAML. Here is Bash code to abort if there is an error (i.e. the CLI returns a non-zero result code):

sam deploy --template-file sam.yaml --stack-name foo-bar … || return

Note the || return, which is the most correct way to return/exit and propagate the error code in Bash if there is an error. However returning a 1 when there are no changes to make will make the automation script think an error occurred, when in fact there was no error at all. Everything is 100% OK. The deployment was successful, it's just that the deployment didn't require changes.

Unfortunately there seems to be no easy workaround possible, because the CLI returns a general error code 1. Thus the calling script cannot determine whether this was a real error such as a broken template (or a duplicate S3 bucket or whatever), or this non-error of "oh, no, everything was already up-to-date".

Steps to reproduce:

Deploy the same stack twice in a row with the SAM CLI without making modifications.

Observed result:

On the second deployment, the SAM CLI will say:

Error: No changes to deploy. Stack foo-bar is up to date

Significantly the CLI returns an error code, specifically 1.

Expected result:

If there are no changes to deploy, the CLI should return a code indicating "no-error", specifically 0.

The CLI should at most indicate a warning:

Warning: No changes to deploy. Stack foo-bar is up to date

Nevertheless the bug here is the CLI return code; the actual wording displayed is not breaking anything.

At a minimum a unique, documented error code should be returned so that the calling script can at least determine if this was really an error.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

{
  "version": "1.135.0",
  "system": {
    "python": "3.12.6",
    "os": "Windows-10-10.0.19045-SP0"
  },
  "additional_dependencies": {
    "docker_engine": "Not available",
    "aws_cdk": "Not available",
    "terraform": "Not available"
  },
  "available_beta_feature_env_vars": [
    "SAM_CLI_BETA_FEATURES",
    "SAM_CLI_BETA_BUILD_PERFORMANCE",
    "SAM_CLI_BETA_TERRAFORM_SUPPORT",
    "SAM_CLI_BETA_RUST_CARGO_LAMBDA"
  ]
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    stage/needs-triageAutomatically applied to new issues and PRs, indicating they haven't been looked at.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions