Assets: Add property to retrieve content hash #1400
Comments
RomainMuller
added
enhancement
feature-request
|
One example use case for this would be having Lambda@Edge with CloudFront. These deploys take an awfully long. At least in my case the Edge Lambda code doesn't change so much… so if I could just get the hash of the asset and compare it to the hash of the deployed version I could determine if I need to make a change at all. And when I would not need to make a change to the Edge Lambda, then the whole deployment would be much faster. |
fulghum
added
effort/medium
|
Please notice that we already have a fingerprint of the asset source available during synthesis, which is used to stage the artifact in the staging directory. This issue is about the hash of the artifact, which we can know calculate after the asset is bundled (e.g. the .zip is created, the docker image is produced, etc). Since this information cannot be "sent back in time" to synthesis, we can pass it through as a CloudFormation parameter (together with S3 coordinates/docker image location) and make it available as a token during synthesis. |
Introduces an `IAsset` interface that centralizes common aspects about assets, such as the `sourceHash` and `bundleHash` properties. The `sourceHash` fingerprints the objects that are used as the source for the asset bundling logic, and is available at synthesis time (it can for example be injected in construct IDs when it one wants to ensure a new logical ID is issued for every new version of the asset). The `bundleHash` fingerprints the result of the bundling logic, and is more accurate than `sourceHash` (in that, if the same source can produce different artifacts at different points in time, the `sourceHash` will remain un-changed, but the `bundleHash` will change. The `bundleHash` is however a deploy-time value and thus cannot be used in construct IDs. Fixes #1400
Introduces an `IAsset` interface that centralizes common aspects about assets, such as the `sourceHash` and `bundleHash` properties. The `sourceHash` fingerprints the objects that are used as the source for the asset bundling logic, and is available at synthesis time (it can for example be injected in construct IDs when it one wants to ensure a new logical ID is issued for every new version of the asset). The `bundleHash` fingerprints the result of the bundling logic, and is more accurate than `sourceHash` (in that, if the same source can produce different artifacts at different points in time, the `sourceHash` will remain un-changed, but the `bundleHash` will change. The `bundleHash` is however a deploy-time value and thus cannot be used in construct IDs. Fixes #1400
Introduces an `IAsset` interface that centralizes common aspects about assets, such as the `sourceHash` and `bundleHash` properties. The `sourceHash` fingerprints the objects that are used as the source for the asset bundling logic, and is available at synthesis time (it can for example be injected in construct IDs when it one wants to ensure a new logical ID is issued for every new version of the asset). The `bundleHash` fingerprints the result of the bundling logic, and is more accurate than `sourceHash` (in that, if the same source can produce different artifacts at different points in time, the `sourceHash` will remain un-changed, but the `bundleHash` will change. The `bundleHash` is however a deploy-time value and thus cannot be used in construct IDs. Fixes #1400
As seen in cdklabs/aws-delivlib#20 - it is useful to be able to determine a content hash for an asset so as to allow detection of changes. This also would help support de-duplication of assets during the upload phase.
The text was updated successfully, but these errors were encountered: