docker / docker/setup-buildx-action
allow endpoint derivation from env
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.4k
- Forks
- 263
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 13
Description
Description
For a self-hosted runner I manage, I configured the env the runner with the envs BUILDKIT_HOST, BUILDER_NODE_0_AUTH_TLS_CERT, BUILDER_NODE_0_AUTH_TLS_CERT, and BUILDER_NODE_0_AUTH_TLS_CACERT
and I had the following in my github actions workflow:
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v4
with:
driver: remote
This isn't working because it's not picking up the BUILDER_NODE_0_AUTH_TLS_CERT, BUILDER_NODE_0_AUTH_TLS_CERT, and BUILDER_NODE_0_AUTH_TLS_CACERT if the endpoint input is not explictly provided even though it does use the BUILDKIT_HOST endpoint url. (If I tried serving the buildkitd without the TLS, it works)
It would be ideal that the users wouldn't need to have know and specify the endpoint
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the action's remote-driver input handling and reproduce the workflow using BUILDKIT_HOST plus the BUILDER_NODE_0_AUTH_TLS_CERT and BUILDER_NODE_0_AUTH_TLS_CACERT environment variables without an endpoint input. Done means the endpoint and TLS settings are derived from the environment and the self-hosted runner can connect to the TLS-enabled BuildKit daemon.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, github-actions
- Domain
- ci-cd, devops
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100