Commit Graph

31 Commits

Author SHA1 Message Date
GitLab Bot f76e1491c9 Add latest changes from gitlab-org/gitlab@master 2024-05-08 18:16:44 +00:00
GitLab Bot 61cb988554 Add latest changes from gitlab-org/gitlab@master 2023-11-23 15:13:51 +00:00
GitLab Bot cc4e1c884c Add latest changes from gitlab-org/gitlab@master 2023-01-20 18:10:05 +00:00
GitLab Bot 5fe2d74e00 Add latest changes from gitlab-org/gitlab@master 2022-12-09 09:08:55 +00:00
GitLab Bot e129eff883 Add latest changes from gitlab-org/gitlab@master 2022-07-05 18:08:43 +00:00
GitLab Bot 2d66c59d59 Add latest changes from gitlab-org/gitlab@master 2021-02-02 18:09:42 +00:00
GitLab Bot fe25c98fa8 Add latest changes from gitlab-org/gitlab@master 2020-07-01 21:08:51 +00:00
GitLab Bot fa7ac2663b Add latest changes from gitlab-org/gitlab@master 2020-06-24 06:09:01 +00:00
GitLab Bot 1f1e53f43f Add latest changes from gitlab-org/gitlab@master 2020-05-28 15:08:02 +00:00
GitLab Bot 729e3765d5 Add latest changes from gitlab-org/gitlab@master 2020-03-24 12:09:42 +00:00
GitLab Bot 2a040e2655 Add latest changes from gitlab-org/gitlab@master 2020-02-21 12:09:07 +00:00
GitLab Bot 364f6f2e33 Add latest changes from gitlab-org/gitlab@master 2020-01-20 15:09:18 +00:00
GitLab Bot bbe2430603 Add latest changes from gitlab-org/gitlab@master 2019-12-18 18:08:04 +00:00
GitLab Bot abfafe3c57 Add latest changes from gitlab-org/gitlab@master 2019-10-29 00:06:10 +00:00
GitLab Bot 6b75320f52 Add latest changes from gitlab-org/gitlab@master 2019-10-17 12:07:33 +00:00
Dinesh Panda 75edb86941 Do not include ApiHelpers again in spec/requests/api 2019-09-11 09:37:20 +00:00
Małgorzata Ksionek 1103c09776 Add new api class for projects events
Refactor api events class to use external helper

Move specs from old class

Add changelog and magic string

Refactor events class to be more explicit

Remove blank line
2019-04-24 17:20:11 +02:00
Oswaldo Ferreira ca884980ee [CE] Support multiple assignees for merge requests
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
2019-04-08 18:40:00 -03:00
Jasper Maes bf73520079 convert specs in javascripts/ and support/ to new syntax 2018-12-21 10:10:26 +01:00
blackst0ne b44a2c801a Update specs to rails5 format
Updates specs to use new rails5 format.

The old format:
`get :show, { some: params }, { some: headers }`

The new format:
`get :show, params: { some: params }, headers: { some: headers }`
2018-12-19 10:04:31 +11:00
Bob Van Landuyt 28acd2b087 Hide confidential events in ruby
We're filtering the events using `Event#visible_to_user?`.

At most we're loading 100 events at once.

Pagination is also dealt with in the finder, but the resulting array
is wrapped in a `Kaminari.paginate_array` so the API's pagination
helpers keep working. We're passing the total count into that
paginatable array, which would include confidential events. But we're
not disclosing anything.
2018-12-17 18:47:53 +01:00
Warren Parad 8aed9f08fc
Add authenticate to events api. fix #49255 2018-08-16 19:52:52 +02:00
Stan Hu 6f4a0a92e6 Eliminate N+1 queries with authors and push_data_payload in Events API 2018-06-05 07:22:07 -07:00
Jacopo 2f40dac352 Refactor `have_http_status` into `have_gitlab_http_status` in the specs 2017-10-20 10:13:18 +02:00
Yorick Peterse 0395c47193
Migrate events into a new format
This commit migrates events data in such a way that push events are
stored much more efficiently. This is done by creating a shadow table
called "events_for_migration", and a table called "push_event_payloads"
which is used for storing push data of push events. The background
migration in this commit will copy events from the "events" table into
the "events_for_migration" table, push events in will also have a row
created in "push_event_payloads".

This approach allows us to reclaim space in the next release by simply
swapping the "events" and "events_for_migration" tables, then dropping
the old events (now "events_for_migration") table.

The new table structure is also optimised for storage space, and does
not include the unused "title" column nor the "data" column (since this
data is moved to "push_event_payloads").

== Newly Created Events

Newly created events are inserted into both "events" and
"events_for_migration", both using the exact same primary key value. The
table "push_event_payloads" in turn has a foreign key to the _shadow_
table. This removes the need for recreating and validating the foreign
key after swapping the tables. Since the shadow table also has a foreign
key to "projects.id" we also don't have to worry about orphaned rows.

This approach however does require some additional storage as we're
duplicating a portion of the events data for at least 1 release. The
exact amount is hard to estimate, but for GitLab.com this is expected to
be between 10 and 20 GB at most. The background migration in this commit
deliberately does _not_ update the "events" table as doing so would put
a lot of pressure on PostgreSQL's auto vacuuming system.

== Supporting Both Old And New Events

Application code has also been adjusted to support push events using
both the old and new data formats. This is done by creating a PushEvent
class which extends the regular Event class. Using Rails' Single Table
Inheritance system we can ensure the right class is used for the right
data, which in this case is based on the value of `events.action`. To
support displaying old and new data at the same time the PushEvent class
re-defines a few methods of the Event class, falling back to their
original implementations for push events in the old format.

Once all existing events have been migrated the various push event
related methods can be removed from the Event model, and the calls to
`super` can be removed from the methods in the PushEvent model.

The UI and event atom feed have also been slightly changed to better
handle this new setup, fortunately only a few changes were necessary to
make this work.

== API Changes

The API only displays push data of events in the new format. Supporting
both formats in the API is a bit more difficult compared to the UI.
Since the old push data was not really well documented (apart from one
example that used an incorrect "action" nmae) I decided that supporting
both was not worth the effort, especially since events will be migrated
in a few days _and_ new events are created in the correct format.
2017-08-10 17:45:44 +02:00
Rémy Coutable 164e660411
Fix a broken Events API spec
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-08-08 16:27:38 +02:00
sue445 7bc0486162 Expose noteable_iid in Note 2017-08-08 11:31:55 +00:00
Robert Speicher 72a7b30c9f Change all `:empty_project` to `:project` 2017-08-02 17:47:31 -04:00
Rémy Coutable ddccd24c13 Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-07-27 14:31:53 +02:00
Mark Fletcher 3c15f0eae7 Accept a username for User-level Events API 2017-06-06 20:16:41 +08:00
Mark Fletcher ad3e180ed3 Introduce an Events API
* Meld the following disparate endpoints:
 * `/projects/:id/events`
 * `/events`
 * `/users/:id/events`
+ Add result filtering to the above endpoints:
 * action
 * target_type
 * before and after dates
2017-06-06 20:16:41 +08:00