Make smalltalkCI compatible to GemStone

[dalehenrich]

Fix for Issue #48 ... SmalltalkCI ported to GemStone:

• includes a fix for Issue TestFailure: Block raised NotFound: Object is not in the collection #49
• .st files converted from CR to LF
• the GemStone SmalltalkCI code is stored in a filetree repository and there is no reason why Pharo and Squeak don't share the code here - after all the tests are all shared in filetree... I've made several bug fixes beyond Issue TestFailure: Block raised NotFound: Object is not in the collection #49, but there is no practical way for me to share those fixes other than through sharing the code itself. @estebanlm, if you want to share code for SmalltalkCI vi filetree, we can find a better location for the code repository and share it ...
• significant refactoring of the SmalltalkCI tests so that it's one test case per spec combo
• ported SCITestReport to GemStone to produce the proper xml result file
• added #projects test type, that takes list of Metacello project names ... this code should be able to run in any dialect with Metacello installed
• add a #'*' test type that causes all subclasses of TestCase to be added to the classes list. the #include and #exclude lists are used ... updated README
• add #onWarning to load spec, so that Warnings get logged to Transcript without having to add explicit handler
• added a number of GsDevKit/tODE artifacts in support of SmalltalkCI, including a runSmalltalkCI script that runs a SmalltalkCI spec against a given stone ...
• changed top-level .gitignore to exclude the common editor data files
• @estebanlm, when a project is specified, the #packages entry is ignored in Pharo, but I think that the #packages and new #projects entry should behave the same as #classes and #categories, in that they add a list of tests to the list of classes in addition to the classes in the loaded project. I've added a test to illustrate differences between GemStone and Pharo)

[fniephaus]

That's fine!

[dalehenrich]

Okay the OS X hostnames are not set correctly:

Are the host names set up correctly for GemStone?
Traviss-Mac-441.local
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1   localhost 
255.255.255.255 broadcasthost
::1             localhost  
fe80::1%lo0 localhost
Well?
clone_gsdevkit

The result of hostname is Traviss-Mac-441.local and Traviss-Mac-441.local does not show up in /etc/hosts....

[fniephaus]

Ok, I can get that fixed. There's no way GemStone could just use localhost?

[dalehenrich]

we call hostname to find out the name of the host ... the code that is involved creates a file that uses the hostname to access a remote host, so wiring in localhost is not really an option - travis-ci is not the primary application here :)

[dalehenrich]

By jove, I think we've got it!

[dalehenrich]

Oops, celebrated too soon ... looks like Issue #65 can failpass for the wrong reason ... I moved the GemStone directory into _build and if your intent is to run a different set of tests it is overkill to delete the whole build ... in this particular case I think that I can fix the problem that caused the failurepass, but as I said, it seems to be expensive to delete the whole thing ... there is a less expensive alternative that could be used for GemStone -- restore from a backup taken before loading the SmalltalkCI tests ...

[dalehenrich]

on second thought rebuilding for Issue #65 is not so bad, however a false positive is not good ...

[dalehenrich]

It also looks like my workaround for Issue #65 is working, so I imagine that we can go ahead an pull trigger on the merge!

[dalehenrich]

ah, my good friend API rate limit ... I will probably go after the API rate limit problem with a vengeance now :) ... not able to work on this most of today though...

[fniephaus]

I will just restart them later then ;)

[fniephaus]

Are you online somewhere, @dalehenrich?