Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [xtext-dev] Build config 
 Hi Miles,

1. Have you thought about the following issue with multiple CVS imports? It seems that because we use CVS SCM management, but also Buckminster is pulling from CVS (i.e. you aren't using "local" reader) that it only makes sense to grab latest releng as you're doing rather than the whole source tree. And the buckminster cvs provider once it sees artifacts in workspace it simply leaves them as is. This means that it is impossible to use SCM triggered builds anymore, correct? Which means that I think you have it set up to just automatically trigger every t periods. And then you need to simply wipe out build space every time a new build is triggered. I suppose that is probably best anyway to ensure an absolutely clean build but it means two areas where resource use and build time would go up.
Now we use git as SCM, but for CVS I think it's a good idea to checkout/update with hudson, because of hudsons "Last changes" feature. Than point buckminster to this checkout location for grabbing sources. SCM triggered builds are not a problem any more. 
2. Why do you use both mv shell script and archive artifacts?
mv shell moves files from some deep folders in your hudson workspace root, than archive artefacts stores this files in your build folder (#30 or what ever). Means if you just use archive artefacts only, you will get very long URLs like https://build.eclipse.org/hudson/job/Xpand-nightly-HEAD/lastSuccessfulBuild/artifact/maybe_some_very_long_path/yourfile.zip 
3. It looks like promote process is now different, that is you have a custom ant task for that. But I can't actually find the source of ${WORKSPACE}/publishroot/publisher.ant in your xtext releng.
Just copied it from https://build.eclipse.org/hudson/job/buckminster-zzzTEMPLATE/ :D 
  Can you tell me where it's located and if there are advantages to that vs. using the cron job? (Except the obvious one of not having to maintain that separately.)
For the publisher there is a web front, so not only you but other developer are able to promote too. An another advantage is that hudson shows you which builds was promoted and so the current promote state. 
4. There is a parameter for REFERENCE_REPOSITORY. This seems to be used for comparison purposes, but I'm not sure why it's needed, that is why you don't simply promote any new build. Is that being referred to from the publish script?
If your build was not triggered by SCM, there may be builds where nothing is changed. They will be normally promoted (i.e. cron job) and so marked as updateable/new. Reference repository should prevent this. 

Regards,
Dennis.


cheers and thanks again,

Miles


On Jul 16, 2010, at 12:25 AM, Dennis Hübner wrote:


Hi Miles,
we still have problems running UI-Tests with Buckminster,
so its probably not the perfect way to configure hudson.

However zipped Hudson configuration site is attached.

Regards,
Dennis.

Am 15.07.10 23:20, schrieb Miles Parker:

Hi guys,

Don't go out of your way to do this, but next time someone is mucking with the Hudson build, could you take a screenshot of your build config for me? I want to see what other projects are doing to setup their bucky builds and this is the only thing I can't look at.

thanks,

Miles_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev

<Xtext-nightly-HEAD Config [Hudson].webarchive>

Back to the top