installing minikube and injecting docker-env to other gradle tasks

[Asher Saban]

To run integration tests using this plugin, there's some additional gradle code that needs to be written -

1. docker env needs to be injected as environment variables before gradle docker tasks run ( we use our gradle-docker plugin.
2. when running integration tests on CI such as CircleCi, downloading and installing minikube and kubectl is required.

i'd like to contribute these to make the plugin more integration-tests friendly. i suggest the following -

1. injecting docker env as env variables to all Exec tasks that will run after the injecting task (this way, users will make their docker tasks depend on that task).
2. downloading and installing minikube, plus supporting cached binaries (downloading the binaries, chmoding, mving to /usr/loca/bin. would require sudo. should be enough for most CI systems).

[Asher Saban]

@loosebazooka @coollog

[Appu]

You can already inject the environment as described at the end of the readme: https://github.com/GoogleContainerTools/minikube-build-tools-for-java/tree/master/minikube-gradle-plugin

I suppose there is scope to expand that out to inject it into any Exec task -- but that seems specific, so I don't know.

Currently I think you can do something like this:

dockerEnv = minikube.getDockerEnv()
tasks.withType(Exec) { exec ->
    exec.environment dockerEnv
}

Is there a reason that this wont be enough?

I don't like the idea of anyone running the whole build as root -- but downloading and installing minikube could be helpful. @sageprice might have some insight into the cost of doing this.

[Chanseok Oh]

I don't like the idea of anyone running the whole build as root

Yeah, whatever files the build creates, like any local build output and Gradle cache, they will be owned by root and most likely cause unwanted trouble.

[Asher Saban]

@loosebazooka few comments -

1. you don't want to fetch the docker env in configuration phase (builds will fail if minikube is down and the user just compiled the project for example. or, if minikube is up, builds will do unnecessary work).
   this is more appropriate -

task injectDockerEnv() {
    doFirst {
        project(':proj').tasks.withType(Exec) { exec ->
            dockerEnv = minikube.getDockerEnv()
            exec.environment dockerEnv
        }
    }
}
tasks.getByPath(':proj:docker').dependsOn(':proj-integration-tests:injectDockerEnv')

if you have more than one project that builds a docker image, you'll need to add more code.
i'm suggesting to encapsulate this logic in the minikube plugin and then user code will be just -

tasks.getByPath(':proj:docker').dependsOn(':proj-integration-tests:injectDockerEnv')

2. builds will not run as sudo. mv'ing the minikube binary to /usr/local/bin would requires sudo. most CIs will run minikube with `vm-driver=none' which requires sudo anyway - #3760

i've already implemented this logic and we're using this in our integration tests. will you accept contribution?

edit -
vm-driver=none requires not only sudo to deploy but also has to be started with sudo and after that requires to chmod ~/.kube and ~/.minikube such that $USER would be able to run minikube.

[Appu]

Sorry we're slow on this.

Yeah I guess I see what you're saying. I don't really see a problem in creating this task. So yes, a pull request is welcome, but please limit it to the task logic.

As for the installer, can you elaborate how it would work (like will it look for updates? or will it just install latest whenever the user runs it?) Where we expect the executable to go -- should that be configured -- we can't expect everyone's CI to be the same, can users even write to /usr/local/bin?
I would think this problem could be more easily solved by invoking the download task from https://github.com/michel-kraemer/gradle-download-task (or something), but again it sounds like you want everything directly in the minikube plugin?