We looked at Travis CI, but it has a fundamental issue that Travis people feel they don't want to fix. Which is that by default it only tests the branch, without concern for what is on Trunk. Which you can fix in your own hook, by merging trunk before running the test suite. However, it also doesn't run the test suite again when Trunk changes, which means you can't actually be sure that the test suite will pass when it is finally merged. e.g.: If I change an API to take another parameter, and then fix up all callers to pass a default parameter there, my test suite passes. If you write a function that starts calling that API before I change it, your test suite passes. If either of our code is merged without resolving the other one, the test suite will break because there is a caller that isn't passing the new parameter. So you do need to run the test suite at the time of merging if you actually want the security of "the test suite has passed on all revisions that land on master".
Travis CI would give a nice level of "everything looks good so far, go ahead and try to merge". But we still need the final bot to run the tests, so we started there. I would imagine it would be easier to update that bot to do "would this be good if I merged it right now". And it could go through the backlog as it has free CPU. The nice thing about Travis is that they donate a *lot* of CPU to do your testing for you. As a very quick pass, just having the 'test' compile the whole source code would actually be fast to do, and still be a reasonably useful test. John =:-> On Thu, Jun 5, 2014 at 10:07 AM, Jonathan Aquilina <[email protected]> wrote: > Not trying to hijack this thread, but a suggestion for reviewing and CI > testing. I have a hunch you guys already have something in place, but > there is TRAVIS CI which integrates nicely with github repos through a > yaml file. > > When a pull request is submitted it performs a build and then on the pull > requests lets you know if the build was successful with that change or > not. > > Apologies if this derails the topic, but in terms of reviewing it might be > helpful. > > > You can keep updating a pull request as your work on a feature. Old diffs > > and comment are preserved. On nice feature is that old comments are > hidden > > if the area of the code they reference is changed by a later diff. > > > > This link from the Github people themselves is light on detail but talks > > about how they use a pull request as a way of tracking work in progress > > right from the beginning of the development of a feature. > > > > https://github.com/blog/1124-how-we-use-pull-requests-to-build-github > > > > I guess this doesn't address the email spam problem but it does seem like > > it would work otherwise. People can individually opt out of notifications > > about a specific PR but that's not really ideal. > > > > > > > > > > On 5 June 2014 15:41, Ian Booth <[email protected]> wrote: > > > >> You can, but then you loose any previous comments and history on the > >> previously > >> work in progress pull request. With Launchpad, you could just flip the > >> status on > >> the merge proposal and all the comments would be retained. > >> > >> On 05/06/14 13:38, John Meinel wrote: > >> > Can't you just create a new Pull request when it is finally ready? > >> > > >> > John > >> > =:-> > >> > > >> > > >> > > >> > On Thu, Jun 5, 2014 at 7:25 AM, Ian Booth <[email protected]> > >> wrote: > >> > > >> >> One of the many things I miss now that we have moved to Github/git is > >> the > >> >> ability to put up a merge proposal with in-progress work, allowing > >> >> collaboration > >> >> on the implementation as it evolves etc. Launchpad supported this > >> nicely, > >> >> as it > >> >> didn't spam people with emails for wip mps etc. > >> >> > >> >> I don't think Github supports this concept. Perhaps a way around it > >> is > >> to > >> >> do a > >> >> pull request against one's forked copy of the main Juju repo. That > >> way, > >> >> people > >> >> can still easily see your work, but without the general spam. Sadly, > >> it > >> >> doesn't > >> >> allow the pull request to then be re-targetted to the Juju repo when > >> ready > >> >> to be > >> >> reviewed for real. Or does it? > >> >> > >> >> Does anyone have any better ideas how to do this? > >> >> > >> >> -- > >> >> Juju-dev mailing list > >> >> [email protected] > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >> >> > >> > > >> > >> -- > >> Juju-dev mailing list > >> [email protected] > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >> > > -- > > Juju-dev mailing list > > [email protected] > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
