Fix tests inside of docker #573
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #573 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 22 22
Lines 6466 6466
=========================================
Hits 6466 6466
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Running tests as root doesn't sound like a great idea. Better to use a real user so that the tests are run in an environment closer to how the code will be used later. And if you want to run the tests, skipping tests shouldn't be the go to solution. I would recommend that you run the tests as a non-root user. In docker it is easy to switch user. If for some reason you really don't want to do that, from the command line you can tell pytest to skip some tests. No need to change the code. |
|
Yes, it is better to use a non-root user. Unfortunately, running as root in docker is the de-facto standard. Do I like it? No. But it is the reality. I feel that just running |
|
I have no problem in accepting this pull request. If you really want to go ahead a run tests as root, I can comment a couple of things and later we merge it. But a clarification. Running tests as root is not a standard. The tests run here via circle ci all use docker images. They run as non-root and I didn't anything special for this. Maybe the github tests also run in docker containers, I am not sure, but if they do, then they run as non-root by default. Base docker images do come as default as root. Though, the idea is that layers are added on top and the user changed. It is a good practice to never run docker containers as root. |
Erotemic
force-pushed
the
investigate-test-failures
branch
2 times, most recently
from
4c1523d
to
136674e
Compare
Erotemic
force-pushed
the
investigate-test-failures
branch
from
136674e
to
5403593
Compare
|
Thanks. I wish running as non-root was an option, but I'm working in an environment where everything is running on a base Having a root-user environment certainly isn't a problem for professional CI systems, but when working on teams with developers at many different skill levels, it can and does come up. I appreciate your willingness to help me out by adding code to detect and work around this admittedly non-ideal enviornment. |
I've run into a tricky issue when running tests locally inside of a docker environment. Tests that involved changing permissions to make a file unreadable were failing when I ran them inside of docker, but they worked on my host system. After a bit of thinking I realized this was because the default user in docker is root, which means files can be read even if they are unreadable according to the permissions.
To address this, I made two changes:
In test_core, I check if I can still read the file after it is forced to be unreadable. If it can be, then we can assume we are in some special circumstance, and we should skip the test.
In test_util, it looks like there is a custom path object, so I fell back to just checking if
os.geteuid() == 0, which should only be true on linux for the root user. In this case I skip the test.Because this is only a test change, I'm not sure if you want a changelog entry.