GHES: parameter token or opts.auth is required

[zetaab]

Behaviour

Steps to reproduce this issue

1. use this action in GHES

Expected behaviour

I expect that it should work like before

Actual behaviour

Configuration

• Repository URL (if public):
• Build URL (if public):

jobs:
  build:
    runs-on:
    - self-hosted
    timeout-minutes: 15
    steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: 0

    - uses: actions/setup-go@v3
      with:
        go-version: 1.19

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

Logs

Download the log file of your build
and attach it to this issue.

[zetaab]

@crazy-max & co. I see that you are doing lots of commits currently to GHES items as well. However, like newest instructions says that use tag v3. However, no such tag exists in this repository? At least I did not like the way the backwards compatibility is handled here. All of our nightly builds failed and all pipelines are currently broken which uses this action.

If I understand this correctly, everything were working without token until #191 & #192 and now everyone should start making PATs in github.com if using GHES? Well...

[crazy-max]

@zetaab

like newest instructions says that use tag v3.

It should be docker/setup-buildx-action@v2 in the instructions, will fix this.

If I understand this correctly, everything were working without token until #191 & #192 and now everyone should start making PATs in github.com if using GHES? Well...

We got an issue yesterday #190 with a GitHub API endpoint we were using to check releases on buildx repository. We have to switch to the official Octokit client.

Looking at your workflow it should use the current Buildx version available on your runner. I will take a look.

[zetaab]

why we should have buildx located in runner beforehand? It does not support downloading buildx anymore? We are hosting our github action runners in kubernetes. The runners will download the packages that they need, and now it looks like it does not work anymore.

[crazy-max]

why we should have buildx located in runner beforehand? It does not support downloading buildx anymore?

https://github.com/docker/setup-buildx-action#using-on-ghes

On public runners Buildx is pre-installed: https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md

If not found then we need to check latest stable on Buildx repo which uses the GitHub API. Previously we could make unauth call to a specific endpoint https://github.com/docker/buildx/releases/latest but it broke yesterday without notice 😣

I will check if we can just host ourselves the latest version on buildx repo so we don't need any API calls.

In the meantime you can have this step before the docker/setup-buildx-action step:

  - name: Download buildx
    run: |
      mkdir -p ~/.docker/cli-plugins
      wget https://github.com/docker/buildx/releases/download/v0.10.1/buildx-v0.10.1.linux-amd64 -O ~/.docker/cli-plugins/docker-buildx
      chmod +x ~/.docker/cli-plugins/docker-buildx

[zetaab]

yeah it seems to work if we cache buildx to the runner image

[crazy-max]

@zetaab #196 should help for your case. You can try with crazy-max/docker-setup-buildx-action@dl-no-token.