[buckminster-dev] Re: Tutorial for building an RCP from hudson

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Henrik,

Henrik Lindberg schrieb:
> Johannes Utzig wrote:
> > Hi Henrik,
> >
> > I'm not sure I understand you right. A patch against the tutorial 
> > project? I already added a patch to make it buildable for the tutorial 
> > and it has been applied, or are you talking about the MSPECs, CSPECs 
> > and the RMAP? Should they live in the releng project of the tutorial? 
> That is what I had in mind.

Ok, I will create a patch for that and open a bugzilla.

> > If so, I can create a patch for that of course, just wasn't sure if 
> > that's what you meant because the other demo queries and rmaps seem to 
> > live in http://www.eclipse.org/buckminster/samples...
> The artifacts that need to be easily shareable (i.e. starting from 
> nothing) should be published there as well.

ok, that would indeed be the mspecs, cspecs and the rmap then.

> > If you guys are ok with the general approach and the tutorial can be 
> > added to the buckminster examples section, I think it could 
> > incrementally demonstrate more advanced features of CI. I could think 
> > of -unit testing
> > -code coverage
> > -benchmarks
> > -metrics (like sonar)
> > -build triggers on commit action
> > -building specific branches/tags
> > -qualifier replacement
> >
> > What do you think?
> I think it is an excellent idea. We have to decide on if we want 
> something that builds up gradually (different instances), or if there is 
> one that includes everything. Maybe have two? The current mailapp 
> tutorial as it is to not overload it with stuff, and then one with 
> everything (and extra mayo :).

That makes sense (although I hate mayo :)). Once the rest is in place I 
can open a new bugzilla and attach a simple test fragment for example. 
The advanced stuff can go into a new wiki page then.

> > It's also quite handy IMO to see the current pains of buckminster 
> > integration in real life.
> > -no changelog for checkout
> > -no update functionality (which forces the user to delete the 
> > workspace prior to a build)
> > -no polling support (which makes it hard to trigger a build on commit 
> > actions)
> > -plugin unit tests are currently difficult to execute
> >
> > Until Peter has finished the 'Buckminster updating / change-list 
> > generation' and issue 243293 (JUnit support) is resolved, the tutorial 
> > can help explaining how that's currently done, and once those features 
> > are in place, the tutorial can be an example on how those new 
> > capabilities can be utilized.
> Issues understood - do you think that is worth while? Isn't it better to 
> wait for the proper solution and document that?

That depends a little on the timeline I'd say. Unit testing is crucial 
for CI and it's currently not super easy to get it up and running. If 
the JUnit support is in place relatively soon (including plugin unit 
tests) then it would be easier to wait, however, if it will take some 
months until the changes are done and actually released, then I think a 
little guidance on how to set it up 'the hard way' would help people a lot.

> > Btw: The eclipse foundation has a hudson up and running as well, right?
> > Would it maybe be possible to set up an example job for the Mail-App 
> > RCP and give anonymous users the right to view the job configuration?
> Hm, not sure if that is doable (permission to view some jobs). Maybe 
> Thomas knows...
> Meanwhile, would it be possible to store the job config in mailapps 
> releng component?

I haven't tried it before, but I think it should be possible since 
hudson is completely file based. I can zip up a minimal job (with just 
the configuration) and the user should be able to extract that into 
hudson's job directory. However, the configuration will have to include 
the location of the MSPECs, CSPECs, RMAP, so I can't create the patch 
until I know the final location of those files (i.e. until you actually 
uploaded it to eclipse.org and told me their whereabouts).


Best regards,
Johannes