On 26 July 2012 15:17, Chris Cunnington smalltalktelevision@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.