Hi Miles,
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.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.
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.zip2. Why do you use both mv shell script and archive artifacts?
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.
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.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.)
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.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?
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 [email protected] https://dev.eclipse.org/mailman/listinfo/xtext-dev<Xtext-nightly-HEAD Config [Hudson].webarchive>
_______________________________________________ xtext-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/xtext-dev
