feature request: option to invalidate CloudFront distribution for CodePipelineActions S3DeployAction

[datariomj]

Ability to invalidate cloudfront distribution from CodePipelineActions S3DeployAction

Use Case

I'm creating a pipeline for static hosting and implementing this feature would simplify everything instead of creating a separate lambda function that will be added to the pipeline for invalidating cloudfront cache.

Proposed Solution

Provide an option for passing in a cloudfront.IDistribution and a list of invalidation paths in S3DeployActionProps that will create the invalidation.

Other

Basically it is this feature request but for S3DeployAction #3106

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[GibzonDev]

This is a great feature request as it's a very common thing one would want to do when working with static websites on Cloudfront with CDK.

Meanwhile, are there any workarounds for such a pipeline solution, without using the S3DeployAction?
For example, using the S3 BucketDeployment referenced in #3106 above. Or somehow being able to make a call with AWS CLI, where CF invalidation is a one-liner.

[skinny85]

@gibzon69 yes, the workaround is to use S3BucketDeployment instead of the S3DeployAction. S3BucketDeployment has an option to do this invalidation.

[GibzonDev]

Thanks for responding!
To be honest, I'm quite new with CDK so even though I tried to use that as a workaround, I didn't figure out how to do it. Within a Pipeline project that is.
Today I ended up adding another CodeBuildAction step after the S3DeployAction with the sole purpose of running this command:
aws cloudfront create-invalidation --distribution-id ${CLOUDFRONT_ID} --paths "/*"
Maybe not the prettiest solution, but it works :)

[skinny85]

That's actually a pretty great workaround @gibzon69 !

Would you mind submitting us a PR adding that trick to the documentation of the S3DeployAction? It's here: https://github.com/aws/aws-cdk/blob/53f092f8a658e7b72adc996a0d06b18f7ca7ab4d/packages/@aws-cdk/aws-codepipeline-actions/README.md#aws-s3-deployment

Thanks,
Adam

[GibzonDev]

Thanks.
I've created a PR. It's linked here.

[rantoniuk]

@skinny85 am I missing something or is S3BucketDeployment.Source currently missing the capability to use codepipeline.Artifact as the source for S3BucketDeployment? The types seem to be incompatible at the moment:

Property 'bind' is missing in type 'Artifact' but required in type 'ISource'.ts(2741)

and generic pipeline.actions compatibility:

Type 'BucketDeployment' is missing the following properties from type 'IAction': actionProperties, bind, onStateChangets(2739)

[skinny85]

Wrong class @warden , you want S3DeployAction. Source is something completely different, in a different module (@aws-cdk/aws-s3-deployment) 🙂.

[skinny85]

Closing this one, as the original ask has been done.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[rantoniuk]

No @skinny85, I am talking exactly about the deployment module - you have suggested using S3DeploymentAction instead of S3DeployAction before and that's what I am trying to use but I fail to see how to use it in the pipeline context.
Are you sure this issue should be closed as done?

[skinny85]

You use it by doing a normal CFN deployment. Nothing special required.

Note that if you want to use the S3DeployAction, you can do CloudFront invalidation very easily in the pipeline: https://github.com/aws/aws-cdk/blob/20a2820ee4d022663fcd0928fbc0f61153ae953f/packages/@aws-cdk/aws-codepipeline-actions/README.md#invalidating-the-cloudfront-cache-when-deploying-to-s3

[rantoniuk]

@skinny85 I must be missing something or there is a misunderstanding, so let me clarify:

I think we agree that using the CodeBuildAction is a workaround, because it includes additional CodePipeline build that consumes additional resources and actually pollutes the target IAM account in cross-IAM scenario:

• it requires complicated IAM permission setup to be able to start the build from the target IAM account
• it requires a CodeBuild in the target IAM account, which for me is an unclean solution, as up till now I did not have any CodeBuild in target account and all builds were realised in the central IAM build account

So, that being said I wanted to try your suggestion:

the workaround is to use S3BucketDeployment instead of the S3DeployAction. S3BucketDeployment has an option to do this invalidation.

but indeed, S3BucketDeployment is in different module as you pointed out and it does not support being in CodePipeline.actions.

This issue was a feature request to be able to do it in CodePipeline actions directly, not via a workaround, so for me this is not yet resolved..

[skinny85]

What I meant was that you have 2 options:

1. Use the S3DeployAction along with the invalidation trick from the ReadMe; or
2. Use the @aws-cdk/aws-s3-deployment module, which will upload your files during a normal CloudFormation deployment. You will need to use the CDK Pipelines module to create a compatible CodePipeline.

Hope this clears this up!

Thanks,
Adam

[abend-arg]

I must support @rantoniuk point that this shouldn't be marked as closed since a workaround is not a properly solution to this matter. S3BucketDeployment needs that the code to deploy exists in the same directory than the infrastructure package which is a use case completely different to S3DeployAction.

I can understand that this feature may have a very low priority in comparison to other issues, but giving you a workaround as a solution is a very cheap outcome.

[Townsheriff]

Lets not forget about http gateway which can be added as origin in cloudfront api route.