-
Notifications
You must be signed in to change notification settings - Fork 11
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
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) |
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.
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. |
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.
Thanks for setting this up!
@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