Official Docker images


(keeganwitt) #1

I’d like to create official Docker images like Maven has. I’ve started work here. I can help maintain it, but would like to get it published under the gradle space. Should I transfer it to the gradle org in GitHub?


(Benjamin Muschko) #2

Would you mind describing the purpose of creating these Docker images? Is the goal to provide a Docker image that provisions a Gradle installation? If that’s the case I’d argue that a Gradle project should use the Wrapper anyway so there’s no real point in pre-installing it.


(keeganwitt) #3

I don’t personally have this need, and there aren’t any use cases I can think of where the Docker option is a must-have vs the wrapper. However, there there are some cases I can think of where it might be more convenient.

Dev/CI Environments built with Docker

  • If you base the image on a Java image instead of Gradle image, and opted for the wrapper, you could end up downloading Gradle every build if, for example, it’s executing on an ephemeral slave.
  • It’s preferable to layer in the different environment dependencies rather than have one giant Dockerfile. This could be one less thing to build to support such a use case, potentially.
  • A way to have a shared place to put things in ~/gradle.properties that you don’t want checked into the project for whatever reason.
  • If you wanted to build a tool similar to Netflix’s NEWT, which provides an abstraction over many different build tools (Gradle, NPM, etc). Docker would be a good way to accomplish that (and is what they used in this case).

Experimental environment
It’s an easy to spin-up destructible environment that you can use to experiment building software that doesn’t have the wrapper configured on a system without Gradle.

The dev/CI environment is I think the main use case. The main thing is that having a Docker image provides a base for creating other environments. I agree that if you need just a raw environment and don’t plan on extending it, Docker doesn’t offer a lot vs the wrapper.


(Benjamin Muschko) #4

If you base the image on a Java image instead of Gradle image, and opted for the wrapper, you could end up downloading Gradle every build if, for example, it’s executing on an ephemeral slave.

I can see ephemeral agents/slaves as a valid use case in order to speed up the build execution time on CI.

A way to have a shared place to put things in ~/gradle.properties that you don’t want checked into the project for whatever reason.

That’s something we’d like to address in one way or another with the concept of a so-called build platform.

I’d like to create official Docker images like Maven has7. I’ve started work here6.

Are you planning to maintain the Docker images for Gradle in the long run? I think it would be important if somebody would take long-term ownership to provide optimal and continued support for the community.

I can help maintain it, but would like to get it published under the gradle space.

To be honest I am not quite sure who owns this registry. I’d have to ask internally.


(Benjamin Muschko) #5

I asked internally and we believe that the gradle was not created by us. Is there any way you could contact the owner?


(keeganwitt) #6

Bummer. Groovy has the same problem. I’m unaware of any procedure for requesting the space be re-allocated (the only way I could find to contact the owner was through a comment on a repo – which I tried to use in the case of Groovy, but since the gradle user has no repos that’s impossible). So I opened an issue. Hopefully the Docker folks can help us get it sorted out.

I agree ~/.gradle.properties is clunky and probably not a primary use case. I was just trying to anticipate how the image might be used (and as I’m sure you’ve seen as a tooling dev, use cases come up all the time that take you by surprise).

As for support, by “I can help maintain it”, I was offering to support it for the indefinite future. It’d be nice if down the road someone else came along to help. But if not, it should be pretty minimal maintenance.

EDIT: Got a reply on the Docker issue that’s helpful. Here’s the account support form: http://success.docker.com/Account_Support. And here’s their ownership policy: http://success.docker.com/Cloud/Solve/How_can_I_claim_ownership_of_an_existing_Docker_ID%3F?origin=autocompletesearch1. Since I’m sure Gradle has a trademark, you should be able to request rights to the existing account. Would you like to contact them since you’re officially with Gradle?

EDIT: As I’m thinking some more about this, maybe publishing as an official image rather than under the gradle username. You may want to claim the gradle id for it’s own sake, but doesn’t matter if it’s published as an official image.


(Benjamin Muschko) #8

Sounds great. I’d love to hear how well-received or used these images become over time.

At the moment we do not really have the bandwidth to look into that. Thanks for letting us know. We’ll try to prioritize an evaluation in the near future.


(keeganwitt) #9

Would you like me to transfer my repo under the gradle Github org? Or should I just point the official library at my Github username?


(Benjamin Muschko) #10

For now you can go with your own username. I am sure the ownership could be transferred at some point of time if needed.