[PATCH RFC] events-api: allow filtering by date
aconole at bytheb.org
Thu Jun 15 23:57:30 AEST 2017
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  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
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
> PS: I published a (now rather outdated) outdated blog  and talk  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.
>  http://www.django-rest-framework.org/api-guide/pagination/#cursorpagination
>  https://that.guru/blog/patchwork-and-ci-in-a-tree/
>  https://speakerdeck.com/stephenfin/mailing-list-meet-ci
More information about the Patchwork