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....
>> > 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/unified...
>> >> >>>
>> >> >>> 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
>
>