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> 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> 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>
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>
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