April 2020 Stats
First, the stats:
Total Installations: 3 Scheduled PRs Merged: 8 PRs Merged: 9 (inc. scheduled)
This month involved another round of refactoring to simplify the code and make it more re-usable. A lot of the flows now center around Github's Pull Request statuses which makes a lot of code re-usable across the different features. Although this took time, it was rewarding to see features get developed in 1-2 nights after all this groundwork was done.
Performance issues continue to crop up, with some requests still creeping into low double-digit seconds to complete. Improvements have been made here with database indices and early returns, but there are two main items remaining:
- A lot of requests involve hitting the Github API which takes time. Long-term a lot of these should be moved into background jobs but at present it's manageable.
- Heroku's Hobby-level postgres performance
I wrote an earlier piece looking at Heroku's Hobby-level Postgres performance here in more detail, but suffice to say that sub-second response times will not be guaranteed until I migrate to another offering (either self-hosted or Heroku's $50 plan). For now I'm opting to continue on the Hobby-level plan until the current performance is unusable or GitArborist brings in enough revenue to cover the cost of upgrading. It still surprises me that Heroku does not have a lower-cost tier for truly production-grade hosted postgres.
New Features In April 🎉
I was able to launch several new features this month:
- Marking a PR dependency
I considered this part of a “minimum viable product”; the ability to mark a PR as a dependency without automatically merging the target PR. It adds a ‘pending’ status to the PR that will be updated to success when the dependecy PR is merged (or failure of the dependency PR is closed).
- Merge when green
Automatically merges a PR once the status is green (i.e. CI has passedc).
- Automatically merge all PRs from a given user
Mainly targeted at dependabot. This was another ‘scratch my own itch’ feature as it means I no longer have to manually sift through dependabot PRs. This has perhaps a limited appeal for my target paying audience though, as I doubt many production apps would want dependency-changing PRs merged automatically unless they have very strong faith in their CI.
May Roadmap 🧭
I would like to tidy up the way PR statuses are handled. Unfortunately, Github does not allow a status to be deleted, so changing an existing status has to be done by marking the previous one as success and creating a new one (or re-using the context and changing description). Currently, this causes some issues with things like changing the scheduled merge time of a PR. Basically, the whole update-or-replace-a-status process needs some thought and rework to make it a more polished experience.
I'd also like to do some investigation on server-executed Git commands to allow things like rebasing a PR. This has two drawbacks however; firstly is doing this with Heroku's ephemeral file system, the latter is that pulling down arbitrary code like this uses bandwidth and thus could potentially increase hosting costs.