mirage / ocaml-github

GitHub APIv3 OCaml bindings
ISC License
100 stars 61 forks source link

Problem while parsing event hook metadata #223

Open Aaylor opened 5 years ago

Aaylor commented 5 years ago

While receiving data from the GitHub event push, we encounter two problems during the parsing of the event metadata.

Type problem while parsing the object repository

There is an inconsistency coming from GitHub for two specifics fields: pushed_at and created_at. The push event always sends the fields pushed_at and created_at as integers (EPOCH), instead of string values as expected from the atd file:

type repository = {
  ...
  ?pushed_at: string option;
  created_at: string;
  ...

The documentation shows that both field must be consider as integers.

I took a quick look at others event payload, and the push event seems to be the only one where those fields are integers...

(The error is different from the issue #136)

Missing record fields created_at, id

The type event_hook_metdata expects two specifics field from the hook payload: created_at and id:

type event_hook_metadata = {
  ...
  created_at: string;
  ...
  id: int <ocaml repr="int64">;
} <ocaml field_prefix="event_hook_metadata_">

Those two fields does not appear anymore in both event I have tested: push and ping. I've also quick checked the documentation from other events, and those two fields does not appear. Maybe they can be consider as optional, or they should be deleted ?

I'm not really used to work with atd, but I may try to write a patch for it.

avsm commented 4 years ago

Considering them optional sounds good to me... not much more we can do really if they vary. PRs welcome for this (and indeed, would you like to get write access to the repository @Aaylor? You've been consistently submitting bug fixes here).

Aaylor commented 4 years ago

It's been a while since I checked if something changed here (even if I believe it did not change), but I'll take a look and apply patches for both problem.

Why not, having write access may allow to work on further improvement (we plan maybe to use more GitHub API features) quicker. In that case, should I continue working with PRs in order to get review (and merge them myself after review) ?