Docker support based on Jib

[danielpetisme]

A proposal for #18

It simply works (i used the openjdk:8-jdk-alpine as default image).
My concerns with jib:

• According to their FAQ the local build requires a weird docker pull to make the image available. We'll see the result on a CI environment. Plus, it requires to run the jibDockerBuild rather than the simple jib task.

• The docker build is 100% programatically, we can't override with a classic Dockerfile (discussed here. I understand the discussion but it's not ops-friendly

I wait for your feedback before starting the documentation.

[chanseokoh]

According to their FAQ the local build requires a weird docker pull to make the image available.

I think you misunderstood this. What the above means is, if you want to pull down to your local Docker daemon the Image built and pushed to a remote registry, you would do mvn jib:build followed by docker pull.

Also, instead of the round-trip, you can directly push to your local Docker daemon by mvn jib:dockerBuild, skipping pushing the image to some remote registry.

[jponge]

I finally took time to test 😉

I ran ./gradlew test and after 10 minutes I had to kill it. I suppose that the added test just doesn't complete. Am I missing anything @danielpetisme?

[danielpetisme]

My bad.
The hanging comes from the process output reading and a "daemon-like" process.

When you try to destroy the process, if the the reading stream is still open will prevent the process stop.
It's a mess to handle properly (in another project, I start a thread capturing the process's output and handling the original process stop/kill).

I'll fix that.

[danielpetisme]

@jponge I take the opportunity to add a travis file (to fix the "it works on my machine" effect 😄 )

[jponge]

Is it really needed?

[jponge]

Oh nevermind, you do need it.

Going into src/test/gradle/vertx-web-sample running gradle tasks fails because of that.

[danielpetisme]

The com.google.cloud.tools:com.google.cloud.tools.jib.gradle.plugin seems only present in mavenCentral and not jcenter.

The Gradle plugin portal is a mirror to jcenter and Maven Central thats why it works wit the this snippet.

The options I can see:

• Ask Google to publish the jib-gradle-plugin to jcenter (the jib maven plugin is already published). Do you know anyone able to do that?
• Wait for the official publication, that will freeze this PR for a while
• Update the project build files to include mavenCentral() (cleaner than pointing the plugin portal)

repositories {
  jcenter()
  mavenCentral()
  mavenLocal()
}

We should also update the documentation to explicit the need of Maven Central as a replacement/complement of JCenter.

WDYT?

[jponge]

The plugin may also manipulate the repositories declaration, and complete if needed :-) BTW JCenter always fetches from Maven Central when dependencies are missing.

…

On Tue, Sep 11, 2018 at 11:00 PM Daniel PETISME ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In build.gradle <#19 (comment)> : > @@ -23,6 +23,11 @@ plugins { repositories { jcenter() + repositories { The com.google.cloud.tools:com.google.cloud.tools.jib.gradle.plugin seems only present in mavenCentral <https://mvnrepository.com/artifact/com.google.cloud.tools.jib/com.google.cloud.tools.jib.gradle.plugin?repo=gradle-plugins> and not jcenter. The Gradle plugin portal is a mirror to jcenter and Maven Central thats why it works withe this snippet. The options I can see: - Ask Google to publish the jib-gradle-plugin to jcenter (the jib maven plugin <https://bintray.com/bintray/jcenter/com.google.cloud.tools%3Ajib-maven-plugin> is already published). Do you know anyone able to do that? - Wait for the official publication, that will freeze this PR for a while - Update the project build files to include mavenCentral() (cleaner than pointing the plugin portal) and documentation to explicit the need of Maven Central as a replacement/complement of JCenter. WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABlaUiHeMOTlq8lCNE-IeTcbvepHPbeks5uaCSCgaJpZM4Vqx-v> .

[danielpetisme]

For the jib-gradle dependency it seems jcenter is not fallbacking to L'avenir Central... 😢
Manipulating the repositories via the plugin looks more like a hack but I don't have a better plan (except completing the documentation).
I'll propose an update soon

[danielpetisme]

@jponge I tried to move on this one.
I was wrong regarding mavenCentral()
According to mvnrepository the jib-gradle-plugin only exists in Gradle Plugins repo.

I raised an issue to ask for the publication of the plugin as a dependency on the common repos:
GoogleContainerTools/jib#1004

The src/test/gradle/vertx-web-sample has a stange behavior, it substitute the vertx-gradle-plugin dependency by the vertx-gradle-plugin project and tries to resolve its dependencies with the vertx-web-sample repositories definition (in that case jcenter() only).
I try to manipulate the project repositories programatically via vertx-gradle-plugin. But based on the structure defined above, Gradle first try to resolve the artifacts coming :classpath (ie. vertx-gradle-plugin) before applying the plugin and since it resolves with the vertx-web-sample repos definition (ie. jcenter) it fails to find jib dependency. Looks like a 🐔 || 🥚 issue.

I'm not sure this issue reflects a real-world situation. WDYT? For the plugin consistency, the issue can be fixed by adding gradlePluginPortal() in the repos definition of vertx-web-sample.

[jponge]

Seems like we need to wait for GoogleContainerTools/jib#1004 right?

[danielpetisme]

Not sure, I understand that the core of jib will be published as a common lib aimed to be integrated in client code. The gralde plugin will use this core lib but not sure the plugin itself will be published on classic repos.

Don't had time to dig it deeper and to be frank I don't know how to fix that in an elegant manner.

Maybe you can tag this PR as "on-hold".

[javenwang]

Suggested change

	imageConfiguration.image = "openjdk:8-jdk-alpine"
	imageConfiguration.image = "openjdk:8-jre-alpine"

I think 'jre' is what we need