[squeak-dev] CI Job artifacts

Frank Shearar frank.shearar at gmail.com
Wed Oct 16 11:42:29 UTC 2013


On 16 October 2013 11:51, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hi,
>
> On 16.10.2013, at 12:36, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> On 16 October 2013 10:23, Tobias Pape <Das.Linux at gmx.de> wrote:
>>> […]
>>> I have not seen the mail… which are you referring to?
>>
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2013-October/013852.html
>
> got it.
>
>>
>>> Isn't it as simple as
>>> set -e
>>> in the bash script?
>>
>> That's what I want, but it's what I currently can't have, because
>> running the script will _always_ return success.
>
> oO
> I see.
> https://github.com/squeak-smalltalk/squeak-ci/blob/master/lib/squeak-ci/build.rb#L259
> At that point you want to make sure that the exit code of the
> Rakefile is _never_ 0 when stuff like that happens…

https://github.com/squeak-smalltalk/squeak-ci/issues/39 should satisfy
this criterion (when it's actually done, of course). It's not entirely
ideal, because we can't tell the difference between a successfully run
script and one that broke, but at least it would let us tell the
difference between a script that hung and was then killed, and one
that _completed_.

>>> […]
>>> I tried updating my trunk image from july, Mac, current CogVM,
>>> crashed, too.
>>
>> Gah. OK, so it's a serious problem, and not just me.
>>>>
> […]
>>>> (*) This failure to bail the entire job means that the image the tests
>>>> run against is a didn't-actually-update image, so you end up with a
>>>> 4.4-12327 image.
>>>
>>>
>>> Apparently.
>>
>> Well, on the plus side we can at least understand why we get the
>> unexpected result!
>
>
> Yes. I think jenkins does the right thing™ when we exit with non-null
> status, and a subsequent archiving step could be skipped…

Yes, I think so.

frank


More information about the Squeak-dev mailing list