search

silvermine / serverless-plugin-cloudfront-lambda-edge

Adds Lambda@Edge support to Serverless
MIT License
296 stars 41 forks source link

will issue update to cloudfront even if function didn't change #79

Closed pkit closed 2 years ago

pkit commented 2 years ago

Considering that CloudFront update is slow as hell And it's pointless to update it if function didn't change Maybe it shouldn't update?

aaka3207 commented 2 years ago

+bump, this adds at least 5-10 extra minutes on my CI build.

jthomerson commented 2 years ago

@pkit and @aaka3207 I honestly don't know what you mean by your comments. Please provide a more complete description of the problem if you'd like us to investigate it. Based on the limited information you provided, I doubt that the problem you're encountering is actually from this plugin. The plugin is very simple and just updates the CloudFormation template that Serverless Framework created, making the following changes to it:

  1. modify the execution role for your Lambda function to: a. allow it to be used by Lambda@Edge (the default would just be the regular Lambda service) b. create log groups and put log events with a more broad IAM policy since we don't control the naming of the log groups and can't limit it to the default names that Serverless Framework uses (the L@E service names its log groups differently, including a region in the name)
  2. remove environment variables from any functions that are associated to a CF dist (since L@E doesn't support them)
  3. [optionally] change the function deletion policy to "retain" to avoid problems when you try to delete a stack (because CloudFormation can't delete L@E globally-replicated functions)
  4. add the Lambda function associations to the CloudFront distribution resource

That's it. So there's nothing we're doing there to cause the CF distribution to update each time. Likely you have some other code or plugin that's changing something on the CF distribution resource each time you build/deploy your service. For example, some plugins will put a tag on the stack and resources that contains the current git version number, or last-modified date. If the tags on the distribution change, maybe that's causing the re-deploy.

I'd suggest inspecting the CloudFormation templates that are in the .serverless directory after each deploy, and comparing them for subsequent deploys. That'll allow you to see what's actually changing.

aaka3207 commented 2 years ago

@jthomerson Fair enough, apologies for not providing more details.

Essentially in my case it's always updating because SLS automatically versions, and versioning does a redeployment (of course redeploying functions @edge takes a while). I understand that this plugin needs versionFunctions set to true, but I rarely even modify the code and by constantly re-versioning a function that doesn't change it wastes compute time on my CI/CD deploys.