Skip to content

2.0.5: gitdb.test.db.test_git.TestGitDB, gitdb.test.db.test_ref.TestReferenceDB, gitdb.test.performance.test_pack_streaming.TestPackStreamingPerformance fail #51

Open
@dvzrv

Description

@dvzrv

Hi!

I'm currently maintaining gitdb(2) for Arch Linux. During packaging I would like to be able to run the tests, but they fail on me due to relatively undocumented behavior in regards to the test git repository:
python-gitdb-2.0.5-check.log

I'm using the pypi source tarballs for version 2.0.5:
https://files.pythonhosted.org/packages/c4/5c/579abccd59187eaf6b3c8a4a6ecd86fce1dfd818155bfe4c52ac28dca6b7/gitdb2-2.0.5.tar.gz

After build (before installation), I run the tests and setup a git repository for test purposes:

local TEST_TMPDIR=$(mktemp -d)                                                                                                                                                              
( cd "$TEST_TMPDIR" && git init . )
export GITDB_TEST_GIT_REPO_BASE="${TEST_TMPDIR}/.git"
nosetests -vd

We're currently on:

  • git 2.23.0
  • python-setuptools 41.2.0
  • python-smmap 2.0.5
  • python-nose 1.3.7

Any hint/help would be greatly appreciated!

Activity

Byron

Byron commented on Aug 28, 2019

@Byron
Member

As in GitPython, an initialised git repository along with some history are assumed for the tests to run successfully.
When looking at the (freshly run) tests on CI, I see the performance tests are skipped there. This might be as they are known to fail on travis as it does check out the repository with low history depth (even though 1000 seems high enough).

I don't think the performance tests are testing anything new or add to coverage, which is why you could skip them as well.

For the other two non-performance failures, there might just not be enough history. If git init . does not create a single commit, then there is no reference either. Please make sure there is some history.

Apologies for the inconvenience, it's clear that unit tests should be isolated and not depend on any state they don't control themselves.

Please let me know if this helped, or if there are any further questions.

dvzrv

dvzrv commented on Sep 28, 2019

@dvzrv
Author

Why not create a git repository on the fly as an asset?
That kind of decoupling would be really great!

dvzrv

dvzrv commented on Sep 29, 2019

@dvzrv
Author

This at least works for nearly all tests:

  local TEST_TMPDIR=$(mktemp -d)
  (
    cd "$TEST_TMPDIR"
    git init
    git config user.name "Test User"
    git config user.email "test@user.org"
    for commit in {1..50}; do
      touch "file${commit}"
      git add "file${commit}"
      git commit -m "file${commit}"
    done
  )
  export GITDB_TEST_GIT_REPO_BASE="${TEST_TMPDIR}/.git"
  nosetests -vd -e 'test_pack_writing'
Byron

Byron commented on Sep 29, 2019

@Byron
Member

That looks neat! Do you think you could supply this with a PR? Thanks so much!

dvzrv

dvzrv commented on Sep 29, 2019

@dvzrv
Author

@Byron I guess it depends on what you understand under pull request.
As part of the test suite (have mainly worked with pytest actually), or as part of the travis setup?

Byron

Byron commented on Sep 30, 2019

@Byron
Member

I think Travis could call a script which contains that code. If I remember correctly, one can set an environment variable for the repository it should use for tests. @dvzrv

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Byron@dvzrv

        Issue actions

          2.0.5: gitdb.test.db.test_git.TestGitDB, gitdb.test.db.test_ref.TestReferenceDB, gitdb.test.performance.test_pack_streaming.TestPackStreamingPerformance fail · Issue #51 · gitpython-developers/gitdb