Closed anthonyma94 closed 2 weeks ago
I've recently hit this too I think. In my case it only reproduces when I'm using docker/setup-buildx-action
too, which lead me to find https://github.com/docker/buildx/issues/847 which appears related.
Running docker images ls -a
after the first of my builds does list the issue, which also suggests to me that this is related to buildx having a different view of the available images.
I've found a partial workaround for my case, though it may not work for all cases. When setting up for the second build, I'm calling docker/setup-buildx-action
again with diver: docker
and then explicitly using that builder in my subsequent build. This works around this issue by not using buildx for that second build.
This is expected as you're using the setup-buildx-action
which will create a container builder which therefore does not have access to the docker store where your image is loaded.
You can either set driver: docker
in setup-buildx-action
step as suggested by @PeterJCLaw:
- uses: docker/setup-buildx-action@v3
with:
driver: docker
Or you can push the image to a local registry that can be accessed by the container builder. Would need to add an ARG
to set the base image in your Dockerfile first:
ARG BASE_IMAGE=dmca-base:latest
FROM $BASE_IMAGE
ARG TAG
ARG INIT_SENTRY
And then in your workflow set up the local registry, load the image and push it to the local registry and then set the build arg in build-push-action:
build-prod:
runs-on: ubuntu-latest
services:
registry:
image: registry:2
ports:
- 5000:5000
needs: [build-base, build-dist]
strategy:
matrix:
app: ${{ fromJson(needs.build-dist.outputs.affected) }}
name: Build and push ${{ matrix.app }} image
steps:
- uses: docker/setup-buildx-action@v3
- name: Download dist artifact
uses: actions/download-artifact@v4
with:
name: dist
path: dist
- name: Download base Docker image
uses: actions/download-artifact@v4
with:
name: ${{ env.BASE_DOCKER_IMAGE }}
path: /tmp
- name: Load base Docker image and push to local registry
run: |
docker load --input /tmp/${{ env.BASE_DOCKER_IMAGE }}.tar
docker tag ${{ env.BASE_DOCKER_IMAGE }} localhost:5000/foo/bar:latest
docker push localhost:5000/foo/bar:latest
- name: Login to Github Packages
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push ${{ matrix.app }}
uses: docker/build-push-action@v5
with:
context: dist/apps/${{ matrix.app }}
build-contexts: |
${{ env.BASE_DOCKER_IMAGE }}=docker-image://${{ env.BASE_DOCKER_IMAGE }}:latest
tags: |
ghcr.io/domain/${{ matrix.app }}:${{ github.event.release.tag_name || 'latest' }}
ghcr.io/domain/${{ matrix.app }}:latest
build-args: |
BASE_IMAGE=localhost:5000/foo/bar:latest
TAG=${{ github.event.release.tag_name }}
push: false
But first suggestion is the one you should use looking at your workflow as you're not using advanced BuildKit features (such as multi-platform, cache exporters)
@crazy-max thanks for confirming what's happening here. Do you think there's anything which could be done to help the error message in this case? It's somewhat non-obvious what the issue is if you're coming to this issue without already knowing the internals of how the builders stuff works. Relatedly I imagine most people will have used buildx locally via e.g: docker buildx build
and the like, which I thiiiink don't have the same issue -- in that case if I recall correctly, no additional steps are needed for buildx builds to be able to see other local images.
Contributing guidelines
I've found a bug, and:
Description
Following docs from here and here, I've built a local image on one job (
build-base
) and uploaded the artifact, then downloaded and restored it on another (build-prod
) and added it to build context. However, it still tries to pull the local image from external registry and fails.Expected behaviour
It should read local image
Actual behaviour
Doesn't read local image
Repository URL
No response
Workflow run URL
No response
YAML workflow
Workflow logs
BuildKit logs
No response
Additional info
No response