Closed mike-thompson-day8 closed 3 years ago
@superstructor To help Jim solve the issue, can we add a git version display to the client. Perhaps display it in the LHS bottom of UI.
Version added in ee61bb9
@mike-thompson-day8 @superstructor
By default, CloudFront caches a response from Amazon S3 for 24 hours (Default TTL of 86,400 seconds). If your request lands at an edge location that served the Amazon S3 response within 24 hours, CloudFront uses the cached response even if you updated the content in Amazon S3.
once you deploy you will need to invalidate the cache using the was cli. The following will invalidate all the objects.
aws cloudfront create-invalidation --distribution-id E1CF3UN5J17VYY --paths "/*".
There is also this github action you can use
https://github.com/marketplace/actions/invalidate-cloudfront
# Invalidate Cloudfront (this action)
- name: invalidate
uses: chetan/invalidate-cloudfront-action@master
env:
DISTRIBUTION: ${{ secrets.DISTRIBUTION }}
PATHS: '/index.html'
AWS_REGION: 'us-east-1'
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
Hope this helps. Reach out if you need more help
The demo app is now published to s3 on every git push to master (via Github Actions)
But the new state of the app takes forever to show up via the URL https://re-com.day8.com.au/. We guess there's a Cloudfront caching issue.
Note: changes are immediately available via the direct S3 bucket URL: https://re-demo.s3-ap-southeast-2.amazonaws.com/index_prod.html
So, should we figure out the Cloudfront issue or run away like the AWS complexity cowards that we are and just avoid the issue and direct people to the s3 URL?