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

Missing TOTAL line in report when omitting all but one file #732

Closed
Hisol opened this issue Nov 13, 2018 · 7 comments
Closed

Missing TOTAL line in report when omitting all but one file #732

Hisol opened this issue Nov 13, 2018 · 7 comments
Labels
wontfix This will not be worked on

Comments

@Hisol
Copy link

Hisol commented Nov 13, 2018

When I run coverage and omit all files bar the one file I am interested in, the report output does not include the TOTAL portion of the report or the separator.

This is therefore breaking the CI scripts that are being used to report on coverage.

If there are 2 files present after the omissions, then the separator and TOTAL rows are returned in the report.

@nedbat
Copy link
Owner

nedbat commented Nov 13, 2018

It seems redundant to have a total line for just one file. Can't the CI scripts just look for the last line of the report?

@nedbat nedbat closed this as completed Nov 25, 2018
@Hisol
Copy link
Author

Hisol commented Dec 3, 2018

Sorry for slow reply, lost in my email :/

Having the total line makes it consistent in all use cases. With the current setup adding an extra file or removing enough files to switch between 1 or 1+ files in the output would also require going and changing the CI scripts each time or potentially weird outputs/errors. More timed spent tweaking scripts etc.

Be nice if the output was simply consistent regardless, or if there was an option at least to force the total for people who want that consistency.

@nedbat
Copy link
Owner

nedbat commented Dec 6, 2018

I think a text scraper can still just look at the last line of the report, with a total or not. But in the long run, I'd rather support your use-case with a true machine-readable format.

@Hisol
Copy link
Author

Hisol commented Dec 6, 2018

Totally it can, but it's more faffing about with CI scripts that IMHO should be only tweaked on occasion. In my use case it was picking up earlier output which included a TOTAL line and I didn't spot the reason why the figures didn't match until I went looking though the workers output.

For me it also says that the script finished without issue, I have used plenty of software that has silently died at some point but you couldn't really tell without knowing some output was being missed.

I guess I just like things to all look the same and not change without user specifying they want changes in the options.

@languitar
Copy link

languitar commented Sep 18, 2020

Just to add one more hint to this: Gitlab only supports regular expressions for parsing the generated output. Without the TOTAL, creating a working regular expression is pretty hard.

@nedbat
Copy link
Owner

nedbat commented Jan 6, 2021

Now with #1091 merged, the TOTAL line is always output.

@nedbat
Copy link
Owner

nedbat commented Jan 26, 2021

This is now released as part of coverage 5.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants