-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bucket location patch for the TemplateURL when deploying a stack #101
Conversation
TemplateURL
containing stringified version of a promisegetUrl
public method of ToolkitInfo
base class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping on this issue.
I'm still not 100% sure for which cases this code path is triggered, as I have not been able to trigger it with a 0815 cdk init ...
project & manipulating the stack to be at a size that forces the usage of a TemplateURL
parameter when deploying. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping on this. I'll have a few more comments that we can iterate over after getting he immediate fix over the line. 🚀
getUrl
public method of ToolkitInfo
base class
Description
When S3 is used as a place of store for the CF artifacts, the resolving of the actual
bucketUrl
within our patch would lead to the presence of a stringified version of a promise, i.e.:'[object Promise]/cdk/digitalu-local-services/dbdbe3071265081abdd49572f43ec8168bc6fb4250c190631f9e84f51a5ccb4c.yml'
. Because of this, what was supposed to be the first prefix within the bucket is now considered to be the bucket. Chaos ensues, and the stack fails to deploy because the S3 bucket "does not exist".So instead of using promises for our patched version of
bucketUrl
attribute, we instead determine the bucket name/URL outside of the function associated with it.While doing this, it was also noticed how the
ToolkitInfo
object isn't always aToolkitInfo
object anymore:{}
(empty key-value pair object).BootstrapStackNotFoundInfo
in which case callingbucketUrl
orbucketName
would throw an exception.ExistingToolkitInfo
, which is the ideal case, and also the case when we should patchbucketUrl
attribute.These classes can be observed here: https://github.com/aws/aws-cdk/blob/87e21d625af86873716734dd5568940d41096c45/packages/aws-cdk/lib/api/toolkit-info.ts