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/
------------------------------------------------------------------------------
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
