Dinghy digests

Sunday 13 March 2022

Dinghy is a tool I wrote to summarize activity on GitHub issues and pull requests. You configure it to look at certain GitHub resources over a recent time period, and it produces a compact digest of what’s been happening:

A sample Dinghy digest

I started dinghy because I needed a way to see disparate activity in repos at work, and it’s been useful for that. So far it has the features I’ve needed. Maybe others will find it useful too.

It was also a chance to dig into the GitHub GraphQL API. GraphQL syntax is oddly strict (why can’t I define a fragment that isn’t used?), and GitHub’s implementation has quirks (sometimes requesting data with the wrong token scope is an error, other times it returns None). I can see the advantage of being able to request a graph of data with one request rather than a REST API that forces me to walk the graph myself, but paginating along multiple axes is still a pain (listing issues, and also comments on issues).

The code is still a mess in some places, and I haven’t figured out how to test most of it. But it was interesting to reverse engineer how GitHub decides on the text color for labels (they compute it in CSS!)

Comments

[gravatar]

Seems super interesting!

What’s your opinion on relaxing domain restriction on the URL checks in method_from_url() in order to allow Enterprise instances of Github?

[gravatar]

I have absolutely no experience with Enterprise. Can you open an issue (https://github.com/nedbat/dinghy/issues) so we can work out the details? Thanks!

[gravatar]

Can you open an issue

Gladly! Here you go

Note: I did a test manually replacing all github.com instances in digest.py with my company’s instance name, but still got an “Unauthorized” error with a stack trace. I believe this is due to a misconfiguration on my company’s server:

They’re using the same TLS cert for “customdomain-com” as well as “api-customdomain-com”, but the certificate does not list “api-customdomain-com” as an alternate name, AND the server is using HSTS. As a result, browsers give me the scare privacy error message and refuse to go.

But I can call API endpoints (including the GraphQL API) with my token using POSTMAN, so I know the token is good and the server supports this API.

I’ll work with IT to fix the TLS cert and re-do my test - although it may be a while before I get it fixed.

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.