default context issue with self hosted runner

[lifeofmoo]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug, and:

• The documentation does not mention anything about my problem
• There are no open or closed issues that are related to my problem

Description

Explicitly setting the context to either:

       - name: Build and push
         uses: docker/build-push-action@v5
         with:
           context: "{{defaultContext}}"

or 
       - name: Build and push
         uses: docker/build-push-action@v5
         with:
           context: .

results in this error.

Creating a new builder instance

  /usr/local/bin/docker buildx create --name builder-f2d40647-7bfd-4310-a7a4-7f3dd40aff91 --driver docker-container --buildkitd-flags --allow-insecure-entitlement security.insecure --allow-insecure-entitlement network.host --use
  ERROR: could not create a builder instance with TLS data loaded from environment. Please use `docker context create <context-name>` to create a context for current environment and then create a builder instance with context set to <context-name>

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:

      - name: Set up Docker Context for Buildx
        id: buildx-context
        run: |
          docker context create builders

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          version: latest
          endpoint: builders

      # - name: Build and push
      #   uses: docker/build-push-action@v5
      #   with:
      #     context: "{{defaultContext}}"

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

[crazy-max]

same as #105 (comment)

[crazy-max]

I'm looking at making context creation automatic with this action if TLS data are detected.

[crazy-max]

@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

[davidfrickert]

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:

context info: {
  "Name": "default",
  "Metadata": {},
  "Endpoints": {
    "docker": {
      "Host": "tcp://localhost:2376",
      "SkipTLSVerify": false
    }
  },
  "TLSMaterial": {
    "docker": [
      "ca.pem",
      "cert.pem",
      "key.pem"
    ]
  },
  "Storage": {
    "MetadataPath": "<IN MEMORY>",
    "TLSPath": "<IN MEMORY>"
  }
}

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 contextInfo.Storage.TLSPath == "<IN MEMORY>". Not sure if this is the way to go but it works for me in Gitea actions!

(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 TLSMaterial.docker that needs to be looked at

[crazy-max]

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)

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 Storage.TLSPath that is always set to <IN MEMORY> for default context even if TLS is not used: https://github.com/docker/cli/blob/393de5f44f250e83b473ad7aeb9bd6d94f21e8c9/cli/command/defaultcontextstore.go#L199

[davidfrickert]

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)

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 Storage.TLSPath that is always set to <IN MEMORY> for default context even if TLS is not used: https://github.com/docker/cli/blob/393de5f44f250e83b473ad7aeb9bd6d94f21e8c9/cli/command/defaultcontextstore.go#L199

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.
maybe this does not show up in docker context inspect but is instead fetched in some other way?

[crazy-max]

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.
maybe this does not show up in docker context inspect but is instead fetched in some other way?

Ok after looking a bit more at it, we need to check for TLSMaterial as well. Here is a repro with a compose file:

services:
  docker:
    image: docker:dind
    privileged: true
    volumes:
      - certs:/certs

  cli:
    image: docker:cli
    depends_on:
      - docker
    volumes:
      - certs:/certs

volumes:
  certs:

$ docker compose run --rm cli buildx create --use
ERROR: could not create a builder instance with TLS data loaded from environment. Please use `docker context create <context-name>` to create a context for current environment and then create a builder instance with context set to <context-name>

[crazy-max]

@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

[davidfrickert]

@davidfrickert Should work with latest changes from #341 if you want to give it a try, thanks!

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?