You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @melnychukvitaliy, thanks for this action! I think it is closest of the many like this to supporting my team's use case.
The only friction for us is that we run our tests on every 'push', so it would be ideal if we could integrate it into our existing actions workflow triggered by a push event, instead of the pull_request events.
I think I might be able to implement this by conditionally using github's 'commit comment' functionality (https://docs.github.com/en/rest/reference/repos#create-a-commit-comment) to attach the comment to a commit when the triggering event is a push, instead of the existing default 'issue/pr comment' for a pull_request event.
Would you have any concerns or guidance if I attempted a PR to add this?
The text was updated successfully, but these errors were encountered:
The support of 'push' events is definitely something that would be very useful for this action. There is a list of limitations of using 'push' event instead of 'pull_request'. I would be happy to help and share them with you to figure out the best way of implementing push events support.
I like the idea of adding comments to each commit with current code coverage percentage. I think we need to use a different comment template for this type of event. This is because we can't get changed files to show what lines were not covered in the PR (src/github/getChangedFiles.js).
The second feature that would be sort of different for 'push' events is src/github/createOrUpdateComment.js where we are updating previously posted comments. We can just disable this one.
If you have time, you can add a draft PR based on your vision and we can go together over it and see what we can use from the 'pull_request' one. Even if we have some limitations on what we can use there I still think it will be useful to have this support.
Thanks for the feedback, that's very helpful. I'll explore looking up open PRs with the payload data provided with a 'push' event as well. It might be ideal to keep the experience the same regardless of triggering event.
Hi @melnychukvitaliy, thanks for this action! I think it is closest of the many like this to supporting my team's use case.
The only friction for us is that we run our tests on every 'push', so it would be ideal if we could integrate it into our existing actions workflow triggered by a
push
event, instead of thepull_request
events.I think I might be able to implement this by conditionally using github's 'commit comment' functionality (https://docs.github.com/en/rest/reference/repos#create-a-commit-comment) to attach the comment to a commit when the triggering event is a
push
, instead of the existing default 'issue/pr comment' for apull_request
event.Would you have any concerns or guidance if I attempted a PR to add this?
The text was updated successfully, but these errors were encountered: