Open hashhar opened 2 years ago
The fix should go here https://github.com/docker/setup-buildx-action/blob/79abd3f86f79a9d68a23c75a09a9a85889262adf/src/main.ts#L99
It should be running docker buildx uninstall
to remove alias (if configured).
@hashhar Can you post your workflow?
Not the exact workflow but a minimal reproduction I was able to verify with.
If you run:
name: Build multi-platform image
on:
workflow_dispatch:
jobs:
buildx:
runs-on: [self-hosted, very-specific-label-to-match-just-one-machine]
steps:
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- uses: docker/setup-buildx-action@v1
id: buildx
with:
install: true # NOTICE THE install: true which installs the alias (but doesn't remove it)
- name: Inspect builder
run: |
echo "Name: ${{ steps.buildx.outputs.name }}"
echo "Endpoint: ${{ steps.buildx.outputs.endpoint }}"
echo "Status: ${{ steps.buildx.outputs.status }}"
echo "Flags: ${{ steps.buildx.outputs.flags }}"
echo "Platforms: ${{ steps.buildx.outputs.platforms }}"
Then run the next one on same hosted runner:
name: "release"
on:
workflow_dispatch:
jobs:
get-starburst-enterprise-repo-sha:
runs-on: [ self-hosted, very-specific-label-to-match-just-one-machine ]
name: Get repo SHA
steps:
- name: Dump environment
uses: hmarr/debug-action@v2.0.0
- name: Cleanup node
uses: AutoModality/action-clean@1.1.0
You'll get into situation as described above.
Note that self-hosted runners aren't ephemeral necessarily so any changes you make to the machine itself will persist and observed by future workflows.
To confirm you can add a step like:
- name: Inspect docker client config
run: cat ~/.docker/*
It'll show that an alias has been added to execute buildx
when build
is used (as described in your docs for the install: true
input to the action.
This action should run
docker buildx uninstall
in the post-step of the action to ensure any future runs on same machine use the traditional builder when invoked viadocker build
unless configured otherwise.
I think removing the alias in a post step would not solve your issue but makes it worst. Using install
on a self-hosted runner is racy. If you trigger multiple runs on the same runner then docker buildx uninstall
could run in the middle of another workflow. I think in your case you should set first an unique Docker config path for each run and cleanup afterwards like:
jobs:
buildx:
runs-on: [self-hosted, very-specific-label-to-match-just-one-machine]
steps:
-
name: Set Docker config
run: |
dockerConfig=${HOME}/.docker-${{ env.GITHUB_RUN_ID }}
mkdir -p "${dockerConfig}"
echo "DOCKER_CONFIG=${dockerConfig}" >> $GITHUB_ENV
-
name: Set up Buildx
uses: docker/setup-buildx-action@v2
with:
install: true
# ... more steps to build, etc...
-
# last step for this job
name: Cleanup Docker config
if: always()
run: |
rm -rf ${DOCKER_CONFIG}
Behaviour
Steps to reproduce this issue
docker build
is usingbuildx
instead of traditional builder.Expected behaviour
This action should run
docker buildx uninstall
in the post-step of the action to ensure any future runs on same machine use the traditional builder when invoked viadocker build
unless configured otherwise.Actual behaviour
The alias installed by this action isn't removed and hence all future calls to
docker build
end up going throughbuildx
instead of traditional builder.Logs
This applies across runs so logs of run don't make sense. However it manifest like:
This output suggests that buildx got used even when the command was
/usr/bin/docker build -t fee7dc:3ef02aa84a984bee8d616813f987552e -f "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0/Dockerfile" "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0"