[PATCH RFC] events-api: allow filtering by date

[Aaron Conole]

Stephen Finucane <stephen at that.guru> writes:

> On Wed, 2017-06-14 at 14:16 -0400, Aaron Conole wrote:
>> Aaron Conole <aconole at bytheb.org> writes:
>> 
>> > This commit allows users of the REST API to query for events based on
>> > the date field.  This will allow utility writers to select a smaller
>> > subset of events when polling.
>> > 
>> > Signed-off-by: Aaron Conole <aconole at bytheb.org>
>
> I think I missed this initially because I'd intended to use cursor-based
> pagination [1] for '/events'. Cursor-based pagination would be beneficial in so
> far as it allows us to grab a pseudo-permalink to page of events, which isn't
> possible with page number-based pagination because the page numbers can change
> way to darn quick. However, it does make '/events' unique in how it does
> pagination. I can go either way with this, and can submit an RFC for this this
> evening, if it would help to compare the two.

Sure; I'm fairly inexperienced with web development, so I don't
understand the nuance between the two approaches.

>> > ---
>> 
>> It should be noted that my motivation for this is to implement a git-pw
>> event poll command for CI integration.
>
> Hmm, so I'll admit I'm not overly fond of this idea. I'm trying to keep git-pw
> as a client side tool for git-patchwork interaction and not a catch-all
> application for all things Patchwork like pwclient currently is. "Create a
> check" doesn't sound like something Acme developer would be doing from within
> their Git repo.

Okay.  I'm approaching this from the angle of "I want to do X, how do I
achieve it today." :)  I thought it made sense to have a running stream
of events that I could poll on, especially since I envision the workflow
like:

1. Wake up
2. Do human things
3. git pw events list --category=series-new* --since=<last time>
4. scroll through that work (ie: git pw series apply X, review, comment,
   etc. keep going until all are done)
5. go to 3.

Maybe I'm not thinking about events correctly, though?

Then I could basically make steps 3,4,5 be done by a machine instead,
and have it run things like checkpatch, make check, etc.  I'll look at
the snowpatch tool, as well.  Thanks.

>> If you think there's a better way of achieving this, let me know.
>
> Any chance you could keep this as a separate tool? I'd be happy to spin out
> some of the 'git-pw' code into a 'patchwork-api' library, if that would help
> (though there really isn't much to spin out). Alternatively, some of the folks
> here were working on a "snowpatch" tool. I've no idea how far along it is nor
> how it works, but it could be a good option if it's still progressing.

Sure thing;  it doesn't have to be part of git-pw;  I was looking at the
details from the freedesktop fork of patchwork [A] and it seemed like a
useful functionality.  As for spinning it out, that's probably a good
idea.

> Stephen
>
> PS: I published a (now rather outdated) outdated blog [2] and talk [3] on how
> to do basic interaction between the REST API and Jenkins a while back. Might be
> worth looking at if you haven't seen them already.
>
> [1] http://www.django-rest-framework.org/api-guide/pagination/#cursorpagination
> [2] https://that.guru/blog/patchwork-and-ci-in-a-tree/
> [3] https://speakerdeck.com/stephenfin/mailing-list-meet-ci

[A] http://patchwork-freedesktop.readthedocs.io/en/latest/testing.html