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>
>
> <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>

I'd understood Sean to be saying "putting your build system under
version control is a good idea", and it is: it makes for repeatable
builds. Now in an ideal world we'd have some way of saying "take this
base image, run it on that virtual machine, and here's a script
telling you what tests to run". We do the building part very simply,
just by taking what's in the Workspace and sticking it in a git repo.
Jenkins says "check out the repo, and run this file", and suddenly we
need zero Jenkins configuration to change the VM or base image, and we
have tracking of what ran against what, and who made it that way. We
can tackle dependency management another day, maybe by letting Dale
Henrichs solve the problem for us! (See his work with the Travis CI
stuff.)

Otherwise, I'd agree with you that Lukas' build script comes with a
large dose of intimidation: shell scripts suck, and their suckage
increases non-linearly in their length.

frank

> 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.
>
>
>
>
>
>
>