[squeak-dev] Re: Build.squeak.org and squeaksource.com in danger (was Re: [Box-Admins] Disk space usage on box3)

Frank Shearar frank.shearar at gmail.com
Mon Dec 9 10:18:38 UTC 2013


On 8 December 2013 22:18, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sun, Dec 08, 2013 at 09:02:28PM +0000, Frank Shearar wrote:
>>
>> Er. I explicitly decided to produce versioned artifacts that a human
>> would assess for quality. I stand by that decision. You _should_ be
>> able to easily go and say "Well, version N is crap, but N - 2 is just
>> fine. Let's just go with that."
>
>
> I want to ask specifically with respect to the SqueakTrunk job, which is
> set up to do this:
>
>   Take a base image (currently 4.5-12565), update it, archive the result.
>   Run the entire suite of in-image tests.
>
> For that job, do we want to archive all build artifacts, or is it instead
> sufficient to discard all but the last successful/stable artifact to save
> disk space?
>
> I would like to make the following changes to the SqueakTrunk job
> configuration:
>
> 1) Archive just the TrunkImage.zip, not all of TrunkImage.*

I did this over the weekend. But I just noticed that I didn't
configure Jenkins to actually use the new zipfile. It does now.

> 2) Enable the "Discard all but the last successful/stable artifact to save
> disk space" option.

I specifically don't want to archive only the last successful build
because that makes it harder for us to debug problems. Imagine that
build 101 works, 102 doesn't, and 103 does. It turns out that 103
"succeeds" because of a completely bogus reason, like a bug in the CI
scripts. We need to see the last known good state, 101. But alas, it's
gone.

This is not what caused the disk usage problem.

> 3) Enable the "Abort the build if it's stuck" option, with a timeout
> of 30 minutes.

That's fine, but wouldn't have helped any time the build hung in the
past, because those hung processes were orphaned anyway. We have used
this feature, in fact, We don't anymore because you end up having two
separate places to define timeouts. Eventually it _will_ be useful,
once we teach Squeak to fail, rather than hang.

> Is it OK to do this for the SqueakTrunk job?

frank

> Dave
>
>


More information about the Squeak-dev mailing list