[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [xtext-dev] Build config
|
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
