Good point on integrate it with CI. Maybe what we all need is a way to run a subset of the bigtop ci locally ? It sounds like it's getting close to The point where this might be possible?
> On Feb 24, 2015, at 11:30 PM, Konstantin Boudnik <[email protected]> wrote: > >> On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote: >> Sorry to chime in late. It was Chinese new year started yesterday. BTW, >> happy new year to bigtop:) > > Happy New Year! > >> A script would be a lot of help for testing, so probably we can have a >> directory to store some dev tools like this, or put it on wiki first. > > Many years in the field thought me one thing: once you add little scriptlets > to ease development workflow - you create a mess that will eat you eventually. > If the scripts are detached - they will rot; if they are the part of the > source code - they will inevitably inflate as all developers are different and > they will want to get some tweak to meet there requirements. If we do anything > - it has to be baked into the build system. But I don't we can do a generic > enough tooling for every body. > >> My origin question is about the patch naming convention. >> In wiki >> <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we >> suggest contributors to upload same name for different patch attempts to >> better track the version. >> A problem for this is that there's a scenario which I'd like to vimdiff two >> different patches to know what has been changed. Same naming for patches >> would require me to rename patches in different names by myself, which >> might cause confusing, and probably result in a wrong version being >> committed. >> To be picky, named patches the same required tester to know how jira sort >> the patches(asc or desc), which I think is a little bit non-intuition. >> To sum up, I think it would be better to name them differently with a >> simple version number. > > If the name of the patch remains the same JIRA makes only the latest patch > link to be bright blue and the rest of them are sorta grey'ish - which > requires no thinking when you need to pick up the latest one. Otherwise, you > one has to look at the series and understand whot's the sequence, or change > the sort order, or else. Basically, I found same-name approach to be very > consistent. > > If you need to diff two patches you can always do > wget oneversion > wget anotherversion > and if second wget detects that the file with the same name already exists it > will add a numerical suffix to the later download. It has been already > thought through - just use the power of Unix tools ;) > > As for the workflow - it's pretty straight, I think: > - download > - apply > - build if needed > - deploy (if a deployment script) > - run tests (if required) > - review/comment > > The flow can be interrupted after each step if expectations aren't met. > > Cos > >> However, there might be a smarter way to do so. So it would be great if you >> guys can share your magic how to do the testing:) >> 2015/2/18 下午9:47 於 "jay vyas" <[email protected]> 寫道： >> >> hi bigtop. evans asked me an interesting question about how to maintain >> patches and test them and so on without getting mixed up in the bigtop >> patch review process. >> >> testing patches is tricky sometimes in bigtop, esp with so many different >> sections of the code base that we work on, and with needing to do things >> like create VMs dockerfiles and so on. >> >> This is all i do at the moment: A shell script which takes patch URL as >> argument, creates a new git branch, clears vagrant boxes. If folks have a >> workflow in their head, we can use this or something similar to expand upon >> for a unified test flow. >> >> or maybe we can think of a creative way to locally leverage and reuse the >> jenkins work folks are doing? >> >> >> #function to clean vagrant boxes, not in this snippet. >> delete_vagrant_boxes >> echo "Bigtop patch tester : $0, wgets the patch, applies in a new >> unique-named branch" >> if [ $# -eq 0 ]; then >> echo "USAGE: Takes patch url as input, applies it in a new branch" >> exit >> fi >> patch="`echo $1 | rev | cut -d'/' -f 1 | rev`" >> echo "PATCH = $patch" >> wget $1 -O /tmp/$patch >> wc -l /tmp/*patch >> >> echo "Checkout root branch and clean it?" >> read x >> git checkout jay_dev >> git clean -i >> >> echo "apply patch in new branch ?" >> read x >> git checkout jay_dev >> git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`" >> >> echo "apply patch now in this branch `git branch` .... ?" >> read x >> git am /tmp/$patch >> # shows the applied patch. >> git log | head >> >> >> >> >> -- >> jay vyas
