Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feature request: option to invalidate CloudFront distribution for s3-deployment #3106

Closed
1 of 5 tasks
clareliguori opened this issue Jun 27, 2019 · 8 comments
Closed
1 of 5 tasks

feature request: option to invalidate CloudFront distribution for s3-deployment #3106

clareliguori opened this issue Jun 27, 2019 · 8 comments
Labels
@aws-cdk/aws-cloudfront Related to Amazon CloudFront @aws-cdk/aws-s3 Related to Amazon S3 feature-request A feature should be added or improved.

Comments

@clareliguori
Copy link
Member

  • I'm submitting a ...

    • 🪲 bug report
    • 🚀 feature request
    • 📚 construct library gap
    • ☎️ security issue or vulnerability => Please see policy
    • ❓ support request => Please see note at the top of this template.

  • What is the current behavior?
    If the current behavior is a 🪲bug🪲: Please provide the steps to reproduce

s3-deployment can't be easily used for many static websites, because a CloudFront distribution needs to be invalidated after new files are uploaded to S3 (assuming you want the new files to show up immediately to users after a deployment, and not wait for the edge caches to expire).

  • What is the expected behavior (or behavior of feature suggested)?

Provide an option for passing in a cloudfront.IDistribution and a list of invalidation paths. The s3-deployment Lambda function should create an invalidation, and then wait for that invalidation to complete.

  • What is the motivation / use case for changing the behavior or adding this feature?

Static websites
@clareliguori clareliguori added the needs-triage This issue or PR still needs to be triaged. label Jun 27, 2019
@clareliguori
Copy link
Member Author

Example addition to BucketDeploymentProps:

  /**
   * The CloudFront distribution using the destination bucket as an origin.
   * Files in the distribution's edge caches will be invalidated after
   * files are uploaded to the destination bucket.
   *
   * @default No invalidation occurs
   */
  readonly distribution?: cloudfront.IDistribution;

  /**
   * The file paths to invalidate in the CloudFront distribution.
   *
   * @default All files under the destination bucket key prefix will be invalidated.
   */
  readonly distributionPaths?: string[];

@NGL321 NGL321 added @aws-cdk/aws-cloudfront Related to Amazon CloudFront feature-request A feature should be added or improved. @aws-cdk/aws-s3 Related to Amazon S3 and removed needs-triage This issue or PR still needs to be triaged. labels Jun 27, 2019
@NGL321
Copy link
Contributor

NGL321 commented Jun 27, 2019

Hi Clare!

Thank you for posting. This definitely sounds like something worth looking into.

While we work on getting the APIs aligned with our guidelines, we are pausing work on most community feature-requests. Please continue to report issues and submit feature requests, of course.

We expect to get back to work on community features within a few weeks.

@eladb
Copy link
Contributor

eladb commented Jun 30, 2019

+1 totally agree

Assets now expose both source hash (synth-time) and artifact hash (deploy-time) which can be used to automatically invalidate based on source changes.

@hoegertn
Copy link
Contributor

hoegertn commented Jul 1, 2019

If you like, I can have a look at this. I need it for my current project. @eladb @clareliguori

@clareliguori
Copy link
Member Author

I started on this, but got pulled off to something else while trying to figure out unit tests and Python SDK mocking for the deployment Lambda function. I also have not looked into comparing the source hash and artifact hash before doing invalidation. Happy for someone to take over:
clareliguori@047d654

@hoegertn
Copy link
Contributor

hoegertn commented Jul 2, 2019

This looks like a very good start. I am happy to take over.

@hoegertn hoegertn mentioned this issue Jul 5, 2019
Merged
eladb pushed a commit that referenced this issue Aug 5, 2019
@hoegertn
feat(s3-deployment): CloudFront invalidation (#3213)
e84bdd6 
see #3106
eladb pushed a commit that referenced this issue Aug 6, 2019
@hoegertn
feat(s3-deployment): CloudFront invalidation (#3213)
297d91a 
see #3106
@hoegertn
Copy link
Contributor

hoegertn commented Aug 7, 2019

I think this can be closed

mergify bot pushed a commit that referenced this issue Aug 7, 2019
@mergify
feat(eks): programmatic definition of kubernetes resources (#3510)
4e11d86 
* chore: update package-lock.json

* feat(eks): define kubernetes resources

This change allows defining arbitrary Kubernetes resources within an EKS cluster.

* nice!

* update readme

* Update README.md

* feat(events): ability to add cross-account targets (#3323)

This adds the capability of adding a target to an event rule
that belongs to a different account than the rule itself.
Required for things like cross-account CodePipelines with source actions triggered by events.

* chore(ci): add mergify config file (#3502)

* chore: update jsii to 0.14.3 (#3513)

* fix(iam): correctly limit the default PolicyName to 128 characters (#3487)

Our logic for trimming the length of the default IAM policy name was not working,
as it wasn't updated when logicalId became a Token rather than a literate string,
and so it was never actually triggered
(it just checked that the display name of the Token was less than 128 characters,
which it always is).
The fix is to resolve the logical ID Token before applying the trimming logic.

Fixes #3402

* v1.3.0 (#3516)

See CHANGELOG

* fix: typo in restapi.ts (#3530)

* feat(ecs): container dependencies (#3032)

Add new addContainerDependencies method to allow for container dependencies
Fixes #2490

* feat(s3-deployment): CloudFront invalidation (#3213)

see #3106

* docs(core): findChild gets direct child only (#3512)

* doc(iam): update references to addManagedPolicy (#3511)

* fix(sqs): do not emit grants to the AWS-managed encryption key (#3169)

Grants on the `alias/aws/sqs` KMS key alias are not necessary since the
key will implicitly allow for it's intended usage to be fulfilled (as
opposed to how you have to manage grants yourself when using a
user-managed key instead).

This removes the statement that was generated using an invalid resource
entry.

Fixes #2794

* fix(lambda): allow ArnPrincipal in grantInvoke (#3501)

Fixes #3264 

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

    aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

    myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error:

    Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

This PR allows ArnPrincipal to be passed to lambda.grantInvoke.

There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission

* chore(contrib): remove API stabilization disclaimer

* fix(ssm): add GetParameters action to grantRead() (#3546)

* misc

* rename `KubernetesManifest` to `KubernetesResource` and `addResource`
* move AWS Auth APIs to `cluster.awsAuth` and expose `AwsAuth`
* remove the yaml library (we can just use a JSON stream)
* add support for adding accounts to aws-auth
* fix cluster deletion bug
* move kubctl app info to constants

* addManifest => addResource

* update test expectations

* add unit test for customresrouce.ref

* fix sample link
@clareliguori
Copy link
Member Author

Fixed by #3213

@datariomj datariomj mentioned this issue Feb 12, 2020
Closed
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
@aws-cdk/aws-cloudfront Related to Amazon CloudFront @aws-cdk/aws-s3 Related to Amazon S3 feature-request A feature should be added or improved.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@clareliguori @eladb @hoegertn @NGL321