[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dash-dev] SCM and Buckminster on Hudson
|
Hi,
i am playing with buckminster for building some artifacts and i already
have done CBI jobs, so i have a view of the two systems.
For both, hudson have to listen the entire source tree to trigger a
build on modification. no magic here, it will checkout the source code
in both cases.
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.
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 ?
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@xxxxxxxxxxx
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev
begin:vcard
fn;quoted-printable:St=C3=A9phane Bouchet
n;quoted-printable:Bouchet;St=C3=A9phane
org:Obeo
adr;quoted-printable:BP 20773;;7 Boulevard Amp=C3=A8re;CARQUEFOU;;44481;France
email;internet:stephane.bouchet@xxxxxxx
tel;work:02-51-13-61-67
x-mozilla-html:FALSE
url:http://www.obeo.fr
version:2.1
end:vcard
