Matthew Knepley <[email protected]> writes: > On Mon, Jun 6, 2016 at 11:57 PM, Barry Smith <[email protected]> wrote: > >> >> In order to allow decent pre-testing before merging to next I had Jason >> write a shell script to talk to a Jenkins server and organize a Jenkins >> server to accept such tests with decent turn around. Little did I know how >> rigid Jenkins is in how it wants to do things; so the final result was just >> too cumbersome to deal with websites and job numbers .... >> >> I'd like us to try again this time with just ssh and simple scripts >> (Jenkins is just not suitable). From the user point of view one would be in >> a git branch such as >> >> ~/Src/petsc (my-cool-branch=) >> $ ./bin/submittest options >> >> depending on options and a configuration file it would launch a series of >> tests on the local machine or any another machine you have ssh keys for. It >> could even have an option like --merge-to-next where in the tests it merges >> the branch into next automatically before running the tests. The jobs would >> all be run (even on the local machine) off of other clones so wouldn't >> interfere with your own work. By default it would run a few cases that >> usually mess up, a complex, a quad precision, a c++, a 64 bit integer etc. >> this will catch most basic errors. >> > > I like this very much. I would also be happy with just email responses, > although I do not see why we don't just use the current filter for the > nightly runs on it. > Just let me know what we have and I will start using it.
In theory, you could use our build status api: https://blog.bitbucket.org/2015/11/18/introducing-the-build-status-api-for-bitbucket-cloud/ This would allow you to test any (or every) branch (before merging) and update the commits that pass/fail. If this works out for you guys, it could be used to update the status of a pull request (if that's of interest to anyone). I think the yt project uses jenkins in this way, I believe. There's also (free and beta) Bitbucket Pipelines but that is based on docker and I'm guessing you have tests specifically for things that docker doesn't support.
