On Jul 9, 2010, at 12:50 AM, Stéphane Bouchet wrote: > Then, again, both will checkout code according to map/rmap files. BUt with > bucky, you can use another source code repository for some other piece of > source code. of course, if source code is modified and hudson is not > configured to check it, no builds will be triggered.
You can do that with a regular old PDE map file though as well. In fact that's how I have my amp build as it is dependent on some GEF3d stuff that doesn't have it's own build site. > > as nick said, there is a config for PDE that will use the checked out source > code, but you will not be able to get another source code from other > repository. you have to do this manually... > > > maybe you could split your build in 2 differents jobs ? You know, I thought about that, but the funny issue here is that it is the releng stuff itself that you need at build time, but the contents of the build are coming from another workspace. So it's more like I'd need to use one build to *trigger* another build..it starts to get a little silly after a while. Perhaps the thing to do is (no, no, not on the Eclipse build servers..!) do a build run every minute and as part of that build do a source change check and just abort the build if nothing has changed. But then you'd have to end up calling everything with ant and you'd be back to essentially putting together your own build infrastructure which is exactly what Hudson and Bucky are trying to provide. Ah, the perils of automation. > > > Le 09/07/2010 03:03, Miles Parker a écrit : >> >> One thing I've realized in playing around with all of these fancy build >> systems is that the rule seems to be "when in doubt, grab the entire set of >> dependencies and duplicate them (yet) somewhere else.." >> >> The reason this came up is that I want to do a build that includes some >> stuff from my Eclipse repos and some stuff from other places, but *that* >> means that my bucky releng stuff is not on the same server (or even VCS) as >> the source code under question. But it appears that Hudson only allows one >> SCM entry. So I guess that means that I'm going to have to do an ant-based >> fetch or something to get my buckminster artifacts *after* getting my source >> code, which I won't even use probably. Oy vey..I'll probably just end up >> triggering that build on a schedule. >> >> I guess I sort of thought that Buckminster would be different somehow. But I >> guess what it does is just create a plain old PDE build from all of the >> artifacts. So .rmap just becomes a .map. Which sorta begs the question why >> I've been making myself nuts writing an rmap when I already have a perfectly >> good .map. It turns out that my RMAP file ended up just as big as my .map >> file but there is just more logic there. At least now I won't have to edit >> the .map every time I add a project, but I digress.. >> >> If you do localSourceCheckoutDir it really begs the question what's the >> point of all of the mapping.. But of course the point there is the checked >> out directory structure doesn't match what PDE needs. >> >> I guess to be fair the point of doing all of the bucky stuff is not just so >> you can do a one off build but so you can provision anywhere, extend it, >> etc..but you lose a lot of that if you "cheat" by just using the source that >> Hudson grabs. >> >> -Miles >> >> 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 >> > > <stephane_bouchet.vcf>_______________________________________________ > 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
