My previous mail forgot one important thing:

On 26 July 2012 15:17, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
> HDTestReport runPackages: #(
>     'HelpSystem-Tests'
> ).
> "Save and Quit"
> WorldState addDeferredUIMessage: [
>     SmalltalkImage current snapshot: true andQuit: true ].
>
> or something more succinct:
>
> HDTestReport runPackages: ((WADevelopment allPackages
>     select: [ :each | each name includesSubString: '-Tests-' ])
>     collect: [ :each | each name ]).
>
>
> <the simple answer>
> tests.st is in the FTP directory. It contains the content above. Add test
> names as strings in the array like 'HelpSystem-Tests'. Or, iterate over some
> packages for '-Tests-'
> </the simple answer>

I get the idea of "this is autoconfiguring", but I don't like it. The
only way you can see what tests ran is by looking at the output. Well,
OK, that might be well and good, but it means you have to look at
Jenkins and poke around. It means you can't easily exclude a package
of tests that simply can't have its tests run today, but we don't want
to remove the package from the base image. (Also, I like
#select:thenCollect:.)

frank

> <longer explanation/probably a rant>
> I don't think GitHub has anything to do with it. The Pharo Jenkins server
> doesn't use it. That's just where Lukas decided to make his scripts
> available.
>
> https://github.com/renggli/builder/tree/master/scripts
> https://github.com/renggli/builder/blob/master/build.sh
>
> Lukas has a system with two parts: scripts; and, the build.sh shell script.
> There are loads of scripts lying around on the Pharo Jenkins server. They
> are attached and combined dynamically by a ~160 line shell script called
> build.sh. So you'd write something like this:
>
> build.sh -i Omnibrowser -i Greco -i Roman -i Etc
>
> That collects a bunch of scripts. All of them look like the content above:
> string names in an array. build.sh merges these scripts elegantly into one
> single stream. There is no tangible difference between that and having a
> file called tests.st where you cut and paste in the test names as strings.
>
> Is Lukas's system elegant? Yes. Do I want to wade through a ~160 shell
> script to faithfully reproduce that? Let me put it this way: why would
> anybody write a shell script over ~100 lines? Even if it was an init script?
> It seems to me build.sh could have been written in another scripting
> language and been  both shorter and easier to comprehend for the next guy
> who came along. It's not 1983.
> </longer explanation/probably a rant>
>
> Chris
>
>
>
> "I don't think you can do that via the Jenkins web UI. Putting the scripts
> on github like Lukas did makes contributing convenient. Then you can have a
> really simple Jenkins job that just downloads the scripts and runs one."
>
> This is interesting, but I don't think it works that way. If I understand
> what you're saying, build.sh would pull down scripts from Github. I don't
> think that's even possible. Why does Github use SSL?
> To password protect scripts it gives away for free? I don't think so. Only
> humans can download content from Github. Try putting a picture gif on Github
> and then link to it from the webpage you're building. Github uses SSL to
> enforce an interface. They don't want people linking to its resources. Pharo
> Jenkins has all the scripts locally in a directory somewhere. I don't think
> you can clone individual files on demand programmaticlly. I'm willing to be
> wrong, but I feel confident that things are as I just described.
>
>
>
>
>
>
>