Make GitHub comments less spammy

[jevakallio]

Currently appr will create a new comment for every build in an open PR - most commonly this means for every push, which can get a bit spammy.

Consider making the user experience better by amending existing comments, or if we still want to post a new comment every time, at least collapsing the content of older comments.

Danger does this quite well. We could see if we can use Danger internally, or more likely, just get inspiration of how it works since we may not want the full danger comment format.

[jpdriver]

My two cents here are:-

1 - if the new Expo URL is the same, don't do anything. We could delete and re-post if we absolutely always want the message to be the most recent comment, but that seems like overkill?

2 - if the Expo URL has changed (e.g. different release channel) post a new message and leave previous ones intact.

[jpdriver]

@jevakallio did you want to change the behaviour here? we're currently doing option 2 above, using comparing the whole message and only posting a new one if it's changed (never deleting).

[motiz88]

It would be awesome to still have some indication within the PR thread that the app has been updated, say with a comment that includes a timestamp, commit hash or both. My model for this is Codecov, which posts a single, data-rich, always-updating comment.

[jpdriver]

@motiz88 I get what you're saying -- but I think that would make more sense if we persisted builds for each commit.

At the moment each branch ( / PR) gets allocated a single Expo Release Channel. Any subsequent commits will update that same Channel, and -- assuming it builds correctly -- the Channel should always be upto date with the latest commit hash.

If in future we created a new Channel for each commit hash, then something like what you've outlined would absolutely make sense. We could have a single comment and continuously update it with new links to each version, wrapped in something like an expanding <details> tag.

But given we don't currently persist commit-level builds, I don't think timestamps and commit hashes would add that much for now. Could be one for the future though! 🙂