Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Java 11 images (latest and debug) / add more tags #285

Merged
merged 9 commits into from
Jan 29, 2019
Merged

Conversation

chanseokoh
Copy link
Member

@chanseokoh chanseokoh commented Jan 24, 2019

About #236.

This is on top of #283, so #283 should be reviewed first.

Debian stretch recently back-ported openjdk-11. The Java 11 images get the openjdk-11-jre-headless (in parity with the Java 8 images) from the stretch-backports snapshot archive.

gcr.io/distroless/java:latest and gcr.io/distroless/java:debug still point to Java 8.

Two new images:
gcr.io/distroless/java:11
gcr.io/distroless/java:11-debug

Additional tags:
gcr.io/distroless/java:8
gcr.io/distroless/java:8-debug
gcr.io/distroless/java:11
gcr.io/distroless/java:11-debug
gcr.io/distroless/java/jetty:java8
gcr.io/distroless/java/jetty:java8-debug

@chanseokoh chanseokoh changed the title Add Java 11 images (latest and debug) Add Java 11 images (latest and debug) / add more tags Jan 24, 2019
@loosebazooka
Copy link
Member

So this generally matches the format of other java images: java:<version>-<more_descriptors>, but should we also include the detailed version numbers? for example java:8u181-xxx or java:11.0.1-xxx as a secondary tag? I'm not really sure at that point that the different vendors will even share version numbers :, so we might even have to include vendor?

@chanseokoh
Copy link
Member Author

Yeah, we do plan to add more detailed tags along the way. It's just that I don't do everything in this PR.

I think we can switch vendors for existing tags. Of course, we can add tags with vendors too (later).

@briandealwis
Copy link
Member

Can we put the version and vendor information as image labels? Putting this information into the tags will get pretty unwieldy. And there's no choice being offered to consumers: we're not planning to publish multiple vendors, and we're not maintaining parallel streams (e.g., 11.0.1 with security updates now that 11.0.2 is released).

@briandealwis
Copy link
Member

@chanseokoh were you going to offer jetty with java11 too?

@chanseokoh
Copy link
Member Author

Can we put the version and vendor information as image labels?

We have a plan to do this: #276

@chanseokoh were you going to offer jetty with java11 too?

Eventually, this will happen. Could be soon, or maybe not. Hopefully soon?

@chanseokoh
Copy link
Member Author

chanseokoh commented Jan 25, 2019

Took out #283 (advancing the snapshot), so this PR is standalone and no longer depends on #283.

@loosebazooka
Copy link
Member

FYI: @saturnism, a more explicity tagging strategy.

) for mode in [
"",
":debug",
) for (rule_name, jre_deb, java_executable_path) in [
Copy link
Member

@loosebazooka loosebazooka Jan 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably just get some bazel person to look at this, is there a way to share the java_executable_path reference or would that make this section look super wonky?
@nlopezgi wdyt?

Copy link
Member Author

@chanseokoh chanseokoh Jan 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, if you look at them closely, the java_executable_path values are different between Java 8 and Java 11. (Java 8 has the "jre" directory.) I could add an if-else logic like "add jre only when Java 8", but wasn't sure if it would look better than this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel super strongly about this. I was concerned about each java path could potentially be shared for each java8, java11 option, but it seems like it's not worth the trouble right now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants