Open CapriciousRebel opened 2 years ago
This sounds great.
Let's maybe start by adding an option to generate HTML locally, and then figure out how to make it easy for folks to consume. Since this requires an API token, it would probably need to be a forked github repo with a cron action that deploys to github pages - which would mean we'd need to make another repo so that people could fork it.
I like the idea of starting with an option to generate the HTML locally, that would be good for a quick POC. However making a repo that needs to be forked by users and running on GitHub actions to use sounds like a tedious user experience, also, having people run a GitHub action every time they try to run a command sounds quite slow to me.
I propose we go with the following flow:
repo-report --gui
] http://localhost:5009
where the user is now fully authenticated]The user can choose to use repo-report as a cli-only app at step-2.
In order to generate the webapp on the system, we could use the following tech stack:
Backend:
Frontend:
Hey If you'd like a partner to work on this, I am up for working on the web app! @CapriciousRebel hmu.
@rosekamallove Of course! I would love that.
Can we probably stup a meet or something?
Sure, let's move the scheduling discussion to discord channel!
Since there is going to be a backend in the web app we can also add the ability to edit those metrics from the dashboard itself. It would save to hassle to find that repo on GH and then edit the metric.
Opinion required @ljharb
I don’t think it’d be very scalable to run a backend for this - and since GitHub api tokens are unique to users and also have points quotas, the web app has to be able to make requests on a user’s behalf. I’m not sure logging in with GitHub provides this or not - but GitHub actions does.
With the the forked repo approach, the action would be a cron - meaning, it automatically runs on a schedule (once every 10 minutes, say) without any user action.
My issue with cron job actions is that it updates once at every time interval, so say, I open the portal, find an issue, solve the issue. Now I have to wait for the cron to update the page for me. Instead, I would prefer the update to happen instantly on refresh or live( using a webhook maybe :D ). Perhaps Instead of writing an entire backend, we can always write APIs that talk to the GitHub API from the frontend itself. The personal access token could be taken as an input and stored safely in the browser storage (perhaps as a cookie)
Requiring a user to manually provide an API token to a webpage, and then potentially storing it unsafely (if the computer is shared, for example) seems tricky.
That's a fair point that you'd have to wait for it to refresh to get new results.
We can always ask the user a prompt "Remember me?" User says yes => store as a cookie User says no => store as a session variable
Summary of our last meeting:
The best approach would be to implement this functionality in stages as follows: Stage 1: Implement static webpage generation:
Stage 2: Implement dynamic webpage:
repo-report --gui
.Both of these cases use the token saved in the environment variables and thus eliminate any browser-storage-based security risks discussed above and in the meeting.
For stage 3 we could explore building repo-report as a third-party app, deployed on a domain that works via the GitHub OAuth flow and provides a one-stop destination for users to use repo-report, but of course, providing repo-report as a service would involve deployment costs, security risks, regular maintenance, and other costs as well.
I'd actually have 4 stages - stage 2 is "implement a static webserver", and stage 3 is "make that webserver dynamic", and then stage 4 is a hosted solution.
Currently, Repo report is a cli-only tool. Having the tool in the CLI itself is great for the user who loves to live in the terminal. However, displaying tables with multiple columns in the terminal breaks the UI when the columns overflow. Following are a few examples (tested on macOS terminal):
Overflowing columns for the default run command with no options passed.
Overflowing columns for the run command with the
--all
option.It is very difficult to be able to read what each tick represents without scrolling all the way to the top to see what column does the tick belongs to.
Expanding the terminal to full screen does help slightly, but the columns still overflow.
The only viable solution to this is by reducing the text size/zooming out of the terminal, but that makes the text too small to read.
I propose we create a single-page, responsive web application for repo-report using the latest frontend development tools. Following is a rough markup of the UI I feel would work the best for this use case (note that I am not a designer, and this is just an example of how I imagine the UI/UX):
Features:
Things that need to be discussed further: