barsoom / ex-remit Goto Github PK

If I set my username to 'MartyBeGood', I can see comments for me, but I'm not allowed to resolve them and it doesn't display that the pair has already resolved a comment:

If I set it to 'martybegood' (exact same casing as in the commit Co-Authored-By trailer), I can resolve them:

There is a unique index on commits.sha, but it should probably be on [repo, sha].

We'll also need to change the association from comments to commits, since that's only on the sha currently. Maybe make that one just use the primary key, now that we ensure a commit always exists if the comment does.

The two webhook faker tasks use a hardcoded port number that doesn't match the port ex-remit listens on in dev mode

The UI first gets the latest n commits, then counts stats in memory.

The stats API counts unreviewed commits from all listed commits, so their counts won't match.

The stats API should also get the latest n and count stats in memory.

Report: https://auctionet.slack.com/archives/CF9SAN79V/p1592893506056800?thread_ts=1592856910.045500&cid=CF9SAN79V

More important:

• Either start using username instead of email for avatars and "reviewed by", or at least start saving the username so we later could do this
• Decide whether we want usecs in datetimes or not
• Save full payload to make future migrations easier?
• Error reporting (Honeybadger)
• Highlighted comments
• Polish comments view

Fun polish:

• Tooltips
• Include reactions on comments in feed, not just comments proper. Best approach might be: on a recurring schedule, figure out which repos the most recent commits are from. Call https://developer.github.com/v3/repos/comments/#list-commit-comments-for-a-repository for each repo to get reactions.
• Relative times here and there, or contextually long times – just the time if today, just the weekday if in the past week…
• Show emoji-only comments in a bigger font (We should probably then also parse GitHub emoji syntax. Could do a sloppy but simple detection of real emoji by triggering on any texts shorter than x length and containing no letters or digits. Perhaps showing all short messages in larger font, even.)
• Show an indicator when you've been reviewing for a long time
• GitHub Oauth for auth + setting username

Can wait until after we start using it:

• More tests
• Devbox setup
• Docs (e.g. Fluid.app)
• Bump Heroku plan if needed
• CI setup
• Consider open sourcing
• Recurring job to remove old data
• Handle missed messages on reconnection (https://curiosum.dev/blog/elixir-phoenix-liveview-messenger-part-4?) See https://github.com/barsoom/review/blob/8728b18c2269c2786bdf0c96a35bf35e8c044f8e/web/static/js/app.js
• Expiring old data
• Consider case sensitivity with username matching

Public release:

• Screenshot in README
• Logo in README
• Polish README

Report: https://auctionet.slack.com/archives/CF9SAN79V/p1592892584049100?thread_ts=1592856910.045500&cid=CF9SAN79V

Remit shows such a user for e.g. the commit b5889b7.

• Don't show it as a co-author (maybe? But we probably still want to show dependabot as one?)
• Don't notify it about comments (and do the same for all bots?)
• Remove any notifications to it already in the DB (ditto)

See discussion: https://auctionet.slack.com/archives/CF9SAN79V/p1592900099078400

See discussion: https://auctionet.slack.com/archives/CF9SAN79V/p1593075011333600

@joakimk says this is how Review behaves and what he prefers.

See discussion: https://auctionet.slack.com/archives/CF9SAN79V/p1592475111389400?thread_ts=1592473726.387600&cid=CF9SAN79V

Report: https://auctionet.slack.com/archives/CF9SAN79V/p1592893370056200?thread_ts=1592856910.045500&cid=CF9SAN79V

See:

• https://auctionet.slack.com/archives/CF9SAN79V/p1592893506056800?thread_ts=1592856910.045500&cid=CF9SAN79V
• https://auctionet.slack.com/archives/CF9SAN79V/p1592894745060400?thread_ts=1592856910.045500&cid=CF9SAN79V

Report: https://auctionet.slack.com/archives/CF9SAN79V/p1593178227481700

React-like components: http://surface-demo.msaraiva.io/

• API
• rstat2 command for now
• Launch: Replace the rstat command

Should be properly fixed by #9 but we should also fix it before then.

Report: https://auctionet.slack.com/archives/CF9SAN79V/p1592892679049800?thread_ts=1592856910.045500&cid=CF9SAN79V

Maybe a filter, maybe automatically collapsing series of reviewed ones and you can expand (GitHub diff style), or something else.

See discussion: https://auctionet.slack.com/archives/CF9SAN79V/p1593075133334500

Like the old Review app did.

A simple solution without writing JS could be to have a timer running e.g. every minute in the LiveView, setting a virtual column to "overdue" or something for overdue commits, then unsetting it when abandoning the review or marking it as reviewed.

• Exclude hidden commits from stats
• Actually fetch commits
• Notify commit users
• Actually fetch previous comments on commit
• Notify comment users

We can't notify the commit author if we don't have the commit in DB.

Plan:

• When a comment comes in via webhook and we don't have the commit in DB, fetch it via API and create it in DB.
• Also fetch all previous comments on the commit (or on this thread, specifically), only creating them if they don't exist already.
• Flag the commit and comments with something like hide: true
• Don't show hide == true commits and comments in the UI. Only use them for notifications. Sticking them at the top of the commit list would be annoying (they could be old); sticking them further down gets confusing.

Alternatively:

• We could just use the data we got via API to notify, and not store anything. This means fetching from API every time if there's an extended discussion, but also means no storing hidden data in DB.
• We could show them in some separate legacy list with unknown usernames. Perhaps easier but less useful.

Alternatives:

• Grid
• Cross-fade
• Stacked with peeking, like GitHub

See https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors.

• Check what that looks like in the webhooks and if we handle it
• Doc it on the settings page
• Maybe change our pair commit tools to use this

If a webhook is re-submitted, we should silently not create duplicates.

Gets env at compile-time, so maybe not a good choice in some cases, e.g. for API keys. If we e.g. change the Heroku API key, I believe it wouldn't actually change until the next deploy.

Or hardcode it, but maybe not to my name.

If we move this project into devbox, we could use its convention.

Or we could give instructions for setting up a user by a certain name ("remit" maybe) and default to that.

Like b6c8de2.

Happened to at least me and Olle overnight. We also had some DB timeout errors logged. My guess is Heroku did something that caused these errors. The clients got this error page at some point from the DB timing out, and nothing on the page attempts to recover from that.

So we could for example look into customising the error page

to have some JS to attempt reloads, maybe.

Also look in the old Review repo – I seem to remember seeing some additional error or retry handling in that one that may or may address a similar situation.

Have started in a branch but am a bit blocked by phoenixframework/phoenix_live_view#990 (previously: phoenixframework/phoenix_live_view#960).

This would fix the issue where comments currently reload (the liveview remounts) when filtering (= when params change).

• Dataclip
• Git hooks
• Git hooks being set up in devbox
• Remove from dashboard – ideally by getting rid of it in CI/Pipeline (?) rather than by ignoring it in dashboard_frontend
• Heroku
• Heroku: review-on-review
• DB (take backup?)
• Heroku "auctionet-remit" (Stimulus Reflex lab?)

As seen in barsoom/gridlook@1a5a0dd. Gets a broken avatar. Just treat it as though it was called "dependabot"?

z-index? Move tooltip to bottom instead of top?

See discussion: https://auctionet.slack.com/archives/CF9SAN79V/p1593177290476000

Both dynos and DB.

If we make it a prod-class DB, we should also change the maintenance window.

Such as https://github.com/barsoom/live_bidding/commit/c74404360d1397bc5cc4b88dc7be7f4579ab1637 which had

      "author": {
        "name": "…",
        "email": "…"
      },
      "committer": {
        "name": "…",
        "email": "…"
      },

with no username passed, and no plus addressing in the emails.

Have asked the dev in question if they know the circumstances: https://auctionet.slack.com/archives/CF9SAN79V/p1591976514145100?thread_ts=1591945393.083400&cid=CF9SAN79V

Looked in DB: we stored authors: [] on the commit.

Simplest solution might be to just make it an explicit, documented requirement that at least one committer/author needs to have a GitHub username, or commit with plus addressing.

We could show "[warning triangle] Unknown username" maybe, with a tooltip like "Committed by Foo Barson with no GitHub username, blabla, Remit won't be able to blabla…".