https://infracost.io logo
Join Slack
Powered by
Good morning! We're running into unauthenticated D...
# general
t
Good morning! We're running into unauthenticated Docker Hub rate limits (100/day) in our Github Actions workflows. I believe it's not possible to log into Docker Hub at the moment the action pulls the Docker image, since it happens before the workflow even starts. We have a pull-through cache on our self-hosted runners, but I think it's not helping because the action uses the 
:latest
tag (ref). Would it be possible to make it so the docker image version can be pinned, so that we're not pulling the image every time? (or if someone knows a way around this particular problem, I'd love to hear it)
w
👋 Good morning! AFAIK it’s not possible for GH Action users to override the image in their yaml, but we can do it on our side (or you can fork the repo if you prefer). Here’s a branch I pushed just now to lock it so you can test if that helps avoid the rate limit, you can use it by: changing 
uses: infracost/infracost-gh-action@master
to 
uses: infracost/infracost-gh-action@locked_version
Also, if you have any feedback/ideas about this GH issue, we’d love to hear it as it seems like we should bump up the priority of that to avoid this sort of issue.
❤️ 1
t
Thanks, I'm trying it now! By the way, to be clear, I don't mind having the version be automatically upgraded. It's just that the 
latest
tag always triggers a pull, so our pull-through cache doesn't help, even if the manifest hasn't changed (if I'm correctly understanding how it works). In other words, it would be fine for me if the version changes, as long as the tag is not 
latest
One other complicating factor is that I can't seem to reliably check the current rate limit status, so I'm not sure how to reliably tell if this has the intended effect without intentionally doing a hundred pulls and breaking CI for who knows how many hours 😕 I'm running this in our workflows:
Copy code
$ token="$(curl -s "<https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull>" | jq -r '.token')"
$ curl -s --head -H "Authorization: Bearer ${token}" <https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest> | grep ratelimit
ratelimit-limit: 100;w=21600
ratelimit-remaining: 100;w=21600
It invariably tells me that I have plenty of pulls remaining, and yet shortly after i get rate limit errors ¯\_(ツ)_/¯
w
By the way, to be clear, I don’t mind having the version be automatically upgraded […] In other words, it would be fine for me if the version changes, as long as the tag is not 
latest
Ah that helps a lot! So maybe we just create 
latest_release
and update it at the same time as latest? we can then point all the CI/CD integrations to that docker tag (we’ll address the longer term needs in #777 )
@little-author-61621 any thoughts on this?
l
Should we have it as the v0.x.y release tag and have a trigger on each release to update it? Checkov do this (https://github.com/bridgecrewio/checkov/blob/master/.github/workflows/build.yml#L244 and https://github.com/bridgecrewio/checkov-action/blob/master/.github/workflows/build.yml#L11) But, happy with another set tag name as well. Would that cause any issues with the cache not updating it though when the tag does change?
w
good point about the stale tag
7 Views
Open in Slack
PreviousNext
Powered by