[squeak-dev] Is the FileList broken in trunk?

Frank Shearar frank.shearar at gmail.com
Sun Dec 15 22:55:00 UTC 2013


On 15 December 2013 22:03, Chris Muller <asqueaker at gmail.com> wrote:
> On Sat, Dec 14, 2013 at 5:13 PM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 14 December 2013 20:53, Chris Muller <asqueaker at gmail.com> wrote:
>> > Hi Frank!  I actually put this message out to lure you into this
>> > discussion.
>> > :)  Because, I want to move on 4.5 and I knew you had _something_ out
>> > there,
>> > but couldn't remember all the details.
>>
>> You used the right kind of bait, that's for sure :)
>>
>> > The issues I faced with needing to get a new image were:
>> >
>>  > - I had to research the mailing list to find out where to download it.
>> An
>> > automated build server is great for doing continuous *testing* and
>> > reporting, but it seems like for end-user downloads we should have a
>> > copy
>> > available at the usual place (ftp.squeak.org).
>> > - When I downloaded the image from CI, updated, and ran the tests, I
>> > found
>> > there were more tests failing than in another image that was simply
>> > updated
>> > from 4.4.  Something seemed to be wrong with the image state.
>> > - Since I was not really certain what all was done in that image, I
>> > could
>> > not trust putting it on the squeak.org FTP site.  The only way I could
>> > be
>> > SURE enough about the state of an image put there was to take the
>> > archive
>> > release image (4.4) and simply update it myself and save it.
>> >
>> > So, the overarching requirements:
>> >
>> >   - Downloadable from squeak.org domains.
>> >   - A way to know exactly how it was built:  This means knowing which
>> > prior
>> > _full release image_ was started with, and what changes (both code and
>> > objects) were made.
>> >   - Reproducible build.  My idea since 4.2 was to have a utility method
>> > on
>> > ReleaseBuilder do all of this so it would be visible straight in the
>> > trunk
>> > repository.  I guess I always thought of the CI's responsibility as a
>> > on-going "test-status reporting" mechanism more than a deployment tool.
>>
>> Yep, yep, yep. I agree with all the above.
>>
>> There is something wrong with the base image state at the moment,
>> partly because I'm incapable of pulling out ToolBuilder-Tests in less
>> than at least three attempts (sigh!). (*)
>>
>> So the idea I've always had with CI was this:
>> * take a known-good base image (not happening right now :( )
>> * update it
>> * run a battery of tests on a copy of the image
>> * run the release process on the image (ReleaseSqueakTrunk)
>
>
> Perfect.  (I assume you meant ReleaseBuilder).

Yes. Run from a script. Outside the image. In fact, we have one.
https://github.com/squeak-smalltalk/squeak-ci/blob/master/release.st

(It needs to lose the CommandLineToolSet fileIn at some point.)

The reason for "outside the image" is because it means the release
person knows they haven't accidentally mutated state in some random
way. Also, automation.

>> Every now and then, someone can take the latest ReleaseSqueakTrunk
>> artifact, takes a look at the test results on build.squeak.org, plays
>> around with it. If it's fit for purpose, he or she pushes the artifact
>> up to ftp.squeak.org as a release candidate. Everyone else bangs on
>> it, and if the release manager's happy, it ships.
>>
>> I do think that manual verification is important, because we don't
>> want random broken builds on ftp.squeak.org, even if they're declared
>> as alpha quality.
>
>
> Absolutely.
>
>>
>>
>> Additionally, as you rightly point out we need someone to advertise
>> build.squeak.org. Not just that it's there and we use it, but how to
>> get a bleeding-edge image, for instance.
>
>
> A link from the main web-site and also from an appropriate page(s) in the
> wiki would be a start.  We should have a page on the wiki dedicated to
> explaining the CI server overview anyway.

Yep.

frank


More information about the Squeak-dev mailing list