Re: [keycloak-dev] development image?

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&gt; 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&gt; > 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&gt; > > 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&gt; > >> 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&gt; > >>> 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&gt; > >>> > 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&gt; > >>> >> 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&gt; > >>> >> 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&gt; > >>> >> >> 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&gt; > >>> >> >>> 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&gt; > >>> >> >>> 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