Skip to content

Comments

GitHub annotations#432

Merged
Bachmann1234 merged 25 commits intoBachmann1234:mainfrom
timkrins:github-warning-annotations
Jul 17, 2025
Merged

GitHub annotations#432
Bachmann1234 merged 25 commits intoBachmann1234:mainfrom
timkrins:github-warning-annotations

Conversation

@timkrins
Copy link
Contributor

@timkrins timkrins commented Jan 12, 2025

Adds a report generator that prints GitHub style annotations to stdout.

Defaults to warning but other types (error, info, debug) can be passed (thanks @kingbuzzman for this, and sorry for delay)

Screenshot of diff-cover coverage.lcov --format github-annotations:warning running in GitHub actions
Screenshot 2025-01-12 at 10 36 30
Screenshot 2025-01-12 at 11 15 53

@timkrins timkrins mentioned this pull request Jan 12, 2025
@Bachmann1234
Copy link
Owner

So at a high level this seems like a useful feature. I have a hard time thinking about new diff-cover/diff-quality features since I dont really use these tools anymore. I just maintain the project.

But it looks like Github annotations introduce some level of customizability (whats a warning, whats an error, whats a message). My gut is the approach taken here "Everything is a warning" seems reasonable. However, if others start using it I suspect the desire for customization will come up shortly after.

I think im happy to merge in a "everything is a warning" pr. Do yall think there will be much demand for further customization? Do you think we could get away with "look, the flag will do the basics but if you have more complex demands that config needs to be defined in some config file"?

@wyardley
Copy link

For the use case like sqlfluff, both errors and warnings would be ideal.

Being able to add code suggestions is also useful, though I suspect most people will use a tool like reviewdog instead for that.

@timkrins timkrins marked this pull request as ready for review January 21, 2025 23:19
@timkrins timkrins marked this pull request as draft January 23, 2025 21:20
@kingbuzzman
Copy link
Contributor

Guess who had this same idea today.... [independently] ME! I'll help out, I would like to see this feature soon.

@wyardley
Copy link

Thanks @kingbuzzman

@kingbuzzman
Copy link
Contributor

kingbuzzman commented Jun 12, 2025

@timkrins can you sync with main? Is this something you want to finish? Or would you like it/wouldn't mind if i took over?

@timkrins
Copy link
Contributor Author

@kingbuzzman awesome regarding the format arguments. I'm a bit slammed atm but I will try and extract some time to rebase!

@kingbuzzman
Copy link
Contributor

No rebase needed, just in github click on the "resolve conflicts" button 😉

@timkrins timkrins force-pushed the github-warning-annotations branch from 46661af to 6e573d4 Compare June 12, 2025 21:07
@timkrins timkrins force-pushed the github-warning-annotations branch from a5d827c to a839043 Compare June 12, 2025 21:12
@timkrins
Copy link
Contributor Author

I have rebased on main, and added the annotation format - although right now it is a TODO as I am still a bit unclear on an elegant way to pass the value down to the formatter and then template context.

@kingbuzzman
Copy link
Contributor

@timkrins ^

@timkrins
Copy link
Contributor Author

@kingbuzzman I'll get to it this week :)

@kingbuzzman
Copy link
Contributor

@timkrins any idea when you'll get around to this? I kind of need this... If you're unwilling, i'll just merge my PR

@timkrins timkrins changed the title GitHub warning annotations GitHub annotations Jul 15, 2025
@timkrins timkrins marked this pull request as ready for review July 15, 2025 08:14
Copy link
Contributor

@kingbuzzman kingbuzzman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking because of a bugfix inside a feature

- name: Complete coverage
run: |
poetry run diff-cover coverage.xml --include-untracked
poetry run diff-cover coverage.xml --include-untracked --format github-annotations:error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with adding error. But i didn't want to impose it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Bachmann1234 what do you think this should be?

Copy link
Contributor Author

@timkrins timkrins Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change it to use the default, which will be warning.

Copy link
Contributor

@kingbuzzman kingbuzzman Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no "default" it will crash. This is a bigger bug that has little to do with your PR. For now, why dont we use warning and wait for @Bachmann1234

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah - I see. I thought it would be a good test of the default, and in a way it was haha.

markdown_report = report_formats["markdown"] or MARKDOWN_REPORT_DEFAULT_PATH
reporter = MarkdownReportGenerator(coverage, diff)
with open(markdown_report, "wb") as output_file:
with open_file(markdown_report, "wb") as output_file:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find, but should really be a separate PR; this should have a test associated with it.

Suggested change
with open_file(markdown_report, "wb") as output_file:
with open(markdown_report, "wb") as output_file:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah - I merged in your branch - it was your change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed here: #516

@kingbuzzman
Copy link
Contributor

kingbuzzman commented Jul 15, 2025

@Bachmann1234 this is Bellissimo!!! and should be [squashed] merged as soon as possible 😇

@timkrins thank you so much for your efforts and idea! This is going to be great for me, you have no idea how much code I will delete because of this! ❤️

@Bachmann1234
Copy link
Owner

Alrighty! Lets go ahead and merge/release this. Thank you for the PR @timkrins and thanks for the review support @kingbuzzman

@Bachmann1234 Bachmann1234 merged commit b478eae into Bachmann1234:main Jul 17, 2025
8 checks passed
@Bachmann1234
Copy link
Owner

Released! Check out https://pypi.org/project/diff-cover/9.6.0/

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

Successfully merging this pull request may close these issues.

4 participants