lightblue-platform/lightblue-dockerfiles

Make container for the snapshot version of lightblue

Closed this issue · 12 comments

Make the necessary changes to make it get the snapshot version (which would be in a different repository like https://oss.sonatype.org/content/repositories/snapshots/com/redhat/lightblue/lightblue-core-api/1.3.0-SNAPSHOT/ ). This issue was first thought on #7 (comment)

From what I see, there is no such thing as parametrized docker builds. How about this: publish lightblue image on docker hub and tag it appropriately, e.g.: lightblue-platform/docker-lightblue:1.2.0, lightblue-platform/docker-lightblue:latest (which would be the snapshot). Then simply define the lightblue version you want in docker-compose.yaml before you run docker-compose up. Do you have better ideas?

I thought the same thingl ike you, I just think that would need this project to be restructured to handle the complexity of dealing with different versions of lightblue (and maybe even from other dependencies as well). I would just list below some links related from the docker official java image which we can inpire us:

https://registry.hub.docker.com/_/java/
https://github.com/docker-library/official-images/blob/master/library/java
https://github.com/docker-library/java

what do you think?

I was thinking to use branches. Once lightblue 1.3.0 is released, we create 1.3.0 branch with Dockerfile updated accordingly. Master branch would then point at 1.4.0-SNAPSHOT (latest). Such setup would mirror version control of lightblue code.

The java image has multiple Dockerfiles in the same branch. If that is what docker people recommend (it's an official image after all), then I guess we should follow it instead of making branches.

What is the process for building images for docker registry? If it's built by a remote system we're stuck. If it's a local build you push out manually we have other options. One thing I have done for some images of my own is have a script generate the Dockerfile from a base file plus some env vars. For example:

https://github.com/jewzaam/docker-X11/blob/master/build.sh

Naveen

----- Original Message -----

I was thinking to use branches. Once lightblue 1.3.0 is released, we create
1.3.0 branch with Dockerfile updated accordingly. Master branch would then
point at 1.4.0-SNAPSHOT (latest). Such setup would mirror version control of
lightblue code.

The java image has multiple Dockerfiles in the same branch. If that is what
docker people recommend (it's an official image after all), then I guess we
should follow it instead of making branches.


Reply to this email directly or view it on GitHub:
#8 (comment)

It is possible to push a locally built image to the public registry. Remote build (on docker hub) can be configured to use custom paths to Dockerfile or specified branch, but I don't think it can run a script to generate the Dockerfile. I think parametrized docker builds are discouraged to ensure consistency of results.

I agree with @paterczm about pushing to the public registry (by the way Arun (from Red Hat) made a nice post about it on http://blog.arungupta.me/pushing-docker-images-registry-techtip58/ ).

About the branch idea you suggest first, I thought the same thing (I thought that would be a good approach at the very beginning) but after I found the dockers official repositories and wonder the differences between these approaches (in summary I think I understood their reasons and I would suggest to we do the same) I found there are few differences. One that caught my attention and concern is to keep the git version concept, roughly speaking, the master branch is the latest stable version of the repository and there are feature branches for new things and the tags for old releases. So, using the java repository as example, I think they want to make clear that all the java versions supported are in the master so they are all updated and you can easily see that all related versions is there (if we make a caparison with branch idea it would be like hidden as someone could not think like we did and could suppose that we hide the other branch or etc). On the other hand, having directory folders for each different version on the branch sounds like we are not doing the right thing with version and git.

Do you guys agree with me about theses views and we could use the same approach that docker did on their repositories??

I agree we should follow the convention established by docker, even if that's the only reason to do so. I don't like the redundancy of configuration files it introduces, but we can have them generated from templates, as @jewzaam suggested. For docker hub builds the outputs of the script would need to be commited, so it would not be on the fly generation, but I don't see a problem with that.

@jewzaam , @paterczm mentioned that he need to be a lightblue collaborator to be able to setup docker hub. Can you give the credentials to his user?

Just to mention in this thread, now we have an account in docker hub registry,thanks you @paterczm =D We can mention that in our documentation (http://www.lightblue.io/)

https://registry.hub.docker.com/repos/lightblue/

Put in an issue for it or a PR.

----- Original Message -----

Just to mention in this thread, now we have an account in docker hub
registry,thanks you @paterczm =D We can mention that in our documentation
(http://www.lightblue.io/)

https://registry.hub.docker.com/repos/lightblue/


Reply to this email directly or view it on GitHub:
#8 (comment)

Created the issues. I think this issue is solved. Anyone think that it still missing anything to be done right now related to this issue?

We already have lightblue-latest and application-latest, which are using snapshots.