[keycloak-dev] development image?

Mon Jan 22 02:52:44 EST 2018

Short/medium term it makes sense to have something simple for them that
lets you co-operate.

If that's the development image you propose I don't have a problem with
that (for Maven caching issue you could probably just use a volume or
simple mount ~/.m2/repository from the host into the container). Would be
nice to also have some options to specify the repository and branch so it
can be used to build a personal fork and/or a different branch (couple
environment variables should allow that).

In the longer term the plan is to create pipelines that can build our ZIPs
and OpenShift images on every PR. Once that's ready we should tie it
together with tests for this integration so we can run the tests with the
xPaaS RH-SSO images as well as the Keycloak images from Docker hub.

On 18 January 2018 at 18:25, Bill Burke <bburke at redhat.com> wrote:

> We're going to be working together in master.
>
> On Thu, Jan 18, 2018 at 11:56 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Perhaps they should be testing with RH-SSO images then?
> >
> > If so the plan is to build OpenShift images for every PR. The pipeline
> that
> > does that could also trigger the AOS tests and the temporary OpenShift
> > images would be available for the test.
> >
> > We could also do the same for Keycloak tests and it wouldn't be to hard
> to
> > create a Jenkins job that builds Docker images for every PR. We'd just
> need
> > a Docker registry to host them in.
> >
> > On 18 Jan 2018 5:38 pm, "Bill Burke" <bburke at redhat.com> wrote:
> >>
> >> I'll ping AOS team for more info.  I think they want to be able to try
> >> things out immediately when a PR happens, like let's say I merge a PR
> >> that fixes or improves OSIN integration.  And/or, they want to trigger
> >> a CI job whenever a PR is merged on our side (and vice versa).
> >>
> >> On Thu, Jan 18, 2018 at 10:05 AM, Stian Thorgersen <sthorger at redhat.com
> >
> >> wrote:
> >> > .... adding to my previous reply
> >> >
> >> > Once we have Jenkins instance setup it should be fairly trivial to
> have
> >> > a
> >> > nightly build of the ZIPs published somewhere. When we have that we
> can
> >> > easily setup a build in Docker hub that would automatically build the
> >> > image
> >> > and make it available. So you'd run with something like:
> >> >
> >> >    docker run jboss/keycloak:nightly
> >> >
> >> > 'nightly' would always be the latest build. We could also add
> >> > 'nighly-<DATE>', but not sure if that's necessary.
> >> >
> >> > On 18 January 2018 at 16:02, Stian Thorgersen <sthorger at redhat.com>
> >> > wrote:
> >> >>
> >> >> Is the use-case folks that want to try out a feature available in
> >> >> master,
> >> >> but not in a Keycloak release yet?
> >> >>
> >> >> What about having daily builds instead? We could have both ZIPs and
> >> >> Docker
> >> >> images built daily.
> >> >>
> >> >> On 17 January 2018 at 20:18, Bruno Oliveira <bruno at abstractj.org>
> >> >> wrote:
> >> >>>
> >> >>> Oh, I forgot about a better option. Upload snapshots from Travis to
> >> >>> Maven
> >> >>> repository and build the docker image based on the latest build. In
> >> >>> this
> >> >>> way we don't need to build everything from scratch, because Travis
> >> >>> already
> >> >>> does it.
> >> >>>
> >> >>> On Wed, Jan 17, 2018 at 5:01 PM Bruno Oliveira <bruno at abstractj.org
> >
> >> >>> wrote:
> >> >>>
> >> >>> > I believe something like this is what you meant
> >> >>> >
> >> >>> >
> >> >>> > https://raw.githubusercontent.com/abstractj/dockerfiles/
> keycloak/keycloak/keycloak-latest/Dockerfile.
> >> >>> > Some considerations about this:
> >> >>> >
> >> >>> > 1. We can automate the build on Docker Hub, but it's gonna take
> like
> >> >>> > forever at each build. Because it's going to download the internet
> >> >>> > like
> >> >>> > Marko mentioned
> >> >>> > 2. Maybe we should consider a smarter way of caching .m2
> >> >>> > repositories.
> >> >>> > I
> >> >>> > just can think about a manual process for this.
> >> >>> > 3. In order to keep the image fresh, might be necessary to trigger
> >> >>> > the
> >> >>> > image build from Travis remotely. I'm not sure if we want this.
> >> >>> >
> >> >>> > Another alternative which I think may solve these 3 items above,
> is
> >> >>> > to
> >> >>> > provide weekly builds of this docker image.
> >> >>> >
> >> >>> > On Wed, Jan 17, 2018 at 3:29 PM Bill Burke <bburke at redhat.com>
> >> >>> > wrote:
> >> >>> >
> >> >>> >> .This image is for people that don't want to know anything about
> >> >>> >> maven
> >> >>> >> our our build system and want to use a distro built from master.
> >> >>> >>
> >> >>> >> For developers like us, we just write a 2 line Dockerfile and
> mount
> >> >>> >> local disk to the image.  This way you never have to rebuild the
> >> >>> >> image
> >> >>> >> as you're developing as everything is in local disk.  This is
> how I
> >> >>> >> approached things lately when I was fidling around the master +
> >> >>> >> kubernetes.
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> On Wed, Jan 17, 2018 at 11:00 AM, Marko Strukelj
> >> >>> >> <mstrukel at redhat.com>
> >> >>> >> wrote:
> >> >>> >> > Yeah, we could also checkout code in 'development' subdirectory
> >> >>> >> > and
> >> >>> >> provide
> >> >>> >> > an option to mount local dir as 'development'. We could also
> >> >>> >> > provide
> >> >>> >> option
> >> >>> >> > to skip checkout and to use existing code in the mounted
> >> >>> >> > ~/development/keycloak - that would use your local working
> >> >>> >> > version
> >> >>> >> > of
> >> >>> >> > keycloak - so you can have it open in your IDE and do a rebuild
> >> >>> >> iteration
> >> >>> >> > quickly ...
> >> >>> >> >
> >> >>> >> > On Wed, Jan 17, 2018 at 3:57 PM, Bruno Oliveira
> >> >>> >> > <bruno at abstractj.org>
> >> >>> >> wrote:
> >> >>> >> >>
> >> >>> >> >> Maybe we can just provide an option for people to mount
> >> >>> >> >> $HOME/.m2/repository ?
> >> >>> >> >>
> >> >>> >> >> On Wed, Jan 17, 2018 at 12:52 PM Marko Strukelj
> >> >>> >> >> <mstrukel at redhat.com>
> >> >>> >> >> wrote:
> >> >>> >> >>>
> >> >>> >> >>> The problematic part is 'mvn clean install' which will pull
> >> >>> >> >>> down
> >> >>> >> >>> the
> >> >>> >> >>> internet of dependencies as if you're building for the first
> >> >>> >> >>> time
> >> >>> >> >>> -
> >> >>> >> every
> >> >>> >> >>> time.
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >>> On Jan 16, 2018 00:56, "Bruno Oliveira" <bruno at abstractj.org
> >
> >> >>> >> >>> wrote:
> >> >>> >> >>>
> >> >>> >> >>> Hi Bill, I think it makes sense. But there are few things
> that
> >> >>> >> >>> people
> >> >>> >> >>> can't
> >> >>> >> >>> avoid, like install JDK for development.
> >> >>> >> >>>
> >> >>> >> >>> On AeroGear we had a -dev image like you described[1]
> >> >>> >> >>>
> >> >>> >> >>> [1] -
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >>
> >> >>> >>
> >> >>> >> https://github.com/jboss-dockerfiles/aerogear/blob/
> master/wildfly/unifiedpush-wildfly-dev/Dockerfile
> >> >>> >> >>>
> >> >>> >> >>> On Mon, Jan 15, 2018 at 9:21 PM Bill Burke <
> bburke at redhat.com>
> >> >>> >> >>> wrote:
> >> >>> >> >>>
> >> >>> >> >>> > Do we need a development image that builds from master.  A
> >> >>> >> Dockerfile
> >> >>> >> >>> > script that:
> >> >>> >> >>> >
> >> >>> >> >>> > - derives from jdk8
> >> >>> >> >>> > - installs git client
> >> >>> >> >>> > - install maven
> >> >>> >> >>> > - git clone https://github.com/keycloak/keycloak
> >> >>> >> >>> > - mvn clean install -Pdistro -DskipTests=true
> >> >>> >> >>> > - unzip distro into /opt/keycloak
> >> >>> >> >>> >
> >> >>> >> >>> > We have a couple of teams asking for something like this
> >> >>> >> >>> > within
> >> >>> >> >>> > Red
> >> >>> >> >>> > Hat as I'm guessing they don't want to deal with running
> >> >>> >> >>> > maven
> >> >>> >> >>> > themselves.  Does that sort of flow make sense?
> >> >>> >> >>> >
> >> >>> >> >>> > --
> >> >>> >> >>> > Bill Burke
> >> >>> >> >>> > Red Hat
> >> >>> >> >>> > _______________________________________________
> >> >>> >> >>> > keycloak-dev mailing list
> >> >>> >> >>> > keycloak-dev at lists.jboss.org
> >> >>> >> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>> >> >>> >
> >> >>> >> >>> _______________________________________________
> >> >>> >> >>> keycloak-dev mailing list
> >> >>> >> >>> keycloak-dev at lists.jboss.org
> >> >>> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>> >> >>>
> >> >>> >> >>>
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Bill Burke
> >> >>> >> Red Hat
> >> >>> >>
> >> >>> >
> >> >>> _______________________________________________
> >> >>> keycloak-dev mailing list
> >> >>> keycloak-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
>
>
>
> --
> Bill Burke
> Red Hat
>