Confusing silent failure under CI when baseline depends on non-existent project

[cdlm]

I pushed a baseline with a new dependency to a project that hadn't yet been created on GitHub.

What happened: the CI build on Travis timed out with no helpful information in the log; it only mentions retrying with HTTPS because SSH failed.

What I expected: an explicit message, clearly mentioning which dependency couldn't be fetched, and giving the root cause (non-existing project, instead of wrong/misconfigured protocol).

[dalehenrich]

Point taken ... I think that the swallowing errors dates back to the time when there multiple repositories that would be retried in the case one failed (back when squeaksource was unstable/slow and there were a number of mirror sites that sprang up ...)...

I think this will be a good bug to fix when I find myself rotating back through Metacello ...

[dalehenrich]

BTW, I don't see the pattern of log entries that I would expect when it is the type of error Metacello can do something about ... the timeout is a travis timeout, so we really don't have any good indication of what is going on ... Metacello itself does not use a timeout, so if a server allows a connection but then hangs, Metacello will hang and there won't be much that can be done ..

[cdlm]

The problem could be in a lower layer like libgit or iceberg, then? I'm assuming that at one poing the server says something like "I have no clue about that repo you're trying to access" and that is either ignored, or treated as the wrong kind of problem… could a debugger pop up and prevent the metacello process from progressing?

[dalehenrich]

I don't recognize this log message:

3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git). I will try to clone the HTTPS variant.

... so iceberg could be a culprit ... in gemstone I use curl or wget and they tend to fail when the url was bogus ...