Actually central CI should only test with the latest Keycloak master, it
doesn't need to test Node.js master against previous KC release
On 15 June 2017 at 14:43, Stian Thorgersen <sthorger(a)redhat.com> wrote:
Having multiple branches to control the version of Keycloak is not
the
right approach. IMO Travis should just test with the latest Keycloak
release, then we should have a CI job in Central CI that checks with
Keycloak and RHSSO master.
On 12 June 2017 at 11:18, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Sure. We actually have this issue:
https://issues.jboss.org/brows
> e/KEYCLOAK-4985.
> Which we could catch earlier, if we had the CI running tests against
> the changes on Keycloak repo.
>
> So the idea is pretty much it:
>
> - latest: test the latest released version of Node.js adapter, against
> the latest stable version of the Keycloak server (we already do this).
>
> - master: test the latest changes from the Node.js adapter, against the
> latest changes on Keycloak server.
>
> Another alternative, if you don't like this idea, is to have a build
> matrix
> on Travis. The same idea from keycloak server tests. Or we can do nothing.
>
> The solo porpuse of this change is to guarantee that we catch issues
> like this earlier.
>
>
> On 2017-06-12, Stian Thorgersen wrote:
> > This doesn't make sense to me. Can you elaborate a bit more? The reason
> it
> > makes sense to have two branches for quickstarts is that one branch is
> Dev
> > and the other is the latest release. For node.js I can't see that being
> the
> > case as there's "proper" releases and tags and such stuff
> >
> > On 9 Jun 2017 6:25 pm, "Bruno Oliveira" <bruno(a)abstractj.org>
wrote:
> >
> > Good morning, I would like to propose the creation of 2 branches for
> > Node.js modules following the same approach from the quickstarts:
> >
> > - latest: stable
> > - master: development
> >
> > The initial motivation behind this, is to enable Travis to test these
> > modules
> > against the latest change on Keycloak server.
> >
> > Thoughts?
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
>