Skip failing test if platform.dist() is Xenial

[cclauss]

Related to #827

Ready for review.

[codecov-io]

Codecov Report

Merging #831 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #831      +/-   ##
==========================================
+ Coverage   94.79%   94.79%   +<.01%     
==========================================
  Files          59       59              
  Lines        9600     9604       +4     
==========================================
+ Hits         9100     9104       +4     
  Misses        500      500

Impacted Files	Coverage Δ
git/test/test_remote.py	97.84% <100%> (+0.02%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a6ca8c...a6938fe. Read the comment docs.

[jeking3]

Do we know why it fails? I would never approve a test change like this... how about using a xenial docker container to figure out why?

[jeking3]

Given my pull request is hitting this, I decided to look into it. I made a docker container to run tox inside with python 2.7 through 3.7 and this happens:

user@c55245f71120:/src$ PYTHONPATH=/src/.tox/py35/lib/python3.5/site-packages/ /src/.tox/py35/bin/nosetests --pdb git.test.test_remote.TestRemote
...> /src/git/remote.py(290)_from_line()
-> raise ValueError("Failed to parse line: %r" % line)
(Pdb) p line
'   (refs/remotes/origin/HEAD has become dangling)'

It looks like there is some unexpected information coming out of git with xenial, which is newer than the one that comes with trusty, so disabling this test is absolutely not the right thing to do.

[jeking3]

The failing test is valid and showing the code is not ready for the updated git version on xenial. It may work find on trusty, but fails on xenial because it looks like git output changed.

[cclauss]

What happens if git is upgraded on trusty?

[jeking3]

I may have been running into a different issue, as locally I had origin set to a git uri instead of https uri, and one of the tests was failing as a result. The last remote test assumes you have read access to origin (on github). Still running through to see what happens.

[jeking3]

Okay, this is pretty frustrating. The entire test suite seems to run only if the current branch is "master". If you are on another branch, there are a number of failures due to bad assumptions? Does anybody else do their work on a branch in a fork, or do you do all of your work in the master branch of your fork?

Example:

======================================================================
FAIL: test_init_repo_object (git.test.test_docs.Tutorials)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jking/GitPython/git/test/lib/helper.py", line 92, in wrapper
    return func(self, path)
  File "/home/jking/GitPython/git/test/test_docs.py", line 75, in test_init_repo_object
    "It's ok if TC not running from `master`.")
AssertionError: <git.Head "refs/heads/fix-requirements"> != <git.Head "refs/heads/master"> : It's ok if TC not running from `master`.
-------------------- >> begin captured logging << --------------------
git.cmd: DEBUG: Popen(['git', 'init', '--bare'], cwd=/tmp/test_init_repo_objectm8st37bo/bare-repo, universal_newlines=False, shell=None)
git.cmd: DEBUG: Popen(['git', 'status', '--porcelain', '--untracked-files'], cwd=/home/jking/GitPython, universal_newlines=False, shell=None)
git.cmd: DEBUG: Popen(['git', 'clone', '-v', '/home/jking/GitPython/.git', '/tmp/test_init_repo_objectm8st37bo/to/this/path'], cwd=/home/jking/GitPython, universal_newlines=True, shell=None)
git.repo.base: DEBUG: Cmd(['git', 'clone', '-v', '/home/jking/GitPython/.git', '/tmp/test_init_repo_objectm8st37bo/to/this/path'])'s unused stdout:
git.cmd: DEBUG: Popen(['git', 'init'], cwd=/tmp/test_init_repo_objectm8st37bo/path/for/new/repo, universal_newlines=False, shell=None)
git.cmd: DEBUG: Popen(['git', 'cat-file', '--batch-check'], cwd=/home/jking/GitPython, universal_newlines=False, shell=None)
git.cmd: DEBUG: Popen(['git', 'archive', '2e414deff98915b736639a67cc1dbf79d57f1eba'], cwd=/home/jking/GitPython, universal_newlines=False, shell=None)
git.test.lib.helper: INFO: Test Tutorials.test_init_repo_object failed, output is at '/tmp/test_init_repo_objectm8st37bo'

--------------------- >> end captured logging << ---------------------

Although the test seems to make you want to think it's okay, the assertion fails and the test actually fails.

Then I run into:

======================================================================
ERROR: test_init_repo_object (git.test.test_docs.Tutorials)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/src/git/test/lib/helper.py", line 92, in wrapper
    return func(self, path)
  File "/src/git/test/test_docs.py", line 138, in test_init_repo_object
    bare_master = bare_repo.create_head('master', origin.refs.master)
  File "/src/git/util.py", line 886, in __getattr__
    return list.__getattribute__(self, attr)
AttributeError: 'IterableList' object has no attribute 'origin/master'
-------------------- >> begin captured stdout << ---------------------

Again this is because I have changes locally on a branch, which is best practices even if you are on your own fork.

[jeking3]

I found a FIXME in the command handler around joining the process thread which states that joining there could block stdin. The issue we're seeing in the CI build is that the command "git cat-file --batch" is waiting for stdin, but does not get it, so I think the issue is around there...

[jeking3]

I changed Python 3.7 to an allowed failure. There is something odd going on here I spent all day trying to understand. I cannot reproduce it inside a Docker container running xenial. Clearly the "get fetch --progress -v" is causing some sort of problem but all we get is error 1 and no additional information.

[jeking3]

Finally I was able to reproduce the issue in the docker container. Xenial comes with git 2.7.4 but 2.20.1 is installed on the xenial images on Travis, and when I updated the docker container to use the same version I am able to reproduce the issue:

(Pdb) pp self.proc.__dict__
{'_child_created': True,
 '_closed_child_pipe_fds': True,
 '_communication_started': False,
 '_devnull': 25,
 '_input': None,
 '_sigint_wait_secs': 0.25,
 '_waitpid_lock': <unlocked _thread.lock object at 0x7f143258bf08>,
 'args': ['/usr/bin/git',
          'fetch',
          '--progress',
          '--tags',
          '-v',
          'daemon_origin'],
 'encoding': None,
 'errors': None,
 'pid': 1193,
 'returncode': 1,
 'stderr': <_io.TextIOWrapper name=38 encoding='UTF-8'>,
 'stdin': None,
 'stdout': None,
 'text_mode': True}
(Pdb) p stderr
b''

[jeking3]

So with git 2.20.1 running as a daemon I get an error:

user@fe413f326ba9:/tmp/daemon_cloned_repo-test_base-nvtutw91$ git fetch --progress --tags -v daemon_origin
Looking up localhost ... done.
Connecting to localhost (port 19418) ... 127.0.0.1 done.
From git://localhost:19418/daemon_repo-test_base-2zdmg0tj
 = [up to date]      master             -> daemon_origin/master
 = [up to date]      0.1.4              -> 0.1.4
 = [up to date]      0.1.4-pre          -> 0.1.4-pre
 = [up to date]      0.1.5              -> 0.1.5
 = [up to date]      0.1.6              -> 0.1.6
 = [up to date]      0.1.7              -> 0.1.7
 = [up to date]      0.2.0-beta1        -> 0.2.0-beta1
 = [up to date]      0.3.0-beta1        -> 0.3.0-beta1
 = [up to date]      0.3.0-beta2        -> 0.3.0-beta2
 = [up to date]      0.3.1-beta1        -> 0.3.1-beta1
 = [up to date]      0.3.1-beta2        -> 0.3.1-beta2
 = [up to date]      0.3.2              -> 0.3.2
 = [up to date]      0.3.2-RC1          -> 0.3.2-RC1
 = [up to date]      0.3.2.1            -> 0.3.2.1
 = [up to date]      0.3.2.1-patched    -> 0.3.2.1-patched
 = [up to date]      0.3.3              -> 0.3.3
 = [up to date]      0.3.4              -> 0.3.4
 = [up to date]      0.3.5              -> 0.3.5
 = [up to date]      0.3.6              -> 0.3.6
 = [up to date]      0.3.7              -> 0.3.7
 ! [rejected]        1.0-RV_hello.there -> 1.0-RV_hello.there  (would clobber existing tag)
 = [up to date]      1.0.0              -> 1.0.0
 = [up to date]      1.0.1              -> 1.0.1
 = [up to date]      1.0.2              -> 1.0.2
 = [up to date]      2.0.0              -> 2.0.0
 = [up to date]      2.0.1              -> 2.0.1
 = [up to date]      2.0.2              -> 2.0.2
 = [up to date]      2.0.3              -> 2.0.3
 = [up to date]      2.0.4              -> 2.0.4
 = [up to date]      2.0.5              -> 2.0.5
 = [up to date]      2.0.6              -> 2.0.6
 = [up to date]      2.0.7              -> 2.0.7
 = [up to date]      2.0.8              -> 2.0.8
 = [up to date]      2.0.9              -> 2.0.9
 = [up to date]      2.1.0              -> 2.1.0
 = [up to date]      2.1.1              -> 2.1.1
 = [up to date]      2.1.10             -> 2.1.10
 = [up to date]      2.1.11             -> 2.1.11
 = [up to date]      2.1.2              -> 2.1.2
 = [up to date]      2.1.3              -> 2.1.3
 = [up to date]      2.1.4              -> 2.1.4
 = [up to date]      2.1.5              -> 2.1.5
 = [up to date]      2.1.6              -> 2.1.6
 = [up to date]      2.1.7              -> 2.1.7
 = [up to date]      2.1.8              -> 2.1.8
 = [up to date]      2.1.9              -> 2.1.9
 = [up to date]      __testing_point__  -> __testing_point__
 = [up to date]      winerr_show        -> winerr_show
user@fe413f326ba9:/tmp/daemon_cloned_repo-test_base-nvtutw91$

"would clobber existing tag" looks like new behavior since April 2018. Need to use --force now.

[jeking3]

git 2.20 added new behavior here, no longer clobbering local tags:
git/git@0bc8d71