Proposal: How to handle Jib build directly to registry.

[coollog]

Currently, Jib can build to the Docker daemon and share the same logic as the rest of the local builders (docker and bazel):

local.go#buildArtifact performs a series of steps for a build:

1. b.runBuildForArtifact builds to the Docker daemon and gets the initial tag
2. docker.Digest gets the digest for the initial tag from the Docker daemon
3. tagger.GenerateFullyQualifiedImageName generates the intended tag
4. b.api.ImageTag retags the initial tag to the intended tag
5. if push=true, docker.RunPush pushes the intended tag

However, to leverage the full benefits of Jib, we would need to add the ability to call jib:build to build directly to the registry. The implementation logic would be very similar to how the kaniko builder works:

1. Generate initial tag as random ID.
2. Run jib:build to initial tag.
3. docker.RemoteDigest to get the digest
4. tagger.GenerateFullyQualifiedImageName to get the intended tag
5. docker.AddTag to retag with intended tag

The original plan was the perform this logic when local.push=true, but we're proposing a new builder type jib (only supports JibMavenArtifact and JibGradleArtifact).

Therefore, the following would be what users could do with the Jib artifacts:

• local and push=false - jib:dockerBuild builds to Docker daemon
• local and push=true - jib:dockerBuild builds to Docker daemon and then the image is pushed
• jib - jib:build builds directly to the registry

The caveat, though, is that the jib builder would not support other artifact types. The alternative is to just keep the original approach, where users could do:

• local and push=false - jib:dockerBuild builds to Docker daemon
• local and push=true - jib:build builds directly to the registry

@GoogleContainerTools/java-tools @GoogleContainerTools/container-tools

[chanseokoh]

It makes me wonder what exactly this "Jib artifact" is? Is it tangible? Does it have a unique property that distinguish it form other types of artifacts?

[coollog]

The JibMavenArtifact and JibGradleArtifact defines what type of project it is (Maven or Gradle) and the module/subproject name, whereas the jib builder type defines to build using jib:build (vs jib:dockerBuild for the local builder type).

[chanseokoh]

The JibMavenArtifact and JibGradleArtifact defines what type of project it is (Maven or Gradle) and the module/subproject name

JibMavenProject or JibMavenProjectStructure may be a more apt name then. Can we call it that way?
Or, is this an internal framework thing in that we have no choice but to adhere to the word "artifact"? An artifact sounds like it is a concrete output that you can carry around, so I think it can be a bit confusing.

[coollog]

It is named like the other config.Artifact types DockerArtifact and BazelArtifact. The "artifact" portion refers to the fact that the project will be used by Skaffold to build an output artifact.

[balopat]

There is no clear agreement yet where we will be heading with the builders/artifacts - I believe it's a confusing situation. See: #953 and #955.

I would not put this on the critical path for Jib yet. I think we should go with the jib builder as a local builder for now even if it's not the most optimal flow for jib yet and when we reshuffle the builder/artifact structure, we can rethink how a more optimal jib flow fits in.

The artifact name is misleading I agree - it refers more to an "descriptor format" like Dockerfile for docker, or bazel files for bazel or pom.xml and build.gradle for jibMaven and jibGradle...

[balopat]

@dgageot
@dlorenc
any thoughts?

[dgageot]

I'm +1000 on just keeping the original approach based on push=true|false

In a project with multiple artifacts, we want a builder to be able to build all the artifacts. It's already not always the case. Let's not make it worth.

I can see myself working on a backend in Java built with Jib and a front end in Node built with Docker

[coollog]

@dgageot Do you mean keeping the original approach as in the current approach (as implemented) of:

• local and push=false - jib:dockerBuild builds to Docker daemon
• local and push=true - jib:dockerBuild builds to Docker daemon and Skaffold pushes to registry

Or the original "proposed" approach of:

• local and push=false - jib:dockerBuild builds to Docker daemon
• local and push=true - jib:build builds directly to the registry

[dgageot]

The latter seems good to me

[coollog]

Okay, for that approach, then, we would deviate from the normal local builder logic and perform the steps like the kaniko builder:

1. Generate initial tag as random ID.
2. Run jib:build to initial tag.
3. docker.RemoteDigest to get the digest
4. tagger.GenerateFullyQualifiedImageName to get the intended tag
5. docker.AddTag to retag with intended tag

[dgageot]

I think it makes sense