[ofiwg] Travis CI testing of libfabric and fabtests

Jeff Squyres (jsquyres) jsquyres at cisco.com
Mon Oct 12 06:54:33 PDT 2015


FWIW, we've left such details to the sites running the CI tests. 

E.G., for the libfabric testing, the community doesn't really care what version of libnl that Cisco tests USNIC with, as long as we are happy with our testing (and that version of libnl may change over time). Likewise, most people won't care what specific version of the PSM / PSM2 libraries intel tests with internally. 

Make sense?

At Cisco, we've typically installed static versions of dependent libraries, just for a measure of stability in the CI testing. But other sites may have different requirements for their dependent libraries. 

Sent from my phone. No type good. 

On Oct 9, 2015, at 7:08 PM, Hefty, Sean <sean.hefty at intel.com> wrote:

>> I've also enabled branch protection to the upstream trees.  Now that
>> Travis CI is working, I'd like to propose that we require status checks to
>> pass before pull requests can be merged.  The only drawback that I see to
>> this is that there will be a small delay (~5-10 minutes) before simple
>> pull requests can be merged.
> 
> In order to build other providers, we have dependencies on external libraries.  We need to determine how we want to handle that.  For example, do we pull a specific version, use only what's available through the build system, or pull directly from upstream git trees?  We probably need some combination of these.
> 
> Pulling upstream git trees where reasonable allows us to stay current, but does open the possibility that status checks could fail because of a problem in the upstream code.  The benefits of forcing status checks still seem to outweigh the risks, but we need a general policy of how to handle external libraries.
> 
> - Sean
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg



More information about the ofiwg mailing list