Thursday before last at DrupalSouth 2023 codesprint I knocked together a prototype of PatchWatch, a tool to consolidate information about patches applied to a set of projects. [Earlier post on patchwatch here]((https://chris.bur.gs/composer-drupal-patches-report/).
This last weekend, I revisited the prototype and fleshed it out some.
The tool now is a Symfony console command with three or four commands implemented:
patchwatch:report-composer-patchesreports on cweagans/composer-patches patches from acomposer.jsonorpatches-filepatchwatch:report-drush-makereports on patches from an old styledrush.makefilepatchwatch:report-patch-directoryreports on a directory of patchespatchwatch:report-patch-packagereports on a directory of patches in patch-package format
It has some test coverage in tests/src/ which parses sample input data from tests/fixtures/.
I also added a caching layer in the Guzzle client, so we don't annoy HTTP endpoints too much while querying for data about issues related to patches.
The core function of "read patch input data and output something structured" works, now. The tool does not yet collate several sources into a single "high level" view, but that should be straightforward to add. I want to spend a bit of time reflecting on the structure of the patch listings before I do that.
I've added some Gitlab CI and this includes a "demo" job which shows the output of the commands when using the test fixture samples as inputs. See the demo job in the latest pipeline for this.
I also had a play with taking the generated output and throwing it at a store ... having heard a bit of buzz about Metabase from some team members lately, I threw the generated JSON at MongoDB and then yoinked that into Metabase, which was interesting. See Lando + Metabase for some notes on that!
Next steps
Configurable patterns
I am thinking about how to take a listing of patches (which will have some basic data such as a patch URL/path and possibly a label), and "enrich" the list of patches into something more full featured. Since different organisations will treat this differently, there is probably room for configurable pattern matching, eg to help an org discern that #123: Bugfix for frobnitz adapter. It may also make sense here to specify that there's no default behaviour and that all references should be canonical (drupal/drupal#123) ... but flexibility here would make adoption easier.
Plugins for informing patch data
The other thing that's on my mind is in the Patch reader where we apply "informers" to the source data. At this point we might want to pass the patch data (an array with a filename) into a set of transformers which might "enhance" the data ("I recognise an issue number in that filename pattern; I will add to the patch data information retrieved from an upstream tracker."). There's only one such plugin at present (for Drupal issues) and I want to work out the right pattern for making this easier to adapt, and possibly allow for user-specific plugins as well.
Support for forks as well
Later I plan to add support for forked repositories as well. Initially I was taking the opinionated position that forks are a worse strategy, and this tool should focus on patch handling. Now that I've implemented a few source adapters, I realise that implementing Git support wouldn't be that hard, and it would make the tool useful to folks who have a local fork of an upstream project.
(I still recommend to not adopt the strategy of long-lived forks, but it's a thing people do, and we can allow for that.)
Credits
Thanks to the authors of the following open source tools which I've been reading and considering as I implement this. I'm grateful to be building on what you've shared.