On Sun, Jan 3, 2016 at 11:25 AM, Erik Rijkers <e...@xs4all.nl> wrote:
> On 2016-01-03 10:06, Magnus Hagander wrote: > >> On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers <e...@xs4all.nl> wrote: >> >>> an erroneous '</p>'. It should be '</td>'. >>> >> > Is there a particular thing you're trying to parse the data out for? As in >> is there some data that we should already be providing in a structured >> format instead of requiring parsing it out? >> >> > I'm just trying to set up a way to compile and test all outstanding > patches. > > It might perhaps be handy to have that patches table's columns somewhere > (in tab-separated, perhaps?). > > Of course most of the work is downstream of that download, anyway. Compile > & check (also rather simple) but especially to have some loading/testing > (both general, and specific to the patch's goal). > > Well, if you get everything else turned into something that works well and is generally useful, then we can definitely look at putting up an API endpoint that you can call to get the data in a structured format rather than parsing it out of the HTML (which might randomly break if we make changes..) Actually having the ability to do that was one of the things we talked about early on (an API and just having a job somewhere that could auto-post the status), but nobody actually got around to doing it.... One of the most basic ideas then would be to just add a state to a patch which could be set to "fails to apply" or "fails to compile" for example, by a job, and an API to basically pick patches off a queue (which would serve up new versions etc automatically). If you're interested in turning it into something like that, feel free to ping me off-list for a discussion of the (very small) amount of things discussed back then. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
