Dear GitLab devs,
first, thank you for GitLab, it is a fine piece of software!
Even though GitLab generally works for us rather well, it
looks like there are some problems in GitLab project events
API.
First, a bit of context.
Our busy little team of 10 developers runs our projects on
top of GitLab and we would like to remind ourselves when we
forget to push or send merge requests with the following
simple algorithm:
1. Get the list of project events since, say, 3 days.
2. Get push and merge request author emails from the list.
3. Take set difference of the list with project developer
email list and send remainder emails to people who are
part of the complement.
GitLab API looked like a fine way of handling this, so I
rolled up my sleeves, installed pyapi-gitlab and started
querying:
gl = Gitlab(conf.GITLAB_SERVER, conf.GITLAB_TOKEN)
events = gl.getprojectevents(conf.GITLAB_PROJECT_ID)
So far, so good - got a nice list of events. The API docs in
doc/api/projects.md promise that events are 'sorted from
newest to latest'. Great, exactly what we need, let's take a
look:
print events[0]
First, event timestamp is missing so it is hard to tell when
the event occurred. I printed more of the list and compared
with events on project dashboard in the web view - and
discovered that it was not the newest event.
Looking at lib/api/projects.rb I saw that
get ":id/events" do
limit = (params[:per_page] || 20).to_i
offset = (params[:page] || 0).to_i * limit
events = user_project.events.recent.limit(limit).offset(offset)
The problem is clearly visible here - `paginate` is not used
and default page is 0. This is inconsistent with other
paginated calls and contradicts with doc/api/README.md that
specifies 1 as default page number.
Seeing the cause of the problem I did run
events = gl.getprojectevents(conf.GITLAB_PROJECT_ID, page=0)
print events[0]
and got the expected result.
---
In short, the following would improve things:
* use `paginate` with `get ":id/events"` or make 0 default for
other paginated calls as well and update docs
* expose `created_at` field in Events in lib/api/entities.rb
* expose `created_at` and `updated_at` field in MergeRequest
in lib/api/entities.rb while at it as well.
How do you feel, can I file these issues as bugs and would
you accept merge requests?
Best,
Mart Sõmermaa
--
You received this message because you are subscribed to the Google Groups
"GitLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.