Thanks Steve, is does sound like a fine approach. - David
On Mon, 2014-06-16 at 05:45 -0500, Stephen Hicks, N5AC wrote: > Josh, > > > Just my two cents here. We switched to using Jenkins internally at > FlexRadio a while back along with a move to Git. ALL of the > developers in our company loathe SVN after using Git. We use feature > branches extensively and have a series of branches mainline branches > also. We have a develop branch that all the developers merge into > from their feature branches. When there's a problem, Jenkins fails to > build and everyone receives an email with what happened and the name > of the developer that broke the build. This causes two things: some > small embarrassment for the developer and the desire to correct the > problem and get the build running again. > > > We also use an Alpha, Beta and Master branch where we move code > through the life cycle at our shop. So when we release an alpha, we > move everything from develop to alpha. From this point, development > continues, but developers ask: will what I'm working on go in the next > alpha or not? If yes, they checkin to alpha and merge into develop. > Otherwise they check in to develop. The same goes for the other main > branches moving forward, checking individual fixes into master just > doesn't happen for obvious reasons. > > > Jenkins builds all four of these branches every time there is a push > to Git. From Jenkins we get a completed installer. This allows us to > tell anyone in the organization that they are free to grab software > from any of the directories (develop, alpha, beta or master) that they > want, knowing that develop might break things, etc. > > > Hope this helps, > Steve > > On Wednesday, June 11, 2014, Joshua Mesilane <[email protected]> > wrote: > Hi All, > > > I was talking to David on the weekend about setting up some CI > on the Codec2 and FreeDV projects, after I had some trouble > getting FreeDV going on my laptop. It seems the build > instructions on the repo are complete-enough but we've really > got not automated way of verifying if the source we're about > to build will actually compile or not, until we check it out > ourselves and try and compile it. > > > I'd like to set up a Jenkins Server, that will perform a fresh > build of the dependencies, compile codec2, and then compile > FreeDV, for this to happen however my testing so far has shown > a few things need to change. > > > Specifically, for this to be reliable, we need "Stable" and > "Non-Stable" sections of the repo for both codec2 and fdmdv2 > to use. > > > At present, we have codec2 and codec2-dev for codec2, but only > fdmdv2 for FreeDV. The way things currently stand, fdmdv2 > relies on codec2-dev to be installed to work, but there's > nothing really documenting that, save for a post that I sent > in saying "help it won't compile" > > What I'd like to propose is the following: > > > 1. If the current "codec2-dev" repo is "stable" merge this > over to the "codec2" repo > 2. Create a few "fdmdv2-dev" repo > 3. Set up Jenkins (I'm happy to do this) > 4. Set up a codec2-dev build task that runs each time code is > checked into the dev repo, and sends an email if the build > breaks > 5. As #4 but for fdmdv2-dev > 6. Set up a manually triggered task to pull codec2-dev into > codec2, this would first perform a build, then migrate the > files over with an appropriate regex to subsititute out any > codec2-dev requirements in any of the build files. This can be > executed each time we're happy that codec2-dev is ready for > release. > 7. Set up a manually triggered task to pull fdmdv2-dev into > fdmdv2, as per #6 > > What do people think? To me, this would give us a stable, > consistent codec2 and fdmdv2 repositories that we could then > use for things like setting up other tasks in jenkins such as > automating Windows Builds, Debian and/or RPM packages which > could then be pushed to a repo. We could also be packaging > "non-stable" versions for testing/bleeding edge features as > well. > > > It would also flag, straight away if there was a problem with > a build, or an incompatability between current dev versions. > > > Happy for feedback. What do you think? > > > Cheers, > Josh > > --- > VK3XJM > 0416039082 > [email protected] > http://www.zindello.com.au/ > > > > -- > > > Stephen Hicks, N5AC > VP Engineering > FlexRadio Systems™ > 4616 W Howard Ln Ste 1-150 > Austin, TX 78728 > Phone: 512-535-4713 x205 > Email: [email protected] > Web: www.flexradio.com > Click Here for PGP Public Key > > > > > Tune In Excitement™ > PowerSDR™ is a trademark of FlexRadio Systems > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
