design of API-based interface

[pvh]

Okay, so I think what I will do is the following in pgcommitfest2 to support this app:

Phase 1: Commitfest API

Add a simple JSON api that supports querying commitfests, submissions (scoped to a commitfest?), and maybe attachments/patches. Modify the existing app to query those APIs and otherwise behave the same. Release this stuff. (cc/ @mhagander) Can you remind me why you don't look at the commitfest app's attachments? I know you said somewhere but it is lost to me now.

Phase 2: Test Result API

Add a table to pgcommitfest that lets you post back results of your test runs to show up on the submission page, and an API to submit to said table. We might want to have an API key that protects you from submitting bad results and lets us tell who is submitting them... but I don't know that this really matters. What benefit (or even real inconvenience) could rogue submissions have?

Future Work

Improve patch handling.

I haven't got a concrete plan here, but your script based approach is either better or worse than what's in the pgcommitfest app now so either one or the other should be shored up or improved.

Separate Branch Creation from Test Runs

If we can generate canonical-ish git branches (and/or let patch authors submit them via the CF app) we should be able to simplify the mechanism of the app pretty significantly here.

Meta thoughts

If this thing works well, we shouldn't have to enforce standards on the community for patch format. People will be naturally incentivized to post patches in a format that the testing tools will automatically pick up.