Open marceltaeumel opened 6 years ago
Metacello has the ability to unconditionally fail in the face of a GoferRepositoryError (see MetacelloCommonMCSpecLoader class>>retryPackageResolution and MetacelloCommonMCSpecLoader class>>retryPackageResolution:) but I'm not sure if you can arrange to set that for a Travis run --- it can be challenging to debug issues remotely via Travis.
The best bet for figuring out what is going on is to reproduce this in an interactive environment with retryPackageResolution set to false ... then a debugger can be used to quickly get to the heart of the problem ...
It should be possible to run SmalltalkCI interactively, but the type of failure you are describing should happen during regular Metacello loads, do you see these failures running local loads?
No, it always loads w/o debuggers locally once SqueakSSL is up an running. 😄
Am 26. Februar 2018 17:27:25 MEZ schrieb Marcel Taeumel notifications@github.com:
No, it always loads w/o debuggers locally once SqueakSSL is up an running. 😄
;P -- Sent from mobile device
Hmm, that complicates things ... I don't think there is a way to customize the version of Metacello that is used by SmalltalkCI ... short of creating a clone of SmalltalkCI that uses a custom Metacello version, In the past I've debugged these problems by dumping stacks or logging additional information to the transcript.
In this case we need to start by dumping a stack in MetacelloCommonMCSpecLoader>>retryingResolvePackageSpecReferences:gofer: and then work backwards with logging as we learn more about what is going wrong ...
Alternatively, if we can figure out the code involved in the bogus ByteArray creation, we could possibly work forward and understand the issue from that direction --- putting in some logging that is only triggered on errors or at least code that could be safely put into the master branch of Metacello ...
It just occurred to m e that I may have seen a similar issue elsewhere: Error when loading from github (failed only on gemstone) ... If you work your way down the thread there's a bug in ZipArchive when used with large zip files ... of course the error is not quite the same and in Mariano's case it was not intermittent ...but it may be related somehow...
@dalehenrich you can run a custom script before loading a project and do whatever you want with the image, e.g. patch Metacello methods. Apart from that, there's only #useLatestMetacello
because that seems like a common request. Not sure if we really need to support loading of a specific Metacello version for debugging purposes in smalltalkCI?
Maybe you could provide a changeset that adds additional logging, so Marcel can file that in before Vivide is loaded.
I'm not sure if this is the reason for the error, but the VMs smalltalkCI uses for Squeak are quite old, because there are still some problems with SqueakSSL. I hope we can update them soon...
Perhaps the root cause is actually the old vms being used by SmalltalkCI? What do you think @krono? if I is likely to be a Metacello issue then we'll need to go into debug mode...
Old VMs is very likely. @fniephaus lets wait for a OpenSmalltalk VM release?
Ok then, let's wait for the release and I will give those new VMs a try...fingers crossed
Here are all variations of this behavior:
Could not resolve: BaselineOfAnimations [BaselineOfAnimations] in /home/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/animations:master/repository ERROR: 'GoferRepositoryError: can''t find EOCD position'
Could not resolve: BaselineOfWidgets [BaselineOfWidgets] in /home/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/widgets:master/repository ERROR: 'GoferRepositoryError: '
Could not resolve: BaselineOfSignals [BaselineOfSignals] in /Users/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/signals:master/repository ERROR: 'GoferRepositoryError: ByteString called #basicNew: with invalid argument -236'
...maybe just a socket problem after all? Broken ZIP download and hence "EOCD" and negative byte string sizes...
The project Vivide experiences sporadic issues on TravisCI via SmalltalkCI while loading the dependencies (including this and that).
It is always some (other) repository that cannot be fetched. Manual retries will eventually solve the problem, and the build will pass. I get the following hint in Travis' output:
I suspect that some HTTP request might not behave as expected and somewhere in the requestor (VM, Plugin, Squeak's sockets, Squeak's unzip mechanism, Gofer, Metacello, ...) the issue occurs and propagates up to Gofer.
I think that a more elaborate error log in Gofer can give us more clues here. Not sure how to enable such a thing. :-)
Best, Marcel