-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: Add Cloudfront invalidation example for S3 deployment #12238
Conversation
Title does not follow the guidelines of Conventional Commits. Please adjust title before merge. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for the contribution @gibzon69 , it looks great! Some minor comments below.
invalidateBuildProject.addToRolePolicy( | ||
new iam.PolicyStatement({ | ||
effect: iam.Effect.ALLOW, | ||
resources: ['*'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, is there a way to reduce these permissions? Do they all have to have "*"
? Can at least some of them be scoped downed to the Distribution that we're invalidating?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup!
I had some old info, that CF didn't have resource level permissions, but they do. So I'm changing so that we only need CreateInvalidation and only for the specific distribution.
Co-authored-by: Adam Ruka <[email protected]>
Pull request has been modified.
I'm glad I could be of help, and thanks for the input! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @gibzon69 ! A few minor suggestions, but I'll apply them myself, and merge the PR later.
Thanks so much!
Pull request has been modified.
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This workaround was discussed in this issue: aws#6243 (comment) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
}); | ||
|
||
// Add Cloudfront invalidation permissions to the project | ||
const distributionArn = `arn:aws:cloudfront::${this.account}:distribution/${distribution.distributionId}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe use process.env.CDK_DEFAULT_ACCOUNT
instead of this.account
. The env var for the account should be set automatically as far as I understood.
One workaround is to add another build step after the deploy step, | ||
and use the AWS CLI to invalidate the cache: | ||
|
||
```ts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add necessary additional import of import * as iam from '@aws-cdk/aws-iam'
This workaround was discussed in this issue: #6243 (comment)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license