[EnMasse] generated artifacts

[Rob Cernich]

Not sure if it's still available...most jobs make it look like it hasn't done anything for a year, but...https://hudson.jboss.org/hudson/

It would be interesting to find out where/how folks are doing their community builds....which a quick google turns up:  https://ci.wildfly.org (login as guest, no password).  Interestingly, there's an artemis build there.


----- Original Message -----
> On 04/10/2017 09:41 PM, Rob Cernich wrote:
> >> Here is a description of the enmasse CI:
> >> https://github.com/EnMasseProject/enmasse/tree/master/documentation/ci
> >>
> >> It basically does build & test -> pushes to docker hub -> triggers
> >> systemtests which does a openshift deployment with enmasse + tests. I
> >> would prefer if we could keep the upstream community bits built and
> >> relased using travis + github.
> >
> > Given that we're talking about doing builds for the artifacts going into
> > the images, I think it would be fine to use jenkins to build the artifacts
> > used within the images (e.g. the patched versions of qpid/proton).  This
> > would create a clean separation between the images and the artifacts being
> > installed in the images (which, btw, we'll need to do anyway once we get
> > to productization).  The only issue I see with doing this in travis is
> > that travis doesn't store build artifacts, and there's no real place to
> > upload these artifacts.  So..hybrid approach, build the artifacts in
> > jenkins; build the images in travis.  Also, I'm guessing you can use a
> > webhook with travis so you can invoke a build upon completion of the
> > jenkins job.
> >
> 
> I agree it is nice to split artifact build from images, but hopefully we
> could use jboss nexus for that. Alternatively if jboss nexus does not
> support zip/tarballs, we have been granted a sonatype repository we
> could start using: https://issues.sonatype.org/browse/OSSRH-25298
> 
> Using internal jenkins jobs for internal testing and productization is
> ok, but we can't remove the upstream CI or have upstream depend on it.
> The requirement for an upstream jenkins would be:
> 
> * it must be publicly visible
> * it must allow non-redhat employees part of the enmasse project to
> configure and start jobs
> * build/test github pull requests
> 
> If there is a public jenkins instance we can use for this, then I'm not
> against using that.
> 
> >>
> >> Setting up internal jenkins jobs to do these builds in addition would be
> >> nice. We have a messaging CI that we can use for that, but I'm currently
> >> awaiting some restructuring in the CI machines so that we can run
> >> systemtests against an internal openshift instance.
> >>
> >>
> 
> 
> --
> Ulf Lilleengen
>