-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
Create a cleanup handler for the varnish cache to provide 'ban' functionality #5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; couple of comments but mostly around unused vars + gh action versions.
One thought - it might be good to allow this to work if INCOMING_QUEUE
is missing. E.g. if we scale out for 4hours to cope with a known load we might want additional varnish instances running without worrying about bans. (maybe create a ticket for this new behaviour rather than add to this PR)
uses: docker/setup-buildx-action@v2 | ||
with: | ||
driver-opts: | | ||
image=moby/buildkit:v0.10.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this is required any longer, I'll take a note to test removing from Protagonist. It was related to a ghcr/buildkit issue from a few months ago (docker/build-push-action#761 (comment))
Resolves #3
This pull request adds a python script that listens to an SQS queue for deletions and then actions a
ban
request on a varnish cache using tags. This script can be run separately, in it's own docker container, or within the varnish container itself