brainy-magician-83981
02/27/2019, 4:17 PMpulumi up
... then uncommenting to add the layer resources back ... and running pulumi up
again. Is there a better way of handling this? Thx!white-balloon-205
name
or description
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-83981
02/27/2019, 5:19 PMcrypto sha256 base64
checksum of the associated zip file archive.
So I believe the correct Pulumi behavior is to check for changes in the sourceCodeHash
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 aws lambda publish-layer-version
command).
Because the layer arn has changed, the aws.lambda.Function
will pick up the new layer arns in the layers
field, and thus the function gets updated.
I hope this makes sense.sourceCodeHash
field, or does Pulumi already do this for me?sourceCodeSize
field eventhough I do not explicitly set itdev
stacks, I tag the name of the resources with the zip file's last modified timestamp
.
For prod
and stage
stacks, I tag the name of the resources with the git revision hash.
I believe this strategy will work out.prod
stack deployments ... I believe Pulumi will destroy the resources if they get a new resource name.
For dev
and stage
stacks this is OK, but I assume I will need to mark these resources as protected
for prod
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.