I am not exactly sure how to do it so that the messages are displayed one by one in travis. We simply print the message to stdout when there is a status change. It seems to me that this should be enough (but it isn't). Do you know what we should do to get the messages displayed continuously in Travis?

The code is here: https://pagure.io/copr/copr/blob/master/f/cli/copr_cli/main.py#_135

Any hints welcome!

It is valid behavior that progress bar is not shown in non-interactive
terminal. If you want the progress bar to be shown, please allocate
terminal manually in travis.

It provides no feedback for people who like watching CI builds ;), but the more problematic is fact that Travis kills the builds with no new output during a specific time period (treating them as stalled).

Btw. the upload is usually non-problem (shorter time compared to the build itself).
I have this work-around in my travis job to this problem:
https://github.com/pgjdbc/pgjdbc/blob/master/packaging/rpm/fedora-image/copr-ci-git#L45

@clime Thanks for a link to code. I don't have any immediate suggestion right now.

@praiskup The problem is not a lack of the progress bar, but the fact that there is no output at all and after the copr-cli execution is finished all the lines are printed. I would expect to have is displayed line by line when a given sub-operation is finished.

Thanks for the link with a workaround. It will be an alternative once we hit the timeout on Travis.

@szpak, you mean that all the lines are printed once the srpm is uploaded, or after
the build is finished? Do you have example log in travis? Because the lines like
Uploading package doublecmd-gtk-0.9.0-0.svn7910.fc27.src.rpm should be printed
out line-by-line (newline at EOL), which reader (travis) should read line by line
even if there's no pty.

If the travis job or the wrapping script doesn't have line by line reader (weird) you can
try script or unbuffer tools. But I'm still missing something in this bug report
to judge :-).

@szpak I guess it is because when you do not run it interactively, then stdout buffer is flushed when block is full. And because the output is so tiny, it will only flush when stdout is closed.
So one solution is to fix it on our side, but calling flush() after every print.
But I guess that more correct way is that either you, or travis, should call:
stdbuf -o 0 copr-cli ....
which will use unbuffered stdout.

Agreed with @msuchy, but I doubt that travis is guilty here, though.

@praiskup Here's the sample log:
https://travis-ci.org/szpak/doublecmd-rpm/builds/341248084
(I haven't looked at that exactly execution, but 2 days earlier it displayed twice as weird as I mentioned)

However, I don't see anything strange there. And in addition Travis does not provide timestamps by default. I will use https://github.com/alexcrichton/stamp-rs to get timestamps (which accidentally could "fix" displaying by changing the output mechanism).

@msuchy @praiskup Thanks for a hint with the tools. I will use them and report back with results.

I submitted #224 which could help us with Travis and with integration testing, too.

@praiskup Here's the sample log:
https://travis-ci.org/szpak/doublecmd-rpm/builds/341248084
(I haven't looked at that exactly execution, but 2 days earlier it displayed twice as weird as I mentioned)
However, I don't see anything strange there. And in addition Travis does not provide timestamps by default. I will use https://github.com/alexcrichton/stamp-rs to get timestamps (which accidentally could "fix" displaying by changing the output mechanism).
@msuchy @praiskup Thanks for a hint with the tools. I will use them and report back with results.

Have you found out something more about this problem?

I started using stdbuf with disabled caching which displays message line by line. As there are just a few lines, performance is not a problem.

#224 looks promising as a more comprehensive approach to that issue.

I started using stdbuf with disabled caching which displays message line by line. As there are just a few lines, performance is not a problem.

Well as @msuchy suggested, we could also do sys.stdout.flush() after each print. I suspect that could solve the issue as well but the question is how to reproduce a Travis-like environment? Anyone has an idea?

Flushing on demand solved that kind of problems (also with databases), but usually it provided performance degradation. Probably it will not be noticeable taking into account number of lines that copr-cli usually displays, but it would be good to have it working properly with Travis. I don't know why for most of other tools it just works and for copr-cli not (I would expect that flush after every is not a common practice in general).

Having stdbuf seems to be a good workaround for me (it doesn't provide flush outside Travis), especially having some alternative approach to the problem of long COPR build time, like proposed in #224.

@clime
$ unbuffer copr-cli ...

@clime
$ unbuffer copr-cli ...

No, that does not reproduce the issue. This is simply an alternative to stdbuf.

The issue can simply be reproduced with:

$ copr-cli build clime/myproject git-lfs-2.2.1-1.fc26.src.rpm | cat

Fixed by https://pagure.io/copr/copr/c/57392b1319063cb0a2cc6f4357785ee246d458cd