dalehenrich / builderci Goto Github PK

See travis issue 1075 for details...

The end of a Travis log:

69$ ./build.sh -i $ST -m -f "$PROJECT_HOME/travisCI.st" -o travisCI
70PROCESSING OPTIONS
71BUILDING IMAGE FILE
72RUNNING TESTS...
73./build.sh: line 187: /home/travis/dalehenrich-builderCI-519eb7d/oneclick/Contents/Linux/squeak: No such file or directory
74$ cd "${BUILD_PATH}/travisCI/"
75$ $BUILDER_CI_HOME/buildImageErrorCheck.sh
76$ $BUILDER_CI_HOME/buildTravisStatusCheck.sh
77
78Done. Build script exited with: 0

...and Travis says the test passed. It would be better if failure of the script caused Travis to say "failed".

travis has started truncating large log files and the summary of test results is lost ... need to dump the summary first (and last) to compensate...

Getting this error in stone log when running GemStone/S on travis using the standard free licenses ... presumably this is a side effect of the fact that travis runs it's linux vms on large multi-core boxes ... anyway I was able to use the maglev license for GemStone 3.1.x ... need to figure out how to get the other versions of gemstone running on travis

From the following error:

• https://travis-ci.org/glassdb/Seaside30/jobs/16428079#L463

I'm deducing that we need to do a ConfigurationOfGLASS project updateProject to ensure that the config is downloaded from an http repository ... For 3.10.4 and beyond, GLASS 1.0-beta.9 is pre-installed and the #updateProject is skipped ... thus causing the get command to fail...

Hypothesis at this moment...

needed for Metacello...

... implies supporting old vm

needed to support FileTree and Metacello

Have to disable Squeak4.5, until this is fixed...

73+ wget -q 'http://www.squeakci.org/job/SqueakTrunk/lastSuccessfulBuild/artifact/target/*zip*/target.zip'
74+ unzip target.zip
75Archive:  target.zip
76  End-of-central-directory signature not found.  Either this file is not
77  a zipfile, or it constitutes one disk of a multi-part archive.  In the
78  latter case the central directory and zipfile comment will be found on
79  the last disk(s) of this archive.
80unzip:  cannot find zipfile directory in one of target.zip or
81        target.zip.zip, and cannot find target.zip.ZIP, period.

Sometime in the not so distant past (like this morning:), GitHub changed the form of the zip download urls from: https://github.com/dalehenrich/builderCI/zipball/master to: https://github.com/dalehenrich/builderCI/archive/master.zip ... or stopped supporting https://github.com/dalehenrich/builderCI/zipball/master ... anyway the new form appears to work.

Change all of the places this is used accordingly...

Ran into a problem where Squeak image hangs until travis kills it. Guessing that interactive window is popping up or even the debugger possibly to cause the hang ...

@frankshearar suggests installing this class to help in debugging headless vms ... at least until a better alternative becomes available in the base image.

Downloads from ftp.gemstone.com appear to be throttled for travis. GemTalk Systems does not control the ftp.gemstone.com site.

We've moved the download files for some of the older versions of GemStone used in travis to ftp.gemtalksystems.com so the install script need to be changed ...

consider including metacello as part of before.st ... then the scripts can be written in terms of the Metacello scripting api from the get go ... submodules again a good bet, I think, since the nesting is not deep

Pharo3.0 directly accesses libSSL1.0.0 instead of a symbolic link for libSSL (AFAICT) so have to upgrade libSSL library .... hopefully I won't end up having to upgrade toi 1.0.1 at some point in future, and break Pharo3.0 again:(

the template travis.yml needs to be fixed (correct path to script) and the script itself must be adjust so that it finds the correct .st file

before.st explicitly loads OSProcess ... probably not necessary anymore

on one level the fact that everything loads correctly is enough of a test (as it is now) but it I suppose as I move forward I will find things that need to be tested/verified ...

Needed to be able to test metacello-work 1.0-beta.31.1.5 branches ....

Compile error encounered ina run script can confound the best intentions of builderCI.

When the build.sh script exits with an error, I think we just exit completely without correctly checking for various output files ... I thought we had that scenario covered, but perhaps not ...

At least the case above normal error handling and logging was side-stepped

To do proper testing of GCI-based applications for GemStone, we need to start GemStone (a stone without any topaz gems), start a netldi process , then start a client Smalltalk (pharo or squeak) and launch tests that will connect to GemStone and excercise GCI-based operations.

run tests for all subclasses of TestCase ...

build 80 failed....

should split out Metacello-Base and file it directly into image (pharo or squeak) and then just resolve the boots trap issues from there and use Metacello scripting api from the get go...

Pharo-2.0 is always loading the latest build, so there may be issues introduced by the build instead of by your code, so it will be interesting to know the build #

Request from Serge Need to make sure that Metacello works there, too...

pull in filetree and install as part of before.st .... consider including as a submodule

Some tests may require access to older commits in the git repository. For those test cases a different clone depth is needed... Make it an option rather than force all projects to clone more than they need ...

It obscures the important output.

Hi Dale,

after merging #62, I've updated our fork to the latest version.
Unfortunately, some projects which use our fork for testing now pass [1], even though they failed before [2].

MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
[] in MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:
[] in MetacelloSqueakPlatform>>do:displaying:
[] in [] in MorphicUIManager>>displayProgress:at:from:to:during:
BlockClosure>>on:do:
[] in MorphicUIManager>>displayProgress:at:from:to:during:
BlockClosure>>ensure:
MorphicUIManager>>displayProgress:at:from:to:during:
ProgressInitiationException>>defaultResumeValue
ProgressInitiationException(Exception)>>resume
ProgressInitiationException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
ProgressInitiationException(Exception)>>signal
ProgressInitiationException>>display:at:from:to:during:
ProgressInitiationException class>>display:at:from:to:during:
ByteString(String)>>displayProgressAt:from:to:during:
MetacelloSqueakPlatform>>do:displaying:
MetacelloFetchingMCSpecLoader>>linearLoadPackageSpec:gofer:VM exit status: 0 
neither SUCCESS nor FAILURE: buildTravisStatusCheck.sh

Projects which passed before still look ok [3].
Does this error message make any sense to you?

[1] https://travis-ci.org/fniephaus/SWTI2014-Project-08/builds/26284558
[2] https://travis-ci.org/SWTI2014/SWTI2014-Project-08/jobs/26213503
[3] https://travis-ci.org/fniephaus/SwtDemo/jobs/26283885

We now need an ST=Squeak-4.5 option

Transcript outputs are redirected to be visible during the TravisCI build and test process. That's great! :)

Could it be possible that no other code is allowed to add new dependents to the Transcript stream? I have a test in my Signals project that produces an error only with your scripted platform.

Known issue? Any way here's the error

See http://forum.world.st/Glass-Happy-Fathers-Day-yeah-right-td4763228.html for more details

It is difficult to do development in the bootstrapping area because in development you may want to use a specific version of ConfigurationOfPreview (the last step in bootstrapping, that loads the latest released version of the Preview) BEFORE releasing it into production ... in the past I've gotten to the point where it was close enough and then just opened a window for error ... with the Pharo2.0 port I am in a situation where I can't run tests to validate the Preview release without booting from the released Metacello-Base which means I can't test the Preview version...

I have to find a way of bootstrapping without loading on top of Metacello-Base ... perhaps it's just as simple as not reloading Metacello-Base when bootstrapping ...

I think so ...

At the moment we need to fail if there are test failures and print a summary of the failed tests ...

A script in the form of:

TestCase debug: #failedTest

would be most convenient for a copy and paste operation ...

Summary line, then list of failed tests ...

Since 4.5's now fully released, and trunk development's now working on what will become 4.6, it seems like a good time to add support for 4.6.

See http://groups.google.com/group/metacello/msg/1ffea81e5211939e for details ...

need to get Metacello scripting api working there first

@frankshearar it looks like we're doing better build results, but the only pass was for Pharo1.4 not sure why the other platforms flaked out som badly

The detection of which tests to execute seems to fetch too many tests---even some of dependent projects.

should make it possible to run tests against GemStone 2.x and GemStone 3.x ...

the metacello-work has conditional listing of the PharoDebug.log ... need to incorporate into build.sh

Segmentation fault appears to be a new failure since moving to 64bit vm ... important to note that second section of builerCI tests is passing ....

3 of the jobs run for this test sequence were killed by travix with the following message:

111PROCESSING OPTIONS
112BUILDING IMAGE FILE
113Linux testing-bluebox-linux-3-8728-linux-1 2.6.32-042stab061.2 #1 SMP Fri Aug 24 09:07:21 MSK 2012 x86_64 x86_64 x86_64 GNU/Linux
114RUNNING TESTS...
115
116
117No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
118
119The build has been terminated

The other runs came close to hitting 10 minutes and were allowed to continue ... the way we run the vm nothing gets written to standard out until the job finishes so any test/build sequence that runs for ten minutes in the vm will be killed by travis ...

I think I need to add some progress indicators to prevent travis from killing the job prematurely ... run the risk of infinite hangs, but as it stands now it looks like half of my jobs get killed for no legitimate reason ... I HATE TIMEOUTS:)

Zeroconf for Pharo has a get script for travis:

curl get.pharo.org/travis+vm | bash

will have to somehow update config for Metacello to reflect this problem, but that will come later ...

we have ensure that 32 bit libs are installed before trying to run again ... @martinmcclure is looking into this puppy for mist...

build 78 ... squeak failed

@frankshearar Installer class>>isThisEverCalled: which has a #halt in it is called instead of throwing a messageNotUnderStood: exception as expected by Metacello means that (Metacello can't be loaded)[https://travis-ci.org/dalehenrich/builderCI/jobs/14078795#L112]...

@demarey, from the following lines in a recent metacello-work build:

+ IMAGE_BASE_NAME=Pharo-2.0
+ IMAGE_TARGET_NAME=Pharo-2.0
+ case "$ST" in
+ cd /home/travis/dalehenrich-builderCI-fc2d52b/images
+ wget -q https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo-2.0.zip
+ unzip Pharo-2.0.zip
unzip:  cannot find or open Pharo-2.0.zip, Pharo-2.0.zip.zip or Pharo-2.0.zip.ZIP.
+ cd Pharo-2.0

It looks like the fancy script wget --quiet -O - get.pharo.org/20+vm | bash hasn't been updated to use the (apparently) new ci paths for Pharo2.0?

The following path works, but doesn't download the vm:

https://ci.inria.fr/pharo/view/2.0/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo.zip

I will need further guidance from you on this one ...

Getting closer to getting Metacello Preview to run with Pharo-2.0, but without being able to download Pharo-2.0 anymore, I'm not sure. I am getting Pharo-1.4 test errors loading the new configuration, which I have to characterize... presumably I haven't quite got the ConfigurationOfMetacello updated correctly...