Good morning, Last week Pedro submitted a PR to the Node.js adapter, but the build is failing because it depends on the changes from Keycloak server master branch. Today we download the latest stable release from Keycloak to run the integration tests for this adapter. I would like to change it and follow the same approach from the Quickstarts, which means clone/build/run Keycloak server from master. In this way, we can always it test against the latest changes. Thoughts? -- abstractj _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Good morning, Last week Pedro submitted a PR to the Node.js adapter, but the build is failing because it depends on the changes from Keycloak server master branch. Today we download the latest stable release from Keycloak to run the integration tests for this adapter. I would like to change it and follow the same approach from the Quickstarts, which means clone/build/run Keycloak server from master. In this way, we can always it test against the latest changes. Thoughts? -- abstractj _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Is nightly enough? Consider keycloak repo breaks due to some change and the quickstarts cannot be built until this is fixed. In nightly, that would delay the development to the next day. My vote is to either build Keycloak from master like Bruno suggested or have a way documented to rebuild the "latest" image (regardless of "nightly" name) anytime on demand to enable dependent changes to be developed quickly. --Hynek On Tue, Aug 14, 2018 at 11:34 AM Vaclav Muzikar <vmuzikar(a)redhat.com&gt; wrote: > > +1 > > We've got a nightly CI job testing Node.js adapter against upstream but > running it in Travis (with each PR) would make more sense. > > On Mon, Aug 13, 2018 at 3:40 PM Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > > Good morning, > > > > Last week Pedro submitted a PR to the Node.js adapter, but the build is > > failing because it depends on the changes from Keycloak server master > > branch. > > > > Today we download the latest stable release from Keycloak to run the > > integration tests for this adapter. I would like to change it and follow > > the same approach from the Quickstarts, which means clone/build/run > > Keycloak server from master. In this way, we can always it test against > > the latest changes. > > > > Thoughts? > > > > > > -- > > > > abstractj > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > Václav Muzikář > Quality Engineer > Keycloak / Red Hat Single Sign-On > Red Hat Czech s.r.o. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

How about this: * Rebuild Docker image for every PR. We can probably do this with a webhook or somethin'.

* Write a script that can be shared to all projects that need a Keycloak server. It would check the latest Docker hub image and see if it matches master. If it doesn't it would build the image locally. Then it would start the Keycloak server. Could use the same script for Node.js, Generic Adapter, QuickStarts, etc..

On Tue, 14 Aug 2018 at 15:10, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > Let's do this, I will change it to always build Keycloak from master > and later we can think about docker images. I think Docker images > would be better, at the same time, I'm not sure how fix the scenario > where feature A on Node.js adapter, depends on Feature B merged on > Keycloak master and both have to be merged/tested in the same day. > > Unless we do something like Hynek suggested. > On Tue, Aug 14, 2018 at 9:33 AM Hynek Mlnarik <hmlnarik(a)redhat.com&gt; wrote: > > > > Is nightly enough? > > > > Consider keycloak repo breaks due to some change and the quickstarts cannot be built until this is fixed. In nightly, that would delay the development to the next day. > > > > My vote is to either build Keycloak from master like Bruno suggested or have a way documented to rebuild the "latest" image (regardless of "nightly" name) anytime on demand to enable dependent changes to be developed quickly. > > > > --Hynek > > > > On Tue, Aug 14, 2018 at 11:34 AM Vaclav Muzikar <vmuzikar(a)redhat.com&gt; wrote: > >> > >> +1 > >> > >> We've got a nightly CI job testing Node.js adapter against upstream but > >> running it in Travis (with each PR) would make more sense. > >> > >> On Mon, Aug 13, 2018 at 3:40 PM Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > >> > >> > Good morning, > >> > > >> > Last week Pedro submitted a PR to the Node.js adapter, but the build is > >> > failing because it depends on the changes from Keycloak server master > >> > branch. > >> > > >> > Today we download the latest stable release from Keycloak to run the > >> > integration tests for this adapter. I would like to change it and follow > >> > the same approach from the Quickstarts, which means clone/build/run > >> > Keycloak server from master. In this way, we can always it test against > >> > the latest changes. > >> > > >> > Thoughts? > >> > > >> > > >> > -- > >> > > >> > abstractj > >> > _______________________________________________ > >> > keycloak-dev mailing list > >> > keycloak-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> > >> > >> -- > >> Václav Muzikář > >> Quality Engineer > >> Keycloak / Red Hat Single Sign-On > >> Red Hat Czech s.r.o. > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > - abstractj > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Thu, 16 Aug 2018 at 15:13, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > On Thu, Aug 16, 2018 at 5:34 AM Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > > How about this: > > > > * Rebuild Docker image for every PR. We can probably do this with a webhook or somethin'. > > If we think about 3 repositories or more getting new PRs. This might > become a bit expensive, don't you think? I'd suggest another > alternative, but that would require a bot to trigger the docker build > on demand. This would be the flow proposed: I didn't quite clarify what I meant. I only meant rebuild Docker image when a PR is merged into Keycloak, resulting in whenever master (keycloak/keycloak repo) changes the Keycloak images will be rebuilt. I believe we can quite easily setup a webhook in GitHub to trigger this rebuild in Docker Hub. Without the bot having to do anything. Docker Hub can however sometimes be a bit slow (up to an hour to schedule and build), so would be worth to allow tests to build the image locally if it's not updated. They can do this by checking out the Dockerfiles and running with build args to build from Keycloak master. > > > 1. PR submitted and tested against the nightly build > 2. PR failed the author add a comment like @keycloak-bot > build-keycloak-server rerun > 3. The bot check if user has the rights for it, trigger the build of > the docker image and run the tests again > > This is just a suggestion which I understand, requires some time. But > this is the best which I can come up with. Or we can try what you > suggested and see how it goes. > > > * Write a script that can be shared to all projects that need a Keycloak server. It would check the latest Docker hub image and see if it matches master. If it doesn't it would build the image locally. Then it would start the Keycloak server. Could use the same script for Node.js, Generic Adapter, QuickStarts, etc.. > > +1 > > Once we reach an agreement on this, with whatever approach we decided. > We can file a Jira. > > > > > On Tue, 14 Aug 2018 at 15:10, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > >> > >> Let's do this, I will change it to always build Keycloak from master > >> and later we can think about docker images. I think Docker images > >> would be better, at the same time, I'm not sure how fix the scenario > >> where feature A on Node.js adapter, depends on Feature B merged on > >> Keycloak master and both have to be merged/tested in the same day. > >> > >> Unless we do something like Hynek suggested. > >> On Tue, Aug 14, 2018 at 9:33 AM Hynek Mlnarik <hmlnarik(a)redhat.com&gt; wrote: > >> > > >> > Is nightly enough? > >> > > >> > Consider keycloak repo breaks due to some change and the quickstarts cannot be built until this is fixed. In nightly, that would delay the development to the next day. > >> > > >> > My vote is to either build Keycloak from master like Bruno suggested or have a way documented to rebuild the "latest" image (regardless of "nightly" name) anytime on demand to enable dependent changes to be developed quickly. > >> > > >> > --Hynek > >> > > >> > On Tue, Aug 14, 2018 at 11:34 AM Vaclav Muzikar <vmuzikar(a)redhat.com&gt; wrote: > >> >> > >> >> +1 > >> >> > >> >> We've got a nightly CI job testing Node.js adapter against upstream but > >> >> running it in Travis (with each PR) would make more sense. > >> >> > >> >> On Mon, Aug 13, 2018 at 3:40 PM Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > >> >> > >> >> > Good morning, > >> >> > > >> >> > Last week Pedro submitted a PR to the Node.js adapter, but the build is > >> >> > failing because it depends on the changes from Keycloak server master > >> >> > branch. > >> >> > > >> >> > Today we download the latest stable release from Keycloak to run the > >> >> > integration tests for this adapter. I would like to change it and follow > >> >> > the same approach from the Quickstarts, which means clone/build/run > >> >> > Keycloak server from master. In this way, we can always it test against > >> >> > the latest changes. > >> >> > > >> >> > Thoughts? > >> >> > > >> >> > > >> >> > -- > >> >> > > >> >> > abstractj > >> >> > _______________________________________________ > >> >> > keycloak-dev mailing list > >> >> > keycloak-dev(a)lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> >> > > >> >> > >> >> > >> >> -- > >> >> Václav Muzikář > >> >> Quality Engineer > >> >> Keycloak / Red Hat Single Sign-On > >> >> Red Hat Czech s.r.o. > >> >> _______________________________________________ > >> >> keycloak-dev mailing list > >> >> keycloak-dev(a)lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> -- > >> - abstractj > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > - abstractj