Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide dedicated control over truncation of "short test summary info" lines #10264

Open
yarikoptic opened this issue Sep 1, 2022 · 7 comments
Labels
topic: reporting related to terminal output and user-facing messages and errors type: enhancement new feature or API change, should be merged into features branch

Comments

@yarikoptic
Copy link

What's the problem this feature will solve?

Currently we cannot easily grasp the summary of underlying fails/errors which happened on CIs (logs archived using https://github.com/con/tinuous/) because "short test summary info" truncates to the width of the terminal which is in non-interactive session happens to be around 80. So we get just e.g.

(git)smaug:/mnt/datasets/datalad/ci/logs/2022/08[master]git
$> git grep  '^FAIL.*test_gracefull_dea'                               
03/pr/6915/964b1f4/travis-14378-failed/2.txt:FAILED ../datalad/support/tests/test_parallel.py::test_gracefull_death - asse...
03/pr/6915/964b1f4/travis-14378-failed/4.txt:FAILED ../support/tests/test_parallel.py::test_gracefull_death - assert 0 >= 2
23/pr/6958/fa7cee0/travis-14469-failed/9.txt:FAILED ../datalad/support/tests/test_parallel.py::test_gracefull_death - asse...
29/pr/6981/2551844/travis-14510-failed/3.txt:FAILED ../support/tests/test_parallel.py::test_gracefull_death - assert [0, 2...
30/push/maint/870c72a/travis-14519-failed/9.txt:FAILED ../datalad/support/tests/test_parallel.py::test_gracefull_death - asse...

The only workaround I found is to specify explicitly COLUMNS env var to be of some higher value on CI, but that would make the entire log wider, so wider section headers etc.

Ideally I wish there was some pytest setting which would take and not truncate the first line (i.e. split by \n) of that line to be displayed so in the captured logs we have it in its entirety.

@nicoddemus
Copy link
Member

Perhaps it makes sense for us to detect we are running on CI and not truncate at all? I recall we already do something similar to truncate tracebacks...

@nicoddemus nicoddemus added topic: reporting related to terminal output and user-facing messages and errors type: enhancement new feature or API change, should be merged into features branch labels Sep 1, 2022
@yarikoptic
Copy link
Author

not sure if worth "on CI" -- the same effect is observed when stdout is not a terminal, i.e. if gets piped to | cat.

@nicoddemus
Copy link
Member

Fair enough.

@david1542
Copy link

Can you provide a reproducible example? I'd like to take a stab at this :)

@yarikoptic
Copy link
Author

yarikoptic commented Oct 21, 2022

#!/bin/bash
set -x

cd "$(mktemp -d ${TMPDIR:-/tmp}/pytest-XXXXXXX)"

cat >| test_some_path_could_be_long.py <<EOF
def test_short_fail():
    assert False 
def test_veryyyyyyyyy_long_test_name_just_because_no_long_path():
    assert False  # which could be long line too
EOF

python3 -m pytest test_some_path_could_be_long.py 
python3 -m pytest test_some_path_could_be_long.py | cat 

would end with

FAILED test_some_path_could_be_long.py::test_short_fail - assert False
FAILED test_some_path_could_be_long.py::test_veryyyyyyyyy_long_test_name_just_because_no_long_path

so no the assert False like in previous output without | cat

@yarikoptic
Copy link
Author

ping on this

@tunstek
Copy link

tunstek commented Aug 14, 2023

Could we have a flag that just stops the truncation of the summary? I would personally just use that in general, even outside of CI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: reporting related to terminal output and user-facing messages and errors type: enhancement new feature or API change, should be merged into features branch
Projects
None yet
Development

No branches or pull requests

4 participants