[Glass] Seaside Smalltalk-CI build for Gemstone runs out of temp object space
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Tue Mar 29 07:04:05 PDT 2016
On 3/29/16 12:24 AM, Johan Brichau via Glass wrote:
>> On 28 Mar 2016, at 21:32, Dale Henrichs via Glass
>> <glass at lists.gemtalksystems.com
>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>> Do you think this would work for you? Any other ideas?
> Sounds good.
> Perhaps: having generic hooks for before and after scripts would make
> sense as well. There will always be things that are specific to a
> project that need to be configured somehow.
> But perhaps that’s out of the scope of Smalltalk-CI and is possible
> via other Travis options. I have not investigated that yet.
SmalltalkCI _is_ the travis environment, so we are able to define
anything we want, but we have to create it ...
For GemStone, SmalltalkCI is built on top of GsDevKit_home. Once
GsDevKit_home is installed, the stone is created. Then the project is
loaded and tests launched bases on the specification in the
I am working with Fabio to arrange to pass in gemstone-specific
arguments from the run.sh command line. Command line options can be
set from within .travis.ym;, but my thoughts on run.sh arguments is
that we want to use them for local control of smalltalkCI - things like
"create stone named X in an existing GsDevKit_home clone" .
The load and launching of tests is driven by the .smalltalk.ston file
and the classes are implemented here. The .smalltalk.ston specs are
mostly shared across Smalltalk dialects, but we can add fields and
classes that are specific to GemStone ... My inclination for the
.smalltalk,ston file is that things should be included there that apply
equally to local and travis runs.
It is possible that to support certain features in SmalltalkCi we will
have to make changes to GsDevKit_home, but I think that is cool ... like
I said, I think I will probably be adding (local) batch test running
support GsDevKit_home so that it becomes simple to run local tests to
reproduce errors seen on travis or to simply run local tests in batch
mode without involving travis ...
Changing the TOC means that we have to arrange for a gem.conf to be
used, since tODE is not currently being run from a topaz command line
... GsDevKit_home and that means putting a gem.conf into the stone
directory (where the GsDevKit_home GEMSTONE_EXE_CONF points). We can
arrange to do this in gemstone/run.sh base on .smalltalk.ston settings -
and TOC changes are something that would be needed both locally and on
Setting time zones for the stone is also something that can be done base
on .smalltalk.ston settings, but in this case one needs to login as
system user to make the changes ... this is something that is
straigtforward for trais, but gets a bit dicey for local systems:
- how do we get the system password, as I haven't cracked this nut
quite net for GsDevKit_home
But this shouldn't stop us from adding the feature to .smalltalk.ston,
because it _is_ a useful feature ...
This brings us to Travis/SmalltalkCI environment variables ... very
useful for setting up test matrices we _could_ use env vars AND
gemstone/run/sh command line options making it easy to create test
matrices for travis runs and perhaps parse the .travis.yml file for the
local GsDevKit_home test driver --- although I don't know of Smalltalk
port of YAML and I don't think it is trivial?
Sooo we have a lot of different options these are just my thoughts on
things and I welcome additional feedback and ideas ... nothing is set in
stone at this point:)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glass