Andi Abes (andi_a...@dell.com) wrote: > > -----Original Message----- > > From: crowbar-bounces On Behalf Of Adam Spiers > > Sent: Monday, March 11, 2013 2:24 PM > > To: crowbar > > Subject: [Crowbar] testing and pull requests > > > > "What testing do we run before submitting?" is a key question; thanks for > > bringing it up. Unfortunately the answer is currently "only whatever we run > > manually", since Travis only runs on a merged repository containing master > > from each barclamp repository, due to barclamps currently being unable to > > run > > their unit tests standalone. > > (There are Trello cards to address this, but it's unlikely to get fixed > > soon.) > > The general pattern we've been following is to have barclamps extend > framework provided classes, and that code currently resides in > crowbar/crowbar_framework... so to get to a point where we can run unit tests > for standalone barclamps will require copying in the framework.... (chicken, > meet egg...).
Hmm ... hopefully there is an industry-wide best practice for reusing shared code between engines which we can follow? > > That means we all need to be as conscientous as possible by running tests > > before every pull request, otherwise master is likely to break often. I > > just spoke > > with James and agree with his proposal to prototype barclamps as gems which > > can run their unit tests standalone (I get the impression engines should > > help > > with this but I am not an expert in the area). That would allow Travis to > > run on > > pull requests to individual barclamp repos. > > A possible short term approach that would give us testing prior to > pull requests being merged would be to reflect Pull requests from > the different repo, into the travis repo. Right, I created https://trello.com/c/6qn6cd0z for this a few weeks ago. Sorry if I didn't publicise this enough at the time. > How is this different from what's happening now? > Now, the update-git script checks for changed files between the travis repo > (as checked-out locally on the server running the script) and the main > crowbar repo. If it finds differences, it pushes an update to the > travis-ci-crowbar repo. > This process will only catch all the merged pull requests. > > The approach I proposing works differently: > On a periodic basis, pull the crowbar repos (crowbar and each barclamp) for > pending pull requests. For each open pull request, create a pull request > against the travis-ci-crowbar repo. This in turn will trigger travis to test > the pull request, before it is actually merged. No, I think we want to stick with handling bundles in a single pass, so that each Travis pull request corresponds to a bundle, or to a singleton if there is no bundle. > There are a few complications that need to be handled (but I believe a > solution exists for both): > a) Bundles - often there are sets of pull requests against different > barclamps (or framework + barclamp) that will only pass tests if > they're evaluated as a 'bundle' (i.e. both sets of changes are required). I already outlined a solution for this in the Trello card and in fact even took the first steps towards implementing. One approach is to iterate over the ids provided by "./dev ci open-ids" and ensure that for each, a branch called (say) pull-req/$ID exists. If not, create it via "./dev pull-requests switch" followed by the normal rsync. Then use something like "hub" to issue the pull request to the Travis repo. I have already forked the repo to the Travis commit-bot's account to allow this. The other approach is to merge into a non-flat tree using git subtree, and perform the tree merging at test-time by telling Travis to do the "./dev tests setup" bit. This has the advantage of preserving commit history, authorship etc. See also https://trello.com/c/tqCDVLgH _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
