[Glass] Seaside Smalltalk-CI build for Gemstone runs out of temp object space

Tue Mar 29 11:38:43 PDT 2016

Some general thoughts:

  - for each of the configuration options there should be a 
corresponding environment variable (SmalltalkCI_GS_<config-name> 
perhaps) that can be set in the .travis.yml file and/or used to drive 
test matrices. An env var overrides the value specified in the .ston file.
- for each of the environment variables, there should be a corresponding 
--gs-<env-var-name> option defined for run.sh. The command line setting 
overrides env vars and .ston file values

Also, I'm inclined to try to add features on demand ... there are quite 
a few options for controlling the whole system and within the above 
framework, I think we can get things implemented ...

Unless I hear from others, I'm will start work going down this path in 
the next day or so (working with Fabio on details of the spec and 
command line args)  implementing the following .ston cofiguration options:

SmalltalkCISpec {
   #configuration:
     SCISystemConfiguration {
       #gemConfPath : 'tests/gemstone/gem.conf',
       #timeZone : 'Europe/Prague',
       #platforms : [ #gemstone ]    },
   #loading : ['...']
}

with corresponding env vars:

   SMALLTALK_CI_GS_GEM_CONF_PATH
   SMALLTALK_CI_GS_TIMEZONE

and run.sh options:

   --gs-GEM_CONF_PATH
   --gs-TIMEZONE

Dale

On 03/29/2016 07:04 AM, Dale Henrichs wrote:
>
>
> 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[1]. Then the project 
> is loaded and tests launched bases on the specification in the 
> .smalltalk.ston file[2].
>
> I am working with Fabio to arrange to pass in gemstone-specific 
> arguments from the run.sh command line[3]. Command line options can be 
> set from within .travis.ym;[4], 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[5]. 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 travis.
>
> 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:)
>
> Dale
>
> [1] 
> https://github.com/hpi-swa/smalltalkCI/blob/master/gemstone/run.sh#L111-L127
> [2] 
> https://github.com/hpi-swa/smalltalkCI/blob/master/gemstone/run.sh#L150-L157
> [3] 
> https://github.com/hpi-swa/smalltalkCI/commit/bc072cce2ca7b1657d5b320bc07faa04360af4da#diff-1b0c2b516b83393edb7200ad5ff12181L139
> [4] https://github.com/dalehenrich/obex/blob/master/.travis.yml#L10-L11
> [5] https://github.com/hpi-swa/smalltalkCI/tree/master/repository

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160329/47aac186/attachment.html>