Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

I’ve got a <https://github.com/pantsbuild/pants/runs/4014342933?check_suite_focus=true#step:13:438|CI test failure here> that I can’t reproduce on Mac OS (Py3.9) or Linux (Py3.7). Any idea how we normally go about debugging something like this?

I'd probably `print(result)` to see if stdout has anything

<@U021C96KUGJ>: CI also rebases to latest `main` before running

so would confirm that you don’t repro when rebased to main

<@U06A03HV1> I verified that I was based against most recent main before running

Stdout was empty:

&gt; `GoalRuleResult(exit_code=0, stdout=‘’, stderr=‘’)`

there’s also that `@logging` decorator for the test

Hrrrm. Once I added the `@logging` decorator, the test failure went away. Caching weirdness?

maybe, but shouldn’t be. the decorator only enables logging, and shouldn’t affect cache keys.

…oh. um. you’re actually rendering to the console, right? not the log?

…you’d have to be to see it in `stdout` i suppose.

I added a `print` statement, which didn’t change the results, but then added `@logging` which changed the results

i meant to ask whether the `coursier-resolve` goal is rendering to the console, rather than the test itself

Ah right, yes, it renders to the console, and the test had been working just fine on other machines.

…oh. but `logging` might affect how the `Console` is mocked…?

i’m fine chasing that down once we have fried other fish.

And now I need to order fish and chips for dinner.