On Wed, Feb 25, 2015 at 01:08AM, Jay Vyas wrote: > 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?
I think that quite within the reach: standard CI containers and admittedly slow progress of making gradle build a focal point of everything should do it! > > > 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
