If you run stackit up twice on a template that contains a serverless function and the code doesn't change in between runs, a failure emerges - when it should be a no-op. Output:
[10:12:16] test-stack-packaged - UPDATE_IN_PROGRESS - User Initiated
[10:12:20] Function - UPDATE_IN_PROGRESS
[10:12:21] Function - UPDATE_COMPLETE
[10:12:23] FunctionVersion7b4af - CREATE_IN_PROGRESS
[10:12:23] FunctionVersion7b4af - CREATE_FAILED - A version for this Lambda function exists ( 1 ). Modify the function to create a new version.
[10:12:24] test-stack-packaged - UPDATE_ROLLBACK_IN_PROGRESS - The following resource(s) failed to create: [FunctionVersion7b4af85c00].
[10:12:40] Function - UPDATE_IN_PROGRESS
[10:12:40] Function - UPDATE_COMPLETE
[10:12:42] test-stack-packaged - UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS
[10:12:44] FunctionVersion7b4af - DELETE_SKIPPED
[10:12:44] test-stack-packaged - UPDATE_ROLLBACK_COMPLETE
This (and avoiding unnecessary uploads) is likely why the AWS CLI uses the MD5 of the zip archive as the basename in the S3 key. We should do that (see #30)
If you run
stackit uptwice on a template that contains a serverless function and the code doesn't change in between runs, a failure emerges - when it should be a no-op. Output:This (and avoiding unnecessary uploads) is likely why the AWS CLI uses the MD5 of the zip archive as the basename in the S3 key. We should do that (see #30)