Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: fix path mounting when running in Docker #1888

Merged
merged 1 commit into from Apr 29, 2021

Conversation

@okainov
Copy link
Contributor

@okainov okainov commented Apr 21, 2021

Currently pre-commit mounts the current directory to /src and uses
current directory name as mount base.
However this does not work when pre-commit is run inside the container
on some mounted path already, because mount points are relative to the
host, not to the container.

Fixes #1387

Second try. Sorry, no way I can not copy-paste in_docker one, it looks too straightforward and quite pythonic already IMO. But the rest was indeed not really optimal, rewrote completely.

@okainov okainov force-pushed the docker-fix-2 branch 3 times, most recently from 1791cbf to a3ff253 Apr 22, 2021
@okainov
Copy link
Contributor Author

@okainov okainov commented Apr 23, 2021

Name                             Stmts   Miss Branch BrPart  Cover   Missing
----------------------------------------------------------------------------
pre_commit/languages/docker.py      65      0     10      1    99%   40->36
----------------------------------------------------------------------------
TOTAL                             7089      0    714      1    99%

100 files skipped due to complete coverage.
Coverage failure: total of 100 is less than fail-under=100

I don't really understand why CI is not happy. All lines are test-covered. what is 40->36?

@asottile
Copy link
Member

@asottile asottile commented Apr 23, 2021

Name                             Stmts   Miss Branch BrPart  Cover   Missing
----------------------------------------------------------------------------
pre_commit/languages/docker.py      65      0     10      1    99%   40->36
----------------------------------------------------------------------------
TOTAL                             7089      0    714      1    99%

100 files skipped due to complete coverage.
Coverage failure: total of 100 is less than fail-under=100

I don't really understand why CI is not happy. All lines are test-covered. what is 40->36?

that's branch coverage -- it means that once it enters the loop you've only tested the two positive cases inside and not the (implicit) else: pass

@okainov
Copy link
Contributor Author

@okainov okainov commented Apr 23, 2021

@asottile fixed, please review and merge if it's fine

pre_commit/languages/docker.py Outdated Show resolved Hide resolved
pre_commit/languages/docker.py Outdated Show resolved Hide resolved
pre_commit/languages/docker.py Outdated Show resolved Hide resolved
pre_commit/languages/docker.py Outdated Show resolved Hide resolved
pre_commit/languages/docker.py Outdated Show resolved Hide resolved
@@ -12,3 +16,75 @@ def invalid_attribute():
getgid=invalid_attribute,
):
assert docker.get_docker_user() == ()


class TestInDocker:
Copy link
Member

@asottile asottile Apr 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use test classes in this project

Copy link
Contributor Author

@okainov okainov Apr 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I do want to group tests for a given function together. Test classes are the best suited for this. Having bunch of files like test_modulename_functionname is a bit too much IMO

Copy link
Member

@asottile asottile Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use test classes in this project

Copy link
Contributor Author

@okainov okainov Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please be more constructive. I would like to have tests grouped together by their test target. Test classes is the built-in way to do so and in comparison with bare functions it improves both readability of the code an readability of reports. They don't introduce any extra tremendous boilerplate, so what's the problem?

tests/languages/docker_test.py Outdated Show resolved Hide resolved
tests/languages/docker_test.py Outdated Show resolved Hide resolved
tests/languages/docker_test.py Outdated Show resolved Hide resolved

@mock.patch.object(docker, 'is_in_docker', return_value=True)
def test_in_docker_no_binds_same_path(self, _):
binds_list: List[str] = []
Copy link
Member

@asottile asottile Apr 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you inline this you shouldn't need the type signature (?)

Copy link
Contributor Author

@okainov okainov Apr 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got warning from CI about it

Copy link
Member

@asottile asottile Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean if you don't have this as a variable you shouldn't need the annotation

Copy link
Contributor Author

@okainov okainov Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to have consistent tests so they look alike

pre_commit/languages/docker.py Outdated Show resolved Hide resolved
pre_commit/languages/docker.py Outdated Show resolved Hide resolved
tests/languages/docker_test.py Outdated Show resolved Hide resolved
@@ -12,3 +16,75 @@ def invalid_attribute():
getgid=invalid_attribute,
):
assert docker.get_docker_user() == ()


class TestInDocker:
Copy link
Member

@asottile asottile Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use test classes in this project


@mock.patch.object(docker, 'is_in_docker', return_value=True)
def test_in_docker_no_binds_same_path(self, _):
binds_list: List[str] = []
Copy link
Member

@asottile asottile Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean if you don't have this as a variable you shouldn't need the annotation


@pytest.fixture
def mock_file_fixture(self):
return lambda read_data: \
Copy link
Member

@asottile asottile Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no backslashes, again

you probably want this to be a yield fixture:

@pytest.fixture
def mocked_read():
    with mock.patch.object(builtins, 'open', new_callable=mock_open) as mck:
        yield mck

and then in your test, utilize mocked_read.read_data = ...

Copy link
Contributor Author

@okainov okainov Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you probably want this to be a yield fixture:

Not really, yield one doesn't really work, it doesn't allow to set read_data afterwards. Seems like it can be set only in constructor, so I keep it like it is.

tests/languages/docker_test.py Outdated Show resolved Hide resolved
Currently pre-commit mounts the current directory to /src and uses
current directory name as mount base.
However this does not work when pre-commit is run inside the container
on some mounted path already, because mount points are relative to the
host, not to the container.

Fixes pre-commit#1387
@asottile asottile merged commit 7f13fa5 into pre-commit:master Apr 29, 2021
2 checks passed
@okainov
Copy link
Contributor Author

@okainov okainov commented Apr 30, 2021

@asottile thanks for merging. Any plans when to expect new release?

@asottile
Copy link
Member

@asottile asottile commented Apr 30, 2021

no, it's also kinda rude to ask -- the release will happen when it happens

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked issues

Successfully merging this pull request may close these issues.

2 participants