cli: better indicate why a deployment couldn't be hotswapped #22784
Comments
echeung-amzn
added
feature-request
|
We will throw this when we detect a change in the template that is one of
If you encounter this error and then run I am marking this issue as p2, which means that we are unable to work on this immediately. We use +1s to help prioritize our work, and are happy to revaluate this issue based on community feedback. You can reach out to the cdk.dev community on Slack to solicit support for reprioritization. Check out our contributing guide if you're interested in contributing yourself - there's a low chance the team will be able to address this soon but we'd be happy to review a PR 🙂 |
peterwoodworth
added
p2
effort/small
|
@comcalvi is working on something that may also address this, assigning and cc'ing for visibility. |
…fall back if necessary (#23653) Changes the behavior of `--hotswap` to ignore all non-hotswappable changes and hotswap what it can. This works at two levels: changes to non-hotswappable resources are ignored, as well as non-hotswappable changes to hotswappable resources (eg `Tags` on a Lambda Function). In addition, non-hotswappable changes are now logged; the logical ID, rejected changes, resource type, and reason why the changes were rejected are all provided for each non-hotswappable change. At some point, support for tags of lambda functions was added. This either broke or simply never worked, and so this PR removes all logic to handle Tags. The existing behavior of `--hotswap` can be used in `--hotswap-fallback`. It is preserved and unmodified by this change. Closes #22784, #21773, #21556, #23640. ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https:/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Construct Runtime Dependencies: * [ ] This PR adds new construct runtime dependencies following the process described [here](https:/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https:/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Describe the feature
When attempting a hotswap deployment, it can fail to do so and fallback to a full deployment with a message like:
However, it does not actually indicate what the non-Asset changes are that are preventing a hotswap deployment from working. It can be quite challenging to grok through a stack to narrow down what the issue is.
Since there's already logic to find the non-hotswappable changes, it'd be nice if the CLI either outputted the list of resource by default, or behind a flag.
Use Case
I'd love to use a hotswap deployment to save time when testing changes in a Lambda function's code assets. Having it fallback to full deployments every time introduces a frustrating amount of churn in the development cycle.
Proposed Solution
Perhaps behind a verbose logging flag, be able to list out the non-hotswappable changes when a hotswap deployment is attempted but fails.
Other Information
No response
Acknowledgements
CDK version used
2.46.0
Environment details (OS name and version, etc.)
macOS 12.6 but not relevant
The text was updated successfully, but these errors were encountered: