2) we seem to be running into <https://github.com/...
# general
a
2) we seem to be running into https://github.com/pantsbuild/pants/issues/6861 a bit lately too. Are there any updates on how to deal with that? We've just been rerunning the thing.
h
Oof, I personally wasn’t aware this is hitting actual users. Others might have already known though. I don’t think we have a solution yet, and the best workaround for now is to re-run the command as you’re doing. Please comment on that issue noting that this is hitting you all. It would be helpful to mention things like how frequently it’s been happening, if you noticed it happening more recently than before, if certain commands seem more problematic, etc. Thanks!
a
Yes please we’ve seen that sparingly in our CI but it will take a higher priority if you’re seeing it too — as detailed info about the repro as possible would be very helpful.
👍 1
a
Yeah unfortunately I don't have a repro 😞 It occasionally happens on our Jenkins jobs, which just kicks off pants anyway. I haven't seen in on my local machine, much less figure out the patterns of it happening. In terms of frequency, I've only noticed it a handful of times. At first I thought it was just people formatting their BUILD files poorly until I put some thought into it, but I'll keep an eye out on how often it happens.
a
nondeterministic things are like that ):
😢 2
if you can think of anything that might make it easier for your infrastructure to handle this occasional failure (automatic restarting, or something) please let us know, we would probably want to use it too
👍 2
(ideally we fix the error of course)
a
small update: happened once again yesterday and once today. The respective commands are
./pants compile target
and
./pants list --changed...
so not finding any patterns there, but this seems to only happen on our BUILD boxes, and I haven't had any reports of it happening locally. Haven't thought of a way to automatically restart this thing because it's hard to find a pattern of where it might happen, and often times our calls to pants are inside other scripts.
👍 2
a
i’m at a doctor right now but will make an issue when i get in! would automatically restarting the command (as you’ve described) be sufficient in this case?
👍 1
a
I'm guessing it probably will. I'm just telling people to restart the job right now. I'm curious to see if there are any levels of restart (e.g. within pants vs outside) that might make it reproducible?
f
As @aloof-angle-91616 pointed out to me I ran into the same issue when trying build with the following requirements:
Copy code
tensorflow==1.13.1 ; sys_platform==darwin
tensorflow-gpu==1.13.1 ; sys_platform==linux
(see also our discussion in #CASMF8SJ1 )
h
@freezing-daybreak-16435 is it consistently failing to parse for you? This has always been a flaky failure for us
f
I’ve tried it a couple of times and it always failed with the following error:
Copy code
timestamp: 2019-03-14T14:53:21.141060
Exception caught: (pants.build_graph.address_lookup_error.AddressLookupError) (backtrace omitted)
Exception message: Build graph construction failed: ExecutionError 1 Exception encountered:
  MappingError: Failed to parse 3rdparty/python/BUILD:
Invalid requirement, parse error at "u'; sys_pl'"
👌 1
a
when we have seen this internally it has also been on lines which have environment markers, i don't know if that's "most of the time" or "all the time"
at least it is consistent
a
Hmmm all the ones I have seen have always been just
"u''"
f
Thanks for the support, I’ve submitted an issue on GitHub: https://github.com/pantsbuild/pants/issues/7382