Closed kingo55 closed 4 years ago
It's pretty simple to add this, but it will need users to add and set up a lot of variables and assign Cloudfront CreateInvalidation permissions on the objects.
Should we include this? Even optionally / commented out?:
image: atlassian/default-image:2
pipelines:
branches:
master:
- step:
name: Build & publish to production
deployment: production
caches:
- node
script:
- npm install
- npm install -g gulp-cli
- gulp scripts
- gulp publish --awsk $AWS_ACCESS_KEY_ID --awss $AWS_SECRET_ACCESS_KEY --production
- step:
name: Invalidate Cloudfront objects
script:
- pipe: atlassian/aws-cloudfront-invalidate:0.1.3
variables:
AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
DISTRIBUTION_ID: '$AWS_CF_DISTRIBUTION'
PATHS: '$AWS_CF_PATHS'
development:
- step:
name: Build & publish to staging
deployment: staging
caches:
- node
script:
- npm install
- npm install -g gulp-cli
- gulp scripts
- gulp publish --awsk $AWS_ACCESS_KEY_ID --awss $AWS_SECRET_ACCESS_KEY
@kingo55 I think this will be handy to include, but as you said, commented out by default given it probably is a "nice to have" feature for most users.
Cool - will get this added then. I might remove the echo "Publishing container code..."
commands and place them into the Bitbucket dedicated name
key instead. e.g. name: Build & publish to production
.
It's more useful in the Bitbucket interface then.
Bitbucket released a new pipeline for Cloudfront invalidation. Cloudfront edges cache files for quite a long time, so it might be useful for us to invalidate old containers in Cloudfront:
https://bitbucket.org/atlassian/aws-cloudfront-invalidate/src/master/
This could speed up the time it takes for production containers to roll out after we push them live, but still allow us to keep the containers primed in the edges' cache for fast access >90% of the time.