Build fails with no obvious reason

I had a timeout on “brew update” (no output for 10m) and restarted the build. Now it runs until “rmdir -rf build && cd build” and then fails without any error or other message.

Build job is here: https://travis-ci.com/Return-To-The-Roots/s25client/jobs/165261762

Any ideas what to do?

I may be having the same or at least similar problem since just the other day. In my case, Travis is running the command xcrun simctl list early, then the build just seems to die while the program is outputting the list. This happens when I have language: objective-c in my .travis.yml file.

I’ve been having the same problem for a couple of my projects. I am using “language: generic” on OSX and installing python via miniconda. In one project I’m just changing changing directory (“cd doc”) and there is no output following that command: https://travis-ci.org/ssec/polar2grid/jobs/468178261
In another project, it runs all of my unit tests which finish successfully and then it just stops having output: https://travis-ci.org/pytroll/pyresample/jobs/468456546

However, I’m just realizing now that both commands being executed are probably cd commands and it looks like that’s what you are doing too @Flamefire. If I had to guess the cd is the issue regardless of whether it is by itself or in a chained command (&&). Any ideas why this is failing?

https://travis-ci.com/Return-To-The-Roots/s25client/jobs/165261762#L1135 is setting errexit. If any of the subsequent commands exits with nonzero status, the build will terminate. The primary suspect at this point is https://github.com/Return-To-The-Roots/s25client/blob/4b1a3f9d70c3287e729b3ba05ee65607e590e192/.travis.yml#L143.

Same for you. https://github.com/astropy/ci-helpers/blob/b28d382bafdfdd17954c6885de521a89f26717fc/travis/setup_dependencies_common.sh#L5

https://docs.travis-ci.com/user/common-build-problems/#my-build-fails-unexpectedly

@BanzaiMan Thanks for the info. My tests now pass after I added a set +e to the end of my install section (which is after the source ci-helpers... stuff). I’ll see if I can talk to the ci-helpers folks about changing this. I do think it is weird that in my original polar2grid job (first link I posted) the job stops after cd doc with no further output even though cd doc works fine in the successful build. Maybe it is a lack of the output being flushed to the final log so we never see the breaking make html output.

I don’t think it was cd that failed. Most likely the one after.

Yes, exactly, I agree. But the output inside travis shows “cd doc” as the last command to run then no output after that. Besides output not being flushed before the script exists, I’m wondering why “cd doc” would be the last thing shown (no exit status shown).

@BanzaiMan thanks for the info. But I’m afraid that this was probably recently changed.

Context: It was often requested to stop the build on the first failed command. It simply is not useful (and often even harmful) to execute subsequent commands when one fails (e.g. mkdir fails, but cmake runs afterwards). So the solution until now was to use set -e at the start and set +e at the end of the script to not interfere with the travis stuff running afterwards.

Until now this worked as expected: On any fail the build stops right after the failed command.

What has changed: The failing command and it’s output are no longer shown.

Is this expected? What is the official guideline on handling failing commands in build scripts? Moving the whole code out into a separate shell script would be a possible solution of course.

1 Like

I worked around the problem with the console log before by adding something like a “sleep 10” command which apparently gave enough time for the log to appear in the console. Not a fix but at least it helped me figure out which command failed. I would expect something like this to happen when running commands in the background/asynchronously but not when running commands in the foreground/synchronously.