Logs truncated every failed build

Every time a build fails, Travis fails to capture the tail end of the output. It typically chops off a dozen or so lines, often making it difficult or impossible to determine the reason for failure. This has been going on for years, although if we go back far enough, it never used to be a problem. Infrastructure changes a long time ago introduced this bug but I never reported it because I assumed something so critical would be fixed in short order. Clearly I was wrong.

When reporting problems, please include relevant build URLs. Thanks.

OK, here’s a failed build.

You are telling the build to exit when the command fails.

https://travis-ci.org/250/Steam-250/builds/637200962#L503

Don’t do that.

If you don’t want the next command upon failure, you can put that command in after_success instead.

That solution doesn’t make sense, because the output is complete before exit is invoked. To be clear, it should not be possible for any script to truncate output that has already been emitted. Whatever is output should be captured by the job exactly as it appeared. Instead, the compete error message is emitted but Travis fails to capture it, whether or not because exit was called after the failure. To put it another way: it is not at all intuitive that exit would delete output already emitted, which is what is happening here.

That’s not an equivalent solution, because any step in after_success cannot fail the build. I want both commands in script to be able to fail the build independently.

Your job is finishing before the buffer is flushed and sent over the ssh connection to the logs.

You’re right about after_success, but ultimately you will need to remove the exit command in order to get what you want.

Sure, that may be what’s happening behind the scenes, but don’t you think that’s a technical issue with your implementation? It simply shouldn’t be possible to lose part of the logs due to user scripting. It shouldn’t be possible for me to prematurely terminate the SSH connection. There should be a wrapper that ensures everything is flushed when the job ends so this problem cannot occur.