Thanks Dennis, that's extremely helpful. On Aug 10, 2010, at 2:00 AM, Dennis Hübner wrote:
> 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. Good to know. I'm having hell of a time getting local Hudson to work with CVS, and I think I'm just going to give up on that. I want to go to Git as well, but I don't have time right now. >> 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 > Yes, that solves a real problem for sure. > > 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. OK, so it sounds like it is actually doing a post-build check. That's a nice extra. -Miles_______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
