This is an attempt to fix#133.
Previously, we just clobbered the recent GUIDs with the lastest response
every single time, assuming that Atom/RSS feeds would consistently return the
same items. This appears to not be the case. In the wild, the number of items
returned on a single request can vary (sometimes even being 1 or 2 when usually
it is 50!).
This patch alters *how many* and *which* GUIDs we keep between requests, in an
attempt to prevent sending old news for buggy RSS feeds.
In the wild it looks like some RSS feeds will occasionally return 0 items
to requests *but not return an error*. This previously meant we would clobber
our knowledge of recent GUIDs with the empty set. This meant that the next
successful poll would resend the **entire** RSS feed.
Now broken down into:
- `labels` : Labelling/Unlabelling issues/PRs
- `milestones` : Milestoning/Demilestoning issues/PRs
- `assign` : Assigning/Unassigning issues/PRs
This is broken down in the guts of parsing the webhook event such that it
appears to be a unique `X-GitHub-Event` type.
In the spirit of "if you have to do something 3 times then factor it
out", make a testutils package to put all the `RoundTrip` boilerplate.
I don't overly like having test packages, especially mixed in with
code, but I don't see a nicer way of doing this without ending up
with a sprawling mess of copypasta'd test boilerplate which will
be an absolute nightmare to maintain.
I think this is the lesser of two evils.
We exclusively view logs using `less` and `tail`. These do not read JSON well.
Logging as JSON makes it a PITA to read logs and debug problems. We do not
appear to make use of JSON logging, and have no good terminal-based
structured log viewer either.
As a result, I've now removed JSON logging from this project and replaced it
with the standard `TextFormatter` (colors off). This still logs in a structured
way:
```
time="2016-11-18 16:25:46.787373" level=info msg="Got filter ID" filter=717 syncing=1 user_id="@goneb:localhost"
time="2016-11-18 16:25:46.787525" level=info msg="Starting sync" next_batch="s26928_287972_2_1029_26_1_2" syncing=1 user_id="@goneb:localhost"
```
So we can still analyse logs sanely at a later date should we need to. This
feels like the best compromise here between pragmatism and ideals.