Expose sourceHash on AssetCode?

[ghost]

Thanks for CDK!

I would like to be able to access the sourceHash of an AssetCode's private asset property.

Use Case

I have a CustomResource and I would like to trigger the associated lambda to run whenever the hash of a certain AssetCode changes. To do this I update a property whenever the AssetCode changes:

    CustomResource(this, 'CustomResource', {
      properties: {
        // When the source hash changes, run migrations by triggering an update to the custom resource.
        sourceHash: props.code.sourceHash
      },
      provider: CustomResourceProvider.lambda(lambda),
      resourceType: 'Custom::MiraMigration'
    })

Proposed Solution

I can workaround the issue by copying the source to AssetCode and using it in my project. The only changes I (seemingly) needed to make were to add a public sourceHash?: string property and to update the bind method to set this.sourceHash when the Asset is instantiated.

Is there a reason this couldn't be added to AssetCode? A better way to trigger the lambda for a CustomResource only when the contents of an AssetCode changes?

Other

Related issue: #2595

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[eladb]

@wprl How would lambda.Code.hash work if the code comes from a parameter or S3 location? I am not sure we can provide a consistent API for all the different types of hashes. Having said that, since lambda.Code.fromAsset basically uses FileAsset under the hood, maybe we should offer a way to pass in a FileAsset object directly lambda.code.fromFileAsset or fromAssetObject (for lack of a better way to distinguish) and then you should have access to the hash.

In general, I like this use case and and I wonder if perhaps we should provide a more first class support for this in custom resources so it happens transparently when their provider changes.

I've recently revamped the CustomResourceProvider surface area and now providers return CustomResourceProviderConfig in response to a bind call. This allows us to extend this return value to include things like providerVersion and implement it through lambda asset hash.

@wprl can you raise another issue with the specific custom-resource use case in mind?

[eladb]

Here you go