pathogen-repo-ci: Log in to docker.io and ghcr.io if possible#38
pathogen-repo-ci: Log in to docker.io and ghcr.io if possible#38
Conversation
ae31ddb to
85745d4
Compare
This lifts low rate limits on image pulls. However, calling workflows must explicitly opt in with "secrets: inherit" in order for this reusable workflow to be able to see the org-level secret containing the token. Related-to: <nextstrain/docker-base#148>
This allows the use of docker-base images we transiently stage at ghcr.io before publishing to docker.io. A new "permissions:" block with "packages: read" restricts the ghcr.io access to read-only. This addition requires explicitly enumerating the rest of the required permissions too, which is only "contents: read" for actions/checkout. Related-to: <nextstrain/docker-base#148>
85745d4 to
83e7441
Compare
|
The annotations when one of the optional login steps fails are kinda annoying in the UI: (screenshot from using this workflow in nextstrain/docker-base#148) |
joverlee521
left a comment
There was a problem hiding this comment.
Too bad about the annoying error outputs...Would it be too hacky to check if secrets.DOCKER_TOKEN_PUBLIC_READ_ONLY exists in a separate step before "Log in to docker.io"?
|
Hmm, yeah, that would work. We could also ditch |
Maybe this will help with nextstrain/docker-base#131... |
…et isn't available Even though a login that fails due to the missing secret doesn't affect the workflow's execution status, it does clutter the workflow's summary page with a bunch of noisy warnings. Suggestion to do this pre-check from @joverlee521 in review. If only we could check for secrets directly in a step condition ("if: …").
|
Pushed 906908a to conditionalize the docker.io login on the presence of the secret, to avoid the annoying warnings. \o/ It works without the secret: and with it: |
21d5297 to
906908a
Compare
| # Log in, if possible, to docker.io (Docker Hub), since authenticated | ||
| # requests get higher rate limits (e.g. for image pulls). Our org-level | ||
| # secret DOCKER_TOKEN_PUBLIC_READ_ONLY is available to all our public | ||
| # repos on GitHub but only available here to this reusable workflow when | ||
| # called with "secrets: inherit". On Docker Hub, the token is granted | ||
| # "public read-only" access. |
@victorlin pointed out¹ that we could launder access to the secrets context thru the step env context without the need for an extra step. I avoid putting the secret itself into the environment (which only increases its potential visibility) and put only its presence/absence instead. ¹ <#38 (comment)>



See commit messages.
Related-to: nextstrain/docker-base#148
Testing