But it appears that Hudson only allows one SCM entry.
One CVS entry, sure. Or multiple SVN or Git entries. Another reason to
abandon CVS! :)
Regarding automation and source fetching... I have done some work with
Tycho/Maven as the build engine, supplemented by Ant to do some extra
build magic. (Specific example is that we build some plugins/features
for Drools to wrap the plugins/features that the Drools team does
themselves; rather than rebuild their code, I use Ant to fetch their
latest binary build from their Hudson job, unpack it, and have it
available against which to compile our stuff.) Ideally they'd just
publish a p2 repo against we could resolve the target platform, but for
now this works just as well.) You could do the same to fetch CVS sources
if you wanted... but really, moving to SVN or Git would be an even
better idea. :)
Nick
On Jul 8, 2010, at 3:28 PM, Nick Boldt wrote:
That's pretty much how PDE works...
1. Hudson checks out your code into its job workspace.
2. When changes occur, it kicks a build for you.
3. Then the PDE build fetches sources from map file and you end up with double
the source on disk. Hella inefficient.
Alternative approach is to have the PDE build use local sources already on disk
as fetched by Hudson, rather than having the build provision the sources for
you. Athena does this using the localSourceCheckoutDir variable; Bucky prolly
has an analoguous approach.
There's also the non-PDE approach using Tycho+Maven, which simply builds from
the already-available sources in Hudson's workspace. Doesn't support fetching
from map file, only from a branch/tag (that is, it'll build whatever Hudson's
already fetched). Ideal for CVS, SVN, or Git sources.
Nick
On 07/08/2010 02:38 PM, Miles Parker wrote:
Hi all,
I'm wondering how people are setting up SCM WRT Buckminster.
1. As I understand things it seems like best practices with Buckminster would
involve pulling everything from Version Control through Buckminster?
2. Except that the releng site, i.e. rmap, cspec etc.. obviously need to be
there so they need to be bootstrapped into the Hudson workspace, presumably
through Hudson SCM.
3. And, you want any changes in covered code to trigger an SCM which (I think?)
means bringing all of that stuff over from SCM first.
2 and 3 sort of seem to conspire against 1, or am I missing something here.
Also, I think this might have been asked before, but is there any way to view
the configurations of other projects to see how they've got things setup?
cheers,
Miles_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling& Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev