Is there a reason you need Kaniko to do anything other than build docker images? It should not be your CI tool, IMO.

We used Jenkins and used side-car containers. We had any docker-related building use the kaniko container, and our Jenkins Docker Image Build agent handle anything else. These shared a PVC so that files could be accessed by both.

It worked well. Is something like this possible with Gitlab-CI?

Well, there are sidecars, and there are services, but it's all very combersome and not reliable enough to my opinion.

We use Kaniko as a base image for a job, it runs the CLI, it produces the image and pushes it to a repo - that's all great.

But I need the same job to report the image somewhere using curl. Really? we need a side-car for that?
I don't want another job just for that!!
Besides - this curl report should be more or less atomic, esp. when we update moving tags like latest.
Another job is kinda klunky and fragile, and I have to use artifacts between them - really?

I'll give you more details: the job calculates the tag, and gathers build info into a json file. So I have to gather it as an artifact that is uploaded to S3, so the job with the curl can download it, just so it can post it to consul? all that because kaniko comes with plain busybox and nothing more?

We solved it by creating an image that extends that kaniko with busybox and adds to that curl and jq, and it works for us very well - so great! So I thought not to keep that to myself and created this #2317

I'll give you two more cents here.

Because of this limitation, gitlab moved to recommending launching kaniko from docker-in-docker, so you can have your base image with your tools and kaniko is lunched from docker-in-docker....? really? doesn't that defeat the purpose?

I did it differently: I prepared with python scripts a kaniko context where everything is resolved, it contains a Dockerfile contains maybe stupid credentials I need to mount in, contains a run.sh script which basically just calls the executor with all flags etc. In that way I can mount this folder into the Kaniko:debug Container in Jenkins and execute the script. So every postprocessing before calling the executor is done beforehand. This has the advantage not to do to much (impossible becuase the tools are not in the kaniko image) unrelated things in the kaniko image itself. So yes we do that in side-car containers to produce this context directory.

@gabyx so you use docker-x or docker-in-docker to launch a kaniko container?

@osher: We use kubernetes over Jenkins CI to launch kaniko to build images. To launch a kaniko container you can use docker or podman, kaniko builds a container in OCI format, thats all it does. I did not understand the question probably?