2

So I am trying to use the coverage.py tool to measure the code coverage of my Django app, however, I have had 0 success today. Basically, my plan was after running the docker container, to have a process manager execute a .sh file, containing the following 2 lines: coverage run /path/to/manage.py test nameofapp and coverage html -d coverage_html". The problem is that the html file is not being created and I am basically getting 0 information about the coverage. After entering the docker container using docker exec -it nameofcontainer bash and reading the logs I found the following error: 

 ----------------------------------------------------------------------
 Ran 12 tests in 0.081s
 OK
 >>> Creating test database for alias 'default'...
 Destroying test database for alias 'default'...
 Traceback (most recent call last):
   File "/usr/bin/coverage", line 9, in <module> load_entry_point('coverage==4.3.4', 'console_scripts', 'coverage')()
   File "/usr/lib/python3.4/site-packages/coverage/cmdline.py", line 756, in main status = CoverageScript().command_line(argv)
   File "/usr/lib/python3.4/site-packages/coverage/cmdline.py", line 483, in command_line return self.do_run(options, args)
   File "/usr/lib/python3.4/site-packages/coverage/cmdline.py", line 641, in do_run self.coverage.save()
   File "/usr/lib/python3.4/site-packages/coverage/control.py", line 742, in save self.data_files.write(self.data, suffix=self.data_suffix)
   File "/usr/lib/python3.4/site-packages/coverage/data.py", line 673, in write data.write_file(filename)
   File "/usr/lib/python3.4/site-packages/coverage/data.py", line 460, in write_file with open(filename, 'w') as fdata:
 PermissionError: [Errno 13] Permission denied: '/.coverage'

So after seeing the lack of permissions on /.coverage, I simply added chmod +x /path/to/.coverage, however, this made 0 difference and I yet received the exact same error. I decided to enter the container once more and execute the script myself and to my surprise, it worked flawlessly. So why am I not capable of executing the .sh file using the process manager? Is it because the /.coverage file is created once I run the first coverage command and even tho I added the chmod command I am not really changing the permissions on the file as it still does not exist?

dsax7
  • 1,333
  • 22
  • 36
  • Why use the process manager as opposed to `docker exec coverage run ...`? – Alex Hall Mar 26 '17 at 21:00
  • @AlexHall Well, I am using the process manager to start a couple of other processes (nginx and some `.sh` scripts), so I thought I may add another one as I will avoid writing long lines and hard coding things. – dsax7 Mar 26 '17 at 21:09
  • What user does the process manager run under, and what user are you when you `exec` in? Also I think you want `chmod +w /path/to/.coverage` or just `/path/to` if the file isn't there already. – Alex Hall Mar 26 '17 at 21:12
  • Sadly, the `chmod +w /path/to` did not work. Is it really important, which user runs the process manager when there are already 4 bash scripts successfully executed meaning that there should be no issues with the process manager itself ? – dsax7 Mar 28 '17 at 18:42
  • The user probably matters if you're getting permissions denied, yes. Did you `chmod` as the user who is able to run coverage, or did you put it in the process manager script? You want the former. – Alex Hall Mar 28 '17 at 18:50
  • Honestly I did not set anything in terms of user permissions. I simply added the new script to the process manager. However, I am fairly new to coverage.py, so I haven't set anything there and my mistake may actually be there. – dsax7 Mar 28 '17 at 20:33
  • 1. Run `docker exec -it nameofcontainer whoami` and report the result. 2. put `whomai` in the `.sh` and report the result. 3. `docker exec chmod +w /path/to` and `docker exec nameofcontainer chmod +w /path/to/.coverage` (it looks like `/path/to` is just `/` btw), restart the container, and try again. 4. `docker exec -it nameofcontainer ls -al /path/to` and tell me what's on the line for `.`. 5. Honestly I think you should scrap the process manager thing, I really don't see the point. Especially since you still have to manually check the logs afterwards. – Alex Hall Mar 28 '17 at 20:57
  • 1. root 2. I haven't tried it as I am haven't executed any other scripts as root and they seem to work 3. I tried both and no luck. 4. `drwxr-xr-x 8 runapps runapps 4096 Mar 28 21:02 .` This is what I got next to the `.` . 5. Well, I do have to collect static files, assure that the superuser is created, do migrations, start + set nginx and a couple of other things and thats why I am still using the process manager. – dsax7 Mar 28 '17 at 21:10
  • 2. The other scripts aren't necessarily trying to write files to `/path/to`. 3. Sorry I just realised I made a mistake with `chmod`, you want `a+w` (give **all** the permission to **write**). 4. Is `runapps` the user the process manager runs under? If not that will explain the problem. 5. I'm not suggesting you stop using the process manager entirely, just not for tests. In my work the python source is mapped to a volume on the host so I can edit the source in an IDE and then run tests in the container through `docker exec` without rebuilding the container, it's a very nice workflow. – Alex Hall Mar 28 '17 at 21:17
  • 2. By default all processes run as root. 3. I tried using `chmod a+w /path/to` yet no luck. 4. As mentioned in 2. By default all of the processes are run as root. 5. Sounds really nice , but isn't there the danger of someone deleting files through the container as you map the folder containing your python code to a folder in the container? – dsax7 Mar 28 '17 at 21:31
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/139309/discussion-between-alex-hall-and-learningdjango). – Alex Hall Mar 28 '17 at 21:36

0 Answers0