-
Notifications
You must be signed in to change notification settings - Fork 145
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
default context issue with self hosted runner #311
Comments
same as #105 (comment) |
I'm looking at making context creation automatic with this action if TLS data are detected. |
@lifeofmoo Can you test my changes from #341 please and let me know if it works for you?: -
name: Set up Docker Buildx
uses: crazy-max/docker-setup-buildx-action@docker-context-tls |
hey @crazy-max , i have the same issue, your PR did not work for me, but very close! diff here: crazy-max/docker-setup-buildx-action@docker-context-tls...davidfrickert:docker-setup-buildx-action:docker-context-tls of a working action (at least for my setup) and also log of my context info:
I do not have TLSData in the endpoints so your PR's action doesn't create the context, so in my commit i replaced that with checking (ofc ignore the changes from debug to info i just changed that because i couldn't get the debug to work) Edit: probably it's |
The right condition in Buildx is on default context with TLS data loaded: https://github.com/docker/buildx/blob/d130f8ef0aea99ed9dc53c808e0bc77a8fc622c0/builder/builder.go#L489 Not |
i see.. but in my case i get the exact error in the code line you linked but i do not have TLSData on the context. |
Ok after looking a bit more at it, we need to check for services:
docker:
image: docker:dind
privileged: true
volumes:
- certs:/certs
cli:
image: docker:cli
depends_on:
- docker
volumes:
- certs:/certs
volumes:
certs:
|
@davidfrickert Should work with latest changes from #341 if you want to give it a try, thanks! -
name: Set up Docker Buildx
uses: crazy-max/docker-setup-buildx-action@docker-context-tls |
Amazing will give it a try later today! Probably out of scope for this issue but would it be possible to cache builders to make use of the cache? |
I guess you mean the local state where build cache is saved, then no for now, see #138
Thanks! |
Actually meant creating a named context and builder (if not exists of course), and not deleting it at the end, so that it can be reused in later executions and it can use the cache. |
Tested in my Gitea Actions setup, works nicely! Log snippet:
|
In this case I suggest to create the builder manually on your self-hosted runner so any build running will use it: # create docker context without tls data
$ docker context create buildxctx
# create the builder using created docker context and use it by default
$ docker buildx create --name mybuilder --use --bootstrap buildxctx
Awesome! Do you have a public link to your pipeline btw? |
sorry, no, it is a private repo. but i can share the pipeline YAML here:
|
Contributing guidelines
I've found a bug, and:
Description
Explicitly setting the context to either:
results in this error.
Creating a new builder instance
Expected behaviour
I expect the default context to be used as it's mentioned a few times in the ENV log output.
Actual behaviour
I can only get my workflow to run and successfully push to an AWS ECR, if I remove the above and use this instead:
I got the inspiration from this similar issue.
Is anyone able to explain why this approach works please? It's more for my understanding and ability to debug issues in future.
Regards,
Benny
Repository URL
No response
Workflow run URL
No response
YAML workflow
N/A
Workflow logs
No response
BuildKit logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: