-
-
Notifications
You must be signed in to change notification settings - Fork 738
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
dockerutil.BuildEmptyImage() fails with bad API version #646
Comments
Interesting... need to investigate/repro. Either way, the next release should address this. Check back a bit later or follow me on Github or Twitter to be notified when the new release is out. |
Sounds good, thanks. I'll see how the next version works out. We're still having some build issues, but it looks like if we set a |
For reference, other versions may work (
in our pipeline |
@jimcottrell this might work as-is https://github.com/mintoolkit/mint/releases/tag/1.41.1 let me know if you still have problems there |
I've tried with v1.41.1 and no explicit |
@jimcottrell which version of Docker do you have installed? Are you on Mac or Linux? If you are on Linux are you using Docker Desktop or only Docker Engine? If you are on a Mac is it an AMD or an M1/M2? Trying to repro... more info on your environment will help |
Getting this on Fedora 39 with the latest stable docker-ce and slim installed.
Setting Seems to be a common problem looking at #637 and caused by #641 |
@sammcj Here's the Vagrant-based repro with Fedora 39 and Docker 26.1.1. You should be good with the release version in the repro config. The release version you shared in this issue is out of date. |
@kcq Sorry for the delay in responding. As noted before, this is happening only on a self-hosted Bitbucket pipeline runner (linux/amd64). When I run locally, I have no issue. To make Slim work in the pipeline environment, it has to run via the Host Docker
|
@jimcottrell Running with dind in Bitbucket runners makes it more complicated because each CI/CD vendor does the dind setup in slightly different ways, which requires different ways to connect to the (correct) Docker runtime. Some environments don't expose the Docker unix socket. Other environments need certs to connect to the Docker runtime. Some have more advanced network configurations that prevents direct container communication, so the To troubleshoot your setup we need two things to get started:
|
Here's a simplified version of our image:
name: atlassian/default-image:4
definitions:
services:
privileged-docker:
type: docker
image:
name: docker:dind
pipelines:
custom:
test:
- step:
runs-on:
- linux
- self.hosted
name: Build Optimized Image
services:
- privileged-docker
script:
- curl https://downloads.dockerslim.com/releases/1.40.11/dist_linux.tar.gz -o slim.tar.gz
- tar xvf slim.tar.gz
#- export DOCKER_API_VERSION='1.25' # Temporary, see https://github.com/slimtoolkit/slim/issues/646
- ./dist_linux/slim build --continue-after=enter alpine I tried it with |
Are there any updates here? I am having the same problem with a gitlab pipeline and dind |
The latest release, 1.41.5, shouldn't have the docker API problem. To connect to the Docker daemon it might be necessary to extract the daemon IP address from the /etc/hosts file if the environment doesn't configure DOCKER_HOST on its own properly. Here's an example for Gitlab (need to double check if it still works): Might need to use the I'll repro it with Gitlab first to confirm that the setup is still ok. Then I'll try to repro with a Bitbucket setup. |
Okay, than the installation routine should be adapted:
|
should be this install script |
Hello @kcq ! |
What image did you try to slim or was it a different command? Do you have a repro? |
It is a custom internal image, already created. Found just now that i'm forced to use the 'export' =>
or While if i do:
It says again client API 1.12 is too old. |
I've got a CI/CD pipeline that's run occasionally when we rebuild a image and create an optimized version with Slim. Without anything having changed that I'm aware of (same Slim version, same pipeline runner), this process has started failing with:
I thought this might be related to #637, but it seems to be a separate issue, and the same thing happens whether or not I try setting
--crt-api-version
. Having updated everything to the latest versions, the problem continues. The issue seems to be specific to this environment, as a local build works.Steps to Reproduce the Problem
(trivial reproduction; of course not our actual image)
Specifications
slim version
:The text was updated successfully, but these errors were encountered: