-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
JSII libraries with assets not found #1716
Closed
costleya opened this issue
Feb 9, 2019
· 1 comment
· Fixed by #2182 · May be fixed by MechanicalRock/account-reaper#6
Closed
JSII libraries with assets not found #1716
costleya opened this issue
Feb 9, 2019
· 1 comment
· Fixed by #2182 · May be fixed by MechanicalRock/account-reaper#6
Labels
@aws-cdk/assets
Related to the @aws-cdk/assets package
@aws-cdk/core
Related to core CDK functionality
bug
This issue is a bug.
effort/medium
Medium work item – several days of effort
Comments
costleya
added
bug
This issue is a bug.
@aws-cdk/assets
Related to the @aws-cdk/assets package
labels
Feb 9, 2019
Wow, yes! That’s definitely something we need to address. The jsii runtime uses a temporary directory to unpack the module npm tarball and so it can load it at runtime and the assets are contained in this tarball. A few proposals:
|
This was referenced Feb 26, 2019
sam-goodwin
pushed a commit
that referenced
this issue
Mar 1, 2019
This change enables each construct in the tree to participate in synthesis by overriding the synthesize and add "artifacts" and write files to a synthesis session. At the moment, the only construct that implements synthesize is Stack which emits an `aws:cloudformation:stack` artifact which includes a reference to a template file stored into the synthesis session as well. `App.run()` traverses the tree and invokes synthesize on all constructs. When synthesis is finalized, a manifest is produced and stored in the root `manifest.json` file. This is accordance with the draft specification for cloud assemblies as authored by @RomainMuller and included in this change. For backwards compatibility, and until we implement the required changes in the toolkit, the output also contains `cdk.out` which is 100% compatible with the current output. Related #1716 Related #1893
eladb
pushed a commit
that referenced
this issue
Apr 4, 2019
To ensure that assets are available for the toolchain to deploy after the CDK app exists, the CLI will, by default, request that the app will stage the assets under the `.cdk.assets` directory (relative to working directory). The CDK will then *copy* all assets from their source locations to this staging directory and will refer to the staging location as the asset path. Assets will be stored using their content fingerprint (md5 hash) so they will never be copied twice unless they change. Fixes #1716 TODO: - [ ] docker assets - [ ] toolkit support - [ ] toolkit test
eladb
pushed a commit
that referenced
this issue
Apr 4, 2019
To ensure that assets are available for the toolchain to deploy after the CDK app exists, the CLI will, by default, request that the app will stage the assets under the `.cdk.assets` directory (relative to working directory). The CDK will then *copy* all assets from their source locations to this staging directory and will refer to the staging location as the asset path. Assets will be stored using their content fingerprint (md5 hash) so they will never be copied twice unless they change. Docker build context directories will also be staged. Staging is disabled by default and in cdk-integ. Added .cdk.staging to all .gitignore files in cdk init templates. Fixes #1716
eladb
pushed a commit
that referenced
this issue
Apr 8, 2019
To ensure that assets are available for the toolchain to deploy after the CDK app exists, the CLI will, by default, request that the app will stage the assets under the `.cdk.assets` directory (relative to working directory). The CDK will then *copy* all assets from their source locations to this staging directory and will refer to the staging location as the asset path. Assets will be stored using their content fingerprint (md5 hash) so they will never be copied twice unless they change. Docker build context directories will also be staged. Staging is disabled by default and in cdk-integ. Added .cdk.staging to all .gitignore files in cdk init templates. Fixes #1716 Fixes #2096
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/assets
Related to the @aws-cdk/assets package
@aws-cdk/core
Related to core CDK functionality
bug
This issue is a bug.
effort/medium
Medium work item – several days of effort
When trying to use a JSII-built library with assets, those assets will not be found at deployment time. For example, if the library has embedded lambda code, the metadata for the asset will point to a temporary folder. This may be the reason why the .zip file in S3 is empty.
Interesting line in synth:
aws:asset:path: /private/var/folders/0t/_hd2htfd497g3b2z41wlvlx439_1m_/T/jsii-kernel-tL6ToE/node_modules/cdk-dynamo-table-viewer/lib/lambda
Library used: cdk-dynamo-table-viewer
Binding Language Used: C# (.NET)
Synth output:
deploy trace:
The text was updated successfully, but these errors were encountered: