Ability to capture a 'repro' of pants state, for debugging.

Review Request #2876 — Created Sept. 23, 2015 and submitted

benjyw
pants
22a65c4...
pants-reviews
mateor, patricklaw, stuhood
When people complain about a problem with pants we can tell them to
run the same command with --repro-capture=<path> and send us the
resulting file.

New unittest passes.
Manual tests.
CI passes: https://travis-ci.org/pantsbuild/pants/builds/81878490.

BE
MA
  1. You have a merge conflict with your earlier patch, just as an fyi. But this is great! It opens up a potential patch to mechanically transform the paths and maybe run the files under pants.d.

    I was suprised that it wanted me to name the tarball. When I passed /Users/mateo/dev (the parent directory of my pants install) it created a /Users/mateo/dev.tar.gz, I guess to avoid having a custom scheme for handling naming, removing, etc.

    1. Yeah, I'm ready for the merge conflict...

      I wanted to make sure that the file was always identifiable as a tar.gz so the user would know how to extract it. I could detect if the output path is an existing dir and put it under that dir, but that seems just as arbitrary... I'll leave this as is for now, and if it turns out to be annoying we can change it.

  2. src/python/pants/bin/repro.py (Diff revision 1)
     
     

    s/2014/2015/

  3. src/python/pants/bin/repro.py (Diff revision 1)
     
     

    I might like ignore exposed as an option as well, you never know when that might come in handy.

    1. Let's wait for that to be needed? I don't like proliferating options on the basis of "might come in handy". There is a cognitive load associated with each one.

  4. src/python/pants/bin/repro.py (Diff revision 1)
     
     

    Maybe add an expanduser? I bet users will pass tilde notation, I know I did at first.

    1. Good idea, done.

  5. src/python/pants/bin/repro.py (Diff revision 1)
     
     

    parens are unnecessary after the not

    1. Ooops, that was left over from an earlier clause.

  6. 
      
ZU
  1. wow, looks like you bundle up the entire workspace including .git and all the output under .pants.d? That sounds huge.

    We have a script that we use 'pants_bug_report.sh' that's integrated into our pants wrapper but I just collect a subset of data, make a tarball, and use the Jira API to file a ticket. I guess we could switch to this method, but we'd probably need to upload this giant tarball to some kind of blobstore like Amazon S3 or something.

    1. It doesn't take .git, but it does take .pants.d, deliberately. We often need that data in order to debug user build issues.

      The file isn't that big - for all of Foursquare's monorepo it comes to a few hundred megabytes.

  2. 
      
BE
BE
BE
  1. Thanks Mateo! Submitted as 6422abace4efa6977d16f1281a865bcb366b8037.

  2. 
      
BE
Review request changed

Status: Closed (submitted)

Change Summary:

6422abace4efa6977d16f1281a865bcb366b8037

Loading...