[Pharo-project] Silly Tweet
norbert at hartl.name
Thu Jun 30 05:24:50 EDT 2011
Am 30.06.2011 um 10:32 schrieb Stephan Eggermont:
> Stef wrote in response to my:
>>> Ok, so you simply do not want the builds to be used by others.
>>> That's fine.
>> why do you say that?
> Such a build server can have two purposes:
> - to directly help with the development of the software named in the build jobs;
> - it can provide a starting point for others to base their work on.
> Both are valuable, and it is acceptable if you want to want to focus on the first.
> For the second, as a commercial developer I have to be able to make my upgrade
> schedule as independent as possible from that of the projects I depend on.
> Depending on artifacts with an unknown availability is not possible.
Exactly. And that is the reason why it will be very hard not to have your own CI server. The official distribution will rarely match your requirements. We all patch packages here and there. That you can only deal with in your own setting.
All CI servers that I know (most of big development teams) face sooner or later the same thing. You might think disk space is endless or CPU but it is not. I don't know any bigger CI server that still builds all commits. It is just not possible because CPU and disk space isn't there enough. From that angle it is even more important to remove the things that aren't really needed.
I think you are actually looking for a reliable download location and the CI server is the wrong place for it. That's why there are last successful builds. The can be copied to a download server and rest forever.
my 2 cents,
>> What is the point to have a build server build all the time the same same same same same
>> same same image?
> A build server is used as we've learned there is no such thing as the same same image.
> There have been regressions because of vm changes or operating system updates,
> and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside
More information about the Pharo-dev