Re-using this project on resin.io

[jviotti]

Hi guys, I'm Juan Cruz Viotti from resin.io.

We've been building a dashboard to evaluate the health of our numerous GitHub repositories, and found this awesome project, which was exactly what we're trying to achieve. We have some more "checks" we would like to add, so I'd love to discuss how we can contribute back, so you can hopefully benefit from our improvements as well! These are some of the things we had in mind:

• We want to see what CI services each project is using (we currently use a mix of Travis CI, Appveyor CI, Circle CI, Jenkins, and recently a self-hosted Councourse CI instance, depending on the use case)
• We built a GitHub app called "VersionBot," which is helpful to enforce more constraints during PR time, like required number of approvals, and also to automatically perform version bumps, CHANGELOG generation, etc (you can read more about it here: https://github.com/resin-io-modules/resin-procbots/blob/master/docresources/VersionBot/versionbot.md), so we'd also love to see how much VersionBot is adopted across the company
• We'd like to add some analytics about GitHub stars. We currently have a (semi-manual) approach to calculate the average number of starts we get in a project per-hour, and then the relative rank compared to other similar projects that were created at more or less the same time

Now, we're also working on Landr, a project to auto-generate landing pages for GitHub repositories that relies on popular open source conventions rather than configuration. The project is able to discover contributing guides, changelogs, releases, documentation etc and create a custom website for it. The mantra is that the best you adhere to good conventions, the more the website will do out of the box for you.

Since Landr relies on parsing the contents of the repo, we began to work on a standalone Node.js module that given a repository, returns a big JSON object including everything it found about it, like versions, configured CI services, etc. The plan was then to build the repo health dashboard also on top of this module.

So some questions:

• What would you think about making use of the repo "discovery" module in project-repos?
• Would it be okay to borrow some of the code from https://github.com/ipfs/project-repos/blob/master/src/RepoMatrix.coffee to help building this module?
• What do you think about adding the features mentioned above to project-repos, plus a way to configure what columns the dashboard should show by default, so every user can deploy project-repos with the things he cares about?
• What would be the best way for us to also deploy this repo for our organisation? Could we modularise it instead of forking it?

Thanks a lot in advance, and looking forward to hear your thoughts!

[harlantwood]

Sorry for the delay, just seeing this now.

I recommend forking, as this project is not very active. Certainly, use freely! Happy to have it in use. Interested to see what you build -- or by now have already built!

[RichardLitt]

Don't apologize, @harlantwood - the fault for not responding to this lies with me! I should have responded sooner, but this fell off of my radar, too.

Of course, you can fork. Please do!

I forked it, myself, and iterated on it quite a bit. You can see that fork, here: mntnr/dashboard. The main reasons I forked it were because I wanted to switch to JavaScript over CoffeeScript; I felt bad editing this repo too much for non-IPFS things; and I wanted to overhaul the design entirely. I haven't worked on it in a bit, but it is stable and working last I checked.

I think all of the features you mention sound awesome. I think that my dashboard may be more modular and easy to work with, but I'm biased. @harlantwood perhaps we can cycle those edits back in?

[harlantwood]

Hi @jviotti curious if you made progress with this or your own version.

FYI I have started a (currently toy level) server-side Elixir version here: https://github.com/harlantwood/matrix

My intention with going server-side is go get around API rate limiting with smart throttling and caching. No promises; currently it is just a good way for me to learn Elixir.

[jviotti]

Hi everyone,

Thanks for the response and sorry for the late response (I took a long vacation). We did some progress on this front, but not much. We've been working on a more generic module to "interrogate" a repo for certain things (https://github.com/resin-io-modules/scrutinizer), and I'd love to extend it to cover the things that you're checking for in this repo.

We're piping this data to an internal database and dashboard (its private, so I can't share the link), but I'd love to take another look at this repo now that I got the green flag :)