goreleaser

goreleaser copied to clipboard

This commit will add a feature to build Docker image using Kaniko running on Docker.

The implementation adds a new kaniko api that implements imager interface.

As kaniko builds and pushes in the same command, the Push method is a no-op. A no-push option is available within Kaniko through a CLI flag --no-push. So Goreleaser's --skip_push is translated into Kaniko's --no-push.

...

#2322

@caarlos0 Could you take a look at this draft to see if it is in the right direction for #2322 please?

I have some questions:

1. Do we need to implement the manifester?
2. I tried to run docker_test.go, but the kaniko tests are failing because the registries use localhost which are not reachable from the kaniko executor image (see https://github.com/goreleaser/goreleaser/runs/6046907714?check_suite_focus=true#step:13:95). Do you have any idea how we can address this?

looking good overall! thank you!

have a concern about the push on build part, and at some point we need to add tests and run task fmt as well

looking good overall! thank you!

have a concern about the push on build part, and at some point we need to add tests and run task fmt as well

I have been having some challenges with the docker_test.go tests where it automatically loads all the imager implementations and run the tests on each of them:

1. The current test image tags using registry address on localhost do not work for Kaniko because Kaniko runs within the docker network. Changing the registry address to fit Kaniko by using a docker network such as alt_registry would then break the tests for the other imagers.
2. Kaniko assumes secure registry by default and will push to https address. This breaks on the test registry which doesn't have SSL. The workaround is to have Kaniko run with insecure option. The default imager loaded within init then needs to be overridden during test.

Given these as well as the skipPush behaviour, I wonder if it should be implemented as a dedicated Kaniko pipeline, instead of adapting Docker.

Given these as well as the skipPush behaviour, I wonder if it should be implemented as a dedicated Kaniko pipeline, instead of adapting Docker.

closed by mistake, but yes, probably worth having another pipe just for kaniko then...

closing for inactivity, feel free to ping if there's still interest in proceeding with this.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.