brainy-magician-8398102/27/2019, 4:17 PM
... then uncommenting to add the layer resources back ... and running
again. Is there a better way of handling this? Thx!
to be dependent on something tied to the version you are trying to deploy (like a hash of the contents?). If you are deploying the code to S3 outside of Pulumi, do you then want every Pulumi deployment to update the layer, or only based on some signal? Because coordinating these is often difficult and clumsy, we typically recommend patterns where the code itself is deployed as part of the Pulumi program, so that the lifecycle of all the updates can be managed.
brainy-magician-8398102/27/2019, 5:19 PM
checksum of the associated zip file archive. So I believe the correct Pulumi behavior is to check for changes in the
crypto sha256 base64
value. If it has changed, then Pulumi will need to update the LayerVersion resource. This update will produce a new aws layer arn (ie. the layer version autoincrements on each
command). Because the layer arn has changed, the
aws lambda publish-layer-version
will pick up the new layer arns in the
field, and thus the function gets updated. I hope this makes sense.
field, or does Pulumi already do this for me?
field eventhough I do not explicitly set it
stacks, I tag the name of the resources with the zip file's
last modified timestamp
stacks, I tag the name of the resources with the git revision hash. I believe this strategy will work out.
stack deployments ... I believe Pulumi will destroy the resources if they get a new resource name. For
stacks this is OK, but I assume I will need to mark these resources as
stack deployments because we will want to keep the older versions. There may be other lambda functions that are dependent on the older layer versions.