added ignore_identical input for cleaner PRs

[dcwither]

Proposal: Ignore Identical Changes

Hi, thanks for building such a useful tool to measure bundle size differences! I've been using this for a little while so far, and found that the only issue I have is with duplicate reports when I push to the PR multiple times.

I've forked your repo and created a suggestion for how this might be mitigated. My changes aren't exactly as clean as I'd I'd like for a final version, but hopefully it's enough to get the idea across.

I think ideally this would be a GitHub app which can then run a check instead of a Review, which simply gets overwritten, but that's a slightly heavier handed approach.

[andresz1]

Hi @dcwither I'm glad it has been useful 🙌 Thank you so much for opening this PR 🎉, I love the idea. I'd prefer to go for the second approach that you described. The action checks if a review has already been posted and if so it updates it. I think that this could be achieved mixing what you did and octokit.pulls.updateReview. What do you think ?

If you have time, feel free to update your PR! that would be awesome. If not, I'll try to merge your PR and create a new one with that during the weekend!

[dcwither]

I'd forgotten about update I think update can be a good way to go, it's mostly a matter of preference due to some tradeoffs

Update Review

Pros

• Only ever one review, keeping the history cleaner
• No risk of back and forth

Cons

• You lose history e.g. (fail -> fixed)
• Review is more likely to get buried (this was one reason I chose against this in another project I worked on)
• Can't update the event so a reject will always be a reject, and will still need a second review in the case of that switch

Ignore Identical

Pros

• Less likely to get buried
• Update event status built in to behavior
• Maintains history

Cons

• Still creates piles of reviews in large changes
• Can show awkward histories that go back and forth between two reports

I'm happy to work more on this, though I'll probably continue on Tuesday (holiday weekend).

[andresz1]

Good comparison between the two options! thank you for that @dcwither. I think that both could be useful. What if we provide both options with one of them by default ? For example:

update_review:
    required: false
    description: 'whether or not identical reviews should be reposted on rebuild'
    default: false

If it's enabled we update the review and if not we ignore identical by default ?

[dcwither]

Digging into it more now.

[andresz1]

Great @dcwither! let me know if you need help!

[dcwither]

I've put an updated version that provides the options to update/create new in #20. It's largely untested, but I'm not certain when I'll have more time to test it more robustly. If you'd like to take a look at it and provide feedback I can try to revisit a little down the line.

If you'd really like to see this go in sooner rather than later, you're more than welcome to pick up the work from here. Thanks for the feedback so far.

[andresz1]

Thank you so much @dcwither! I'll try to continue your work during this week!

[andresz1]

@dcwither Closing this one in favor of #25. Please let me know if you have any other idea or issue. Thank so much for the help!