https://pantsbuild.org/ logo
a

average-vr-56795

06/01/2020, 11:18 PM
One other thought: a lot of the time the heuristic I really want isn't quite as static as levels... "Show me this if it failed, or took a non-trivial time". That felt like one of the things people found very annoying about v1 logging - logging trivial workunits which spent <100ms no-oping
đź‘Ť 2
w

witty-crayon-22786

06/01/2020, 11:21 PM
nooping is eliminated by pantsd and caching though.
a

average-vr-56795

06/01/2020, 11:22 PM
Eric's example isn't actually no-op, it's "this particular run wasn't interesting, but if it was slow or had anything other than the default expected output it would've been"
đź’Ż 1
w

witty-crayon-22786

06/01/2020, 11:23 PM
do you want to see no output for your test because it took less than 100 ms…?
h

hundreds-father-404

06/01/2020, 11:24 PM
I want output, but only from the underlying tool. I don’t want the noise of Pants adding all this extra information taht’s irrelevant
w

witty-crayon-22786

06/01/2020, 11:25 PM
but how do you identify which tool output corresponds to which target?
needs a header… which is the completing workunit, i think.
h

hundreds-father-404

06/01/2020, 11:27 PM
Yes, I agree it needs a header. What I want is for it to look like 1.29.x. I thought 1.29 had a good balance of noise to signal. Honestly, I don’t think any of the new log statements add value.
And when you’re running a simple case, like just one test or
test --debug
, we should not add any headers or summary. 1.29 does this atm
w

witty-crayon-22786

06/01/2020, 11:28 PM
i mostly agree. but i think that that is addressed by (1)
h

hundreds-father-404

06/01/2020, 11:29 PM
Yeah, (1) certainly would help. But that needs to apply to
Process
too. I don’t think it’s valuable to log when running every single
Process
. The output of the Process is what I care about
w

witty-crayon-22786

06/01/2020, 11:29 PM
with a header to identify what it is, yea.
h

hundreds-father-404

06/01/2020, 11:29 PM
Yes
w

witty-crayon-22786

06/01/2020, 11:29 PM
iff it is info or above.
there are processes that should probably be at debug.
a

average-vr-56795

06/01/2020, 11:30 PM
And even the output… Look at https://travis-ci.com/github/pantsbuild/pants/jobs/341659189 - All of those blocks that say:
Copy code
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-5.3.5, py-1.8.1, pluggy-0.13.1
rootdir: /b/f/w
plugins: cov-2.8.1, icdiff-0.5, timeout-1.3.4
collected 1 item
pants_test/contrib/awslambda/python/test_python_awslambda_integration.py . [100%]
============================== 1 passed in 25.90s ==============================
are noise to me after the run finishes. They would be useful if a test was hanging. But now, they get in the way of me finding the failure.
w

witty-crayon-22786

06/01/2020, 11:31 PM
@average-vr-56795: agreed… implicit in (3) perhaps is that i don’t think we should be rendering stdio for successful runs (ie things not at
warn
/
error
)
a

average-vr-56795

06/01/2020, 11:31 PM
Cool 🙂 I look forward to seeing how it looks!
Oh, and one more while I’m on my soap box… Can we sort the summary at the end by test status, rather than target name?
đź’Ż 1
w

witty-crayon-22786

06/01/2020, 11:32 PM
. @hundreds-father-404: ^ thoughts on that aspect of (3)? i know that you had said that you wanted all tool output regardless
h

hundreds-father-404

06/01/2020, 11:33 PM
I do, but ideally it’s controllable. For example, Pytest may succeed but have deprecation warnings. I want to see those
w

witty-crayon-22786

06/01/2020, 11:34 PM
that should be addressed by (2) i think
so yea. cool.
đź‘Ť 1