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

Feature Request: Option to run without pipe/stdin. Automatically load lcov file from standard location. #201

Open
cinderblock opened this issue Nov 17, 2018 · 1 comment

Comments

@cinderblock
Copy link

I looked for other suggestions for such a feature and did not find one. Frankly, I'm surprised there isn't one.

Admittedly, I'm pretty new to coverage reports but it seems to me that most tools store the lcov formatted output in a predictable location coverage/lcov.info. It would be swell if coveralls automatically found that file and did the right thing without requiring me to pipe the file into the stdin of coveralls.

I recognize that this probably can't be as simple as just running coveralls without any arguments as it looks difficult to me to detect if stdin is provided or not. Could use a timeout to detect no stdin and then go look for the file...

Adding a simple flag like --find would be one way to differentiate the use cases.

We could also or alternatively add a second argument that specifies the lcov file to load specifically. This could even be differentiated from the existing argument by testing if the argument is a file vs a folder.

This would help Windows users tremendously as cat is often missing and | often doesn't work on Windows systems. I recognize that there is a simple solution that works for Linux and Windows of using stdin redirection but I still feel automatically finding lcov data or passing it as an argument and using it would be easier.

It might also directly help with issues like #150

@jtwebman
Copy link

jtwebman commented Mar 6, 2022

Since this library doesn't seem to be supported anymore I fix a bunch of things on a fork if you want to check it out and are still pulling the library into your packages: https://github.com/jtwebman/coveralls-next I kind of agree this would be a good idea. I would be willing to add it to the fork.

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

No branches or pull requests

2 participants