# Use \`travis\_wait\` but still see the output

**URL:** <https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647>\
**Category:** Travis CI Discussions & Feedback\
**Tags:** build-env\
**Created:** [October 23, 2019, 5:26pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647 "2019-10-23T17:26:57Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkhansen](https://avatars.discourse-cdn.com/v4/letter/m/65b543/32.png) [@mkhansen](https://travis-ci.community/u/mkhansen)\
**Post date:** [October 23, 2019, 5:26pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/1 "2019-10-23T17:26:57Z")

</div>

I have a CI failure because I’m building a docker image inside of Travis, and within that build, there is a package being built that has a lot of plugins / libraries. That build takes more than 10 minutes and doesn’t output anything. See here:  
[https://travis-ci.org/ros-planning/navigation2/builds/601413527](https://travis-ci.org/ros-planning/navigation2/builds/601413527)

This is the error:

```auto
Starting >>> gazebo_plugins

2148

2149

2150 No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

2151 Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

2152

2153 The build has been terminated

```

I’ve tried looking for solutions, the only thing I found was adding a `travis_wait` to the beginning of the build. But now I don’t see the output of the build, just the `travis_wait` messages:

```auto
travis_time:start:210720f0
e[0K$ travis_wait 45 docker build --tag navigation2:latest --build-arg PULLREQ=$TRAVIS_PULL_REQUEST --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./

Still running (1 of 45): docker build --tag navigation2:latest --build-arg PULLREQ=1268 --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./
Still running (2 of 45): docker build --tag navigation2:latest --build-arg PULLREQ=1268 --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./
Still running (3 of 45): docker build --tag navigation2:latest --build-arg PULLREQ=1268 --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./
Still running (4 of 45): docker build --tag navigation2:latest --build-arg PULLREQ=1268 --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./
Still running (5 of 45): docker build --tag navigation2:latest --build-arg PULLREQ=1268 --build-arg CMAKE_BUILD_TYPE --build-arg COVERAGE_ENABLED ./

```

Is there any way to run a `travis_wait` but still see the output of the command in the console? Otherwise, is there any better solution for this?

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [October 24, 2019, 12:05am UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/2 "2019-10-24T00:05:14Z")

</div>

> [@mkhansen](#):
>
> That build takes more than 10 minutes and doesn’t output anything.

Consider making that build report on its progress. Not outputting anything is awful UX because you can’t tell if anything’s happening or it’s stuck (which is bad because if it’s stuck, you are wasting your time waiting for it; and you also have no idea where exactly it’s stuck to be able to fix that). Travis’ auto termination is there specifically to kill stuck commands – for our mutual benefit, as per above.

> [@mkhansen](#):
>
> Is there any way to run a `travis_wait` but still see the output of the command in the console? Otherwise, is there any better solution for this?

There is no supported way. `travis_wait` saves output to a log file and prints it all at the end. You may try `tail -F "travis_wait_${$}.log" &` (make sure to save the job’s PID to `kill` it at the end) but this is not a supported way (thus may break in the future) and will get you a duplicate of the output at the end.

You may consider `start_spinner`/`stop_spinner` from [https://github.com/matthew-brett/multibuild/blob/master/common\_utils.sh](https://github.com/matthew-brett/multibuild/blob/master/common_utils.sh) as an alternative.

---

<div class="post-metadata">

**Author:** ![mkhansen](https://avatars.discourse-cdn.com/v4/letter/m/65b543/32.png) [@mkhansen](https://travis-ci.community/u/mkhansen)\
**Post date:** [October 24, 2019, 3:11pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/3 "2019-10-24T15:11:25Z")

</div>

> [@native-api](#):
>
> Consider making that build report on its progress

Actually, the build tool (colcon) does report on the progress every 30 seconds when I run it on my system, and even when I build the docker image locally. For some reason it seems to be buffered in the Travis run however, and that is why it times out. Is there a way to fix the buffering?

> [@native-api](#):
>
> `travis_wait` saves output to a log file and prints it all at the end.

I wasn’t aware of that, and it may meet my needs. I tested this yesterday and I do see the output, so unless there’s a way of making sure the output is printed immediately (non-buffered), this may be the solution.

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [October 24, 2019, 4:32pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/4 "2019-10-24T16:32:36Z")

</div>

> [@mkhansen](#):
>
> Actually, the build tool (colcon) does report on the progress every 30 seconds when I run it on my system, and even when I build the docker image locally. For some reason it seems to be buffered in the Travis run however

This must be because it detects that stdout is not a terminal – because you are using secret variables.

---

<div class="post-metadata">

**Author:** ![mkhansen](https://avatars.discourse-cdn.com/v4/letter/m/65b543/32.png) [@mkhansen](https://travis-ci.community/u/mkhansen)\
**Post date:** [October 24, 2019, 8:08pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/5 "2019-10-24T20:08:03Z")

</div>

OK, we were able to resolve this another way without the travis\_wait.

I think this is resolved now, thanks for your help!

---

<div class="post-metadata">

**Author:** ![mbrandizi](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/mbrandizi/32/3692_2.png) [@mbrandizi](https://travis-ci.community/u/mbrandizi)\
**Post date:** [January 22, 2020, 10:18pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/6 "2020-01-22T22:18:44Z")

</div>

_There is no supported way. `travis_wait` saves output to a log file and prints it all at the end. You may try `tail -F "travis_wait_${$}.log" &` (make sure to save the job’s PID to `kill` it at the end) but this is not a supported way (thus may break in the future) and will get you a duplicate of the output at the end._

I’ve just discovered this `travis_wait` from the documentation. If it can’t output the executed command while running, then it isn’t very useful, due to what you wrote about how bad UX is not yielding any output for long time. I can’t get why it cannot be changed to work in a useful way. To me, it’s just about not hijacking the stdout of the executed command and adding some keepalive message from time to time.

---

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [January 23, 2020, 3:18am UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/7 "2020-01-23T03:18:08Z")

</div>

> [@mbrandizi](#):
>
> If it can’t output the executed command while running, then it isn’t very useful, due to what you wrote about how bad UX is not yielding any output for long time.

I guess the idea was to avoid mixing up the output proper with spinner messages.

---

<div class="post-metadata">

**Author:** ![mbrandizi](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/mbrandizi/32/3692_2.png) [@mbrandizi](https://travis-ci.community/u/mbrandizi)\
**Post date:** [January 23, 2020, 12:10pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/8 "2020-01-23T12:10:59Z")

</div>

> [@native-api](#):
>
> I guess the idea was to avoid mixing up the output proper with spinner messages.

I can’t use it that way. I’m rather thinking of running a background process of my own, which yields a message from time to time, stopping completely after some time (or when the main process kills it).

---

<div class="post-metadata">

**Author:** ![BanzaiMan](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/banzaiman/32/67_2.png) [@BanzaiMan](https://travis-ci.community/u/BanzaiMan)\
**Post date:** [January 23, 2020, 1:05pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/9 "2020-01-23T13:05:47Z")

</div>

You are welcome to devise your own way to meet your needs, or suggest improvements to `travis_wait`. This, and all the related code can be found in [https://github.com/travis-ci/travis-build/tree/master/lib/travis/build/bash](https://github.com/travis-ci/travis-build/tree/master/lib/travis/build/bash).

---

<div class="post-metadata">

**Author:** ![mbrandizi](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/mbrandizi/32/3692_2.png) [@mbrandizi](https://travis-ci.community/u/mbrandizi)\
**Post date:** [January 23, 2020, 1:32pm UTC](https://travis-ci.community/t/use-travis-wait-but-still-see-the-output/5647/10 "2020-01-23T13:32:45Z")

</div>

> [@BanzaiMan](#):
>
> You are welcome to devise your own way to meet your needs, or suggest improvements to `travis_wait` .

I was about to file an issue about it, but [Travis people don’t seem interested in changing](https://github.com/travis-ci/travis-ci/issues/7323) such silly behaviour. Besides, I’ve just discovered the [alternative travis-pls](https://github.com/naftulikay/travis-pls), I’ll try that.
