Have minikubeDockerBuild be more helpful by providing default parameters.

[coollog]

Currently, minikubeDockerBuild (#7) takes a context and flags.

We want it to be more helpful by providing some default docker build parameters as part of the task configuration:

~~1. dockerfile- configures the task with -f <value>

• Default: src/main/docker/Dockerfile
• Reason: since we don't really expect to find Dockerfile in the root of a Gradle project.~~
  1. Reason: save the user the hassle of having to define build context/Dockerfile location themselves.
  2. IN PROGRESS (#16) A separate task prepareMinikubeDockerBuild that prepares the context to use for minikubeDockerBuild. Takes parameters:
     • context: the task syncs this to build/docker
       • Default: build/libs
     • dockerfile: the task syncs this to build/docker/Dockerfile
       • Default: src/main/docker/Dockerfile
  3. IN PROGRESS (#17) Have minikubeDockerBuild use build/docker for its context and depends on the successful execution of the prepareMinikubeDockerBuild task.
  4. IN PROGRESS (#15) tag - configures the task with -t <value>
• Default: ${project.group}/${project.name}:${project.version}
• Reason: provides the user with a convenient tag to refer to the image with

Please comment with more ideas about what configuration to provide. The above list will be updated with more ideas.

[r2d4]

It might be useful to auto-populate the "tag" parameter with something like $ORGANIZATION/$PROJECT_NAME:$VERISON

[coollog]

Okay, how about having a field like:

imageTagConfig - nested with properties: organizationName, projectName, version (Configures the task with -t <organizationName>/<projectName>:<version>)

@loosebazooka

[coollog]

Also, @loosebazooka , it seems that the Dockerfile must be in the build context, so a default context of build/libs with a default Dockerfile of src/main/docker/Dockerfile would not work.

[loosebazooka]

I think you can just have those be base properties on the task, with defaults pulled from the gradle config, like project.version and project.name?

[coollog]

What if the user wanted to not use the auto-populated task? Should we include another property called useAutoGeneratedTag that defaults to true?

[loosebazooka]

I'm not sure what the override order is, but if the user uses -t in "flags", that should override whatever we've configured from imageTagConfig (or whatever that config ends up being)

[coollog]

The user can actually specify multiple -t tags, and it will tag the same image with each tag that is provided, so there is no override.

[coollog]

Closed pending design for new way of building with the Minikube Docker environment.