to push updated counts file to S3 bucket nextstrain-data. However, despite the existence of cloudfront-invalidate script, I'm pretty sure the invalidation is not called as part of the GitHub Action workflow.
I discovered this today when I was trying to update the forecasts to include clade 23B. This was in the available metadata, but just running the GitHub Action (or walking through the commands called by the GitHub Action), resulted in a push to S3, but not an invalidation. I just fixed today's issue with a manual invalidation from the AWS Console.
Expected behavior
When files are pushed to the S3 bucket nextstrain-data, these files should be invalidated on the CloudFront domain fronting data.nextstrain.org.
Current Behavior
When
update-ncov-gisaid-clade-counts.yaml
orupdate-ncov-open-clade-counts.yaml
are run, they run:to push updated counts file to S3 bucket
nextstrain-data
. However, despite the existence ofcloudfront-invalidate
script, I'm pretty sure the invalidation is not called as part of the GitHub Action workflow.I discovered this today when I was trying to update the forecasts to include clade 23B. This was in the available metadata, but just running the GitHub Action (or walking through the commands called by the GitHub Action), resulted in a push to S3, but not an invalidation. I just fixed today's issue with a manual invalidation from the AWS Console.
Expected behavior
When files are pushed to the S3 bucket
nextstrain-data
, these files should be invalidated on the CloudFront domain fronting data.nextstrain.org.