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(a)redhat.com> wrote:
We're going to be working together in master.
On Thu, Jan 18, 2018 at 11:56 AM, Stian Thorgersen <sthorger(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>> >>> >> >>> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>> >> >>> >
>> >>> >> >>>
_______________________________________________
>> >>> >> >>> keycloak-dev mailing list
>> >>> >> >>> keycloak-dev(a)lists.jboss.org
>> >>> >> >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Bill Burke
>> >>> >> Red Hat
>> >>> >>
>> >>> >
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev(a)lists.jboss.org
>> >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
--
Bill Burke
Red Hat