search

jbake-org / jbake-docker-image

Docker Image for JBake
1 stars 4 forks source link

Define the docker image contract #1

Open OndraZizka opened 6 years ago

OndraZizka commented 6 years ago

Currently, I only see a branch with an image which runs jbake -b -s on a given content.

That's a good start. But we could create an image which would periodically check a git repository and on change, run jbake and push the result to some other repository. It could be a simple cron task, but also jenkins-based solution (I prefer the earlier).

That way, one could just set up a JBake service in kubernetes and forget it until an upgrade is needed.

Is there a demand for such image?

ancho commented 6 years ago

Oh. I almost forgot about that, as I'm not really using jbake with docker at the moment.

But I started an experiment with jbake source as a git submodule to build the docker image from it. Have a look at https://github.com/ancho/jbake-docker-image/tree/feature/build-from-source

There is also a problem at the moment with network binding as jbake serve binds to localhost. You need to use --network host as far as I remember.

ancho commented 6 years ago

Oh I got you wrong. I think the purpose of this image was it to be used in a ci build pipeline. So is there a demand for your proposal? I don't know. But why not just build something like that and see how it works out? This image could be the base for it.

OndraZizka commented 6 years ago

I see. Well, I can see at least 2 docker image types with JBake:

  1. Jenkins JBake pipeline - would watch a content source (e.g. git repo), would feed the result to destionation (e.g. another git repo).
  2. Just JBake, so that the user could simply run docker run jbake to build the current directory's web.

So this issue is basically asking - which of these does this repo pursue?

Regarding dockerization implementation - I strongly recommend having a look at docker-maven-plugin which makes building and testing the image a piece of cake. It may seem a little bit strange at first sight, but it's very logical, reduces boilerplate, creates optimized Dockerfile, makes releasing of the image easier (integrates with maven's paradigms), and working with the result is a pleasure.

jonbullock commented 6 years ago

The initial reason this was created was to enable jbake.org to be automatically updated using GitLab Pages and their CI system. However I don't use Docker much at all, so my knowledge is limited.

Couldn't option 2 be used in a CI pipeline too? Should option 2 be the first goal to aim for? Then build on that?

ancho commented 5 years ago

We are using the second version for the build at gitlab already.

Anyways...I prefer the second version over the first one for now.

@manikmagar Do you mind to release a 2.6.2 version of your javastreets image until we decide where we go from here.

The docker image build process should be part of the release, that way the release note on the homepage could be baked directly with a fresh version. That would be a nice goal.

manikmagar commented 5 years ago

I have pushed a newer version of the javastreets/jbake image with JBake 2.6.2.

In addition to that, I also wanted to update https://github.com/jbake-org/jbake.org/blob/master/.gitlab-ci.yml to use javastreets/jbake:base-latest as base image, instead of any specific version. That way, next time it should always use the latest version. But, while testing in local, I found that jbake.org is failing to bake with 2.6.2. See jbake-org/jbake.org#106 for more details.

@ancho Yes, I think we should add this to build/release pipeline.