Travis CI support about ctf HOT 15 CLOSED

Can you explain why we need this? I see no motivation or general description of functionality on the Travis website. I am not eager to find out and debug issues for older versions of gcc at the moment, if this is what is being offered. The kind of automated testing I would really want would require regular runs on a supercomputer across scales and builds on different supercomputers. Basic automated testing infrastructure is useful when there are a lot of developers, but the opposite is the case for CTF at the moment. I don't think I break master very often, and I usually at least run parallel tests of intel/clang/icpc before merging.

Also, I think it could make perfect sense to do this for AQ without having it for CTF, since AQ checks out CTF automatically.

from ctf.

Travis is a free continuous integration (CI) service with significant Github integration. CI is used to verify the code is working for the prescribed set of tests. Travis runs automatically when one pushes commits and when a pull request is created.

One major advantage is that one does not have to manually verify that pull requests won't break the build for the test configurations. For example, if someone creates a PR that depends upon GCC-specific behavior, Travis will catch it because the Clang tests won't build. The same is true if something works on Linux but not on Mac. You will see the outcome of Travis in the Github PR itself. See for example ParRes/Kernels#26 where it says "All checks have passed".

You can see the results of Travis support for MADNESS here. We find Travis is very useful in catching regressions, both because of issues in our code and because of toolchain wonkiness.

from ctf.

You can use Travis to generate a test harness for any machine. See https://github.com/travis-ci/travis-build. I intend on setting this up for the PRK project and running regular tests at NERSC. I don't know if I can do this completely automatically (NERSC may not like me running a daemon on the login node) but at least I can make it fire in only one line of shell, while still capturing any test harness changes I've made upstream.

from ctf.

I recently set up Jenkins CI for NCC/CFOUR. I decided not to go with
Travis because I wanted to include end tests/unit tests/performance
tests/static anlysis/etc. which seemed out of the scope of Travis
(correct me if I'm wrong). Either way, some form of automated testing is
important in my opinion.

Also, I have now "Seen the Light (TM)" of unit testing. I've implemented
some in NCC and already saved more time debugging than it took to write
them. Ideally one would write the unit tests first, but even writing
them later is extremely helpful if the code might ever change or has
troublesome edge cases. I used Google Test for this, which is pretty
easy to set up.

On 1/8/16 12:13 PM, Jeff Hammond wrote:

You can use Travis to generate a test harness for any machine. See
https://github.com/travis-ci/travis-build. I intend on setting this up
for the PRK project and running regular tests at NERSC. I don't know
if I can do this completely automatically (NERSC may not like me
running a daemon on the login node) but at least I can make it fire in
only one line of shell, while still capturing any test harness changes
I've made upstream.

—
Reply to this email directly or view it on GitHub
https://github.com/solomonik/ctf/issues/12#issuecomment-170078285.

from ctf.

@devinamatthews Travis doesn't do that but Coverity provides Github integration. I'm going to be working on Coverity support for some of my projects at some point.

from ctf.

I'm going ahead with Jenkins for CFOUR because I think it's easier to
pitch CFOUR people (local control etc.). I'll let you know how it works out.

On 1/8/16 3:21 PM, Jeff Hammond wrote:

@devinamatthews https://github.com/devinamatthews Travis doesn't do
that but Coverity provides Github integration. I'm going to be working
on Coverity support for some of my projects at some point.

—
Reply to this email directly or view it on GitHub
https://github.com/solomonik/ctf/issues/12#issuecomment-170126733.

from ctf.

@devinamatthews Indeed, Travis only supports open-source projects in the free version, which doesn't work for CFOUR :-) Jenkins is indeed the right way to go for local control. MPICH uses Jenkins because they run across a range of internal machines.

from ctf.

I am finally working on this, but it is still in-progress.

• https://github.com/jeffhammond/ctf/tree/travis-ci
• https://travis-ci.org/jeffhammond/ctf

from ctf.

One of the four targets works now: https://travis-ci.org/jeffhammond/ctf/jobs/150325407

from ctf.

@solomonik: re the Transform<double, dpair> error: std::function has a
templated constructor (which is not required to select only appropriate
functor types), so there is no preferred conversion to different
std::function types. You can either construct a std::function of the
appropriate type yourself or add SFINAE to tempated Transform
constructors to check whether the argument is appropriately callable.

On 8/6/16 4:36 PM, Jeff Hammond wrote:

One of the four targets works now:
https://travis-ci.org/jeffhammond/ctf/jobs/150325407

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/solomonik/ctf/issues/12#issuecomment-238054520,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAMoWrF1kcsxms9xYPQIYy_q0C90htzks5qdRqTgaJpZM4HBVej.

from ctf.

@jeffhammond thanks
@devinamatthews The latest versions of gcc seem to be able to infer the right constructor based on the signature of the lambda, but yes it might not be part of the standard and is an issue for new compilers. This SFINAE thing sounds like the right work around, I just learned about it a couple of weeks ago when discussing this precise issue, and think its also applicable for inferring algebraic structure functionality (the other place in which CTF relies on advance C++ feature). I've since started working on getting CTF to be less dependent on new versions of gcc, with the goal of getting it to build with compilers like XLC and Fujitsu. However, I think this will take a couple of days of development and I am moving to Champaign in the coming week, so it may not get done until 2-3 weeks from now.

from ctf.

{GCC,Clang} x Linux are passing: https://travis-ci.org/jeffhammond/ctf/builds/150699779. I vote to merge since Mac issues are not easily resolved in Travis.

from ctf.

Ok, sorry for the delay, am now trying to merge this. So I think I activated solomonik/ctf on Travis. The next step would be to add a yml file, but it looks like you already did this. Could you create a pull request or is there some other way for me to merge?

from ctf.

You already merged everything with solomonik@47e99b9.

from ctf.

That would explain why I couldn't find anything to merge... ok, now got a build to trigger via a push to master. Will close this, thanks for your contribution.

from ctf.