Open Toxicable opened 3 years ago
@Toxicable Thanks for submitting a ticket! Hmm this is quite interesting, I will do some investigating today and get back to you. I imagine something it is due to the watch file system api that vscode offers. https://github.com/ryanluker/vscode-coverage-gutters/blob/85720680f75236ea8722e6f435cd391831e31fe9/src/coverage-system/coverageservice.ts#L145-L169
I should be able to also make a quick test to reproduce this via the integration coverage we have in the extension. https://github.com/ryanluker/vscode-coverage-gutters/blob/master/test/extension.test.ts
@Toxicable could you also install the custom extension vsix below and look into the output tab -> dropdown -> coverage-gutters
and tell me what the file system watchers are looking for in your project?
This might also be an issue with how the coverage file is being placed in the project from your build system (does it delete and create a new file with the same name? can you force it to use a unique name each time instead that can be found via a glob pattern?)
Thanks for looking into this @ryanluker . I'm out of town for the next week but be able to test it when im back. The build system we're using is Bazel, I'm not certain but I think it deletes the file then writes a new one. As far as I can see in the docs there's no config for specifying the output file, it always gives you one by the same name.
I've just attempted to reproduce it at home with the rules_nodejs repository. But it was working as expected.
I expect that it's working here because I'm using VS Code on Windows, then using the "Remote SSH" extention to work on a repository in a Linux VM, I'm guessing something to do with how the extentions are run in this config makes it work.
I'll be back at work in a few days so will attempt to reproduce it there with your patch then.
Ok so just tried it on Linux with the repository running locally and got this log:
Listening to file system at {/home/f.wiles/workspace}/bazel-out/_coverage/{_coverage_report.dat,lcov.info,cov.xml}
The path to the file is /home/f.wiles/workspace/bazel-out/_coverage/_coverage_report.dat
Also from what I can tell Bazel deletes the old coverage file and replaces it with a new one when it needs to "update" it
@Toxicable Thanks for getting back to me with the log message. That looks like it should work but like you mentioned it would be because of the remote ssh scenario 🤔 .
I will try to find some time to do some more triaging but I have a feeling it is due to the delete + recreate that is going on or something funky with the windows -> linux bit...
I'm hitting this same issue on Mac OS X, where the watch system doesn't seem to notice files changing. I've found I can get it to work correctly by providing the manualCoverageFilePaths
option with an absolute path to a single LCOV file.
Obviously, that's not ideal as I'd much rather be able to take advantage of glob file watching
@lsanwick Good observation on the glob file watching potentially being the issue. We can see in the code snippet below that it uses the built in vscode file system watcher with a glob pattern 🤔 . https://github.com/ryanluker/vscode-coverage-gutters/blob/master/src/coverage-system/coverageservice.ts#L131-L154
I am not 100% sure if it is the issue but I do see some examples of using vscode to generate relative patterns for this, so potentially it might be something we are missing... https://github.com/Microsoft/vscode/issues/67172#issuecomment-458045026 https://vscode.readthedocs.io/en/stable/extensionAPI/vscode-api/#workspace.createFileSystemWatcher
Describe the bug Coverage Gutters is not able to watch changes to readonly coverage files
To Reproduce Not sure best way to reproduce this. Our build system produces a lcov file which is not writable:
-r-xr-xr-x
which we'd like to point Coverage Gutters at, however due to being readonly it's not able to watch changes. If I manually "Remove Watch" then re "Watch" it updates, but as the build system produces changes it dosen't reflect those changes in the UI If I change the permissions withchmod 777
which produces-rwxrwxrwx
then it's able to watch the file as expected, however we don't want to have to constantly do this.Expected behaviour Should pick up changes
Screenshots
Desktop (please complete the following information):
Additional context