summaryrefslogtreecommitdiff
path: root/spec/requests/api/discussions_spec.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@13-2-stable-eeGitLab Bot2020-07-201-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-04-031-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-211-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-12-231-0/+12
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-10-291-0/+2
|
* Eliminate Gitaly N+1 queries with notes APIsh-eliminate-gitaly-nplus-one-notesStan Hu2019-08-221-51/+3
| | | | | | | | | | | | | | | | | | | | | | Similar to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31834, we see that in https://gitlab.com/gitlab-org/gitlab-ce/issues/65957 there can be hundreds, even thousands, of Gitaly requests in the `/api/:version/projects/:id/merge_requests/:noteable_id/notes` endpoint. Previously, the API to retrieve notes generated hundreds of Gitaly calls to determine whether a system note should be shown to the user. It did this by: 1. Rendering the Markdown 2. Extracting cross-references from the Markdown 3. Issuing a Gitaly `FindCommit` RPC for every reference to validate that the commit exists. The last step is unnecessary because we don't need to display a commit if the user doesn't have access to the project in the first place. `RendersNotes#prepare_notes_for_rendering` is already used in `MergeRequestsController`, which is why we don't see N+1 Gitaly calls there. We use it here to optimize the note redaction process.
* Fix failing N+1 spec in spec/requests/api/discussions_spec.rbStan Hu2019-08-151-3/+5
| | | | | | This test was failing in EE because the API helper `get()` creates a personal access token each time it's run. We can avoid that by pre-creating a personal access token and passing it each time.
* Eliminate many Gitaly calls in discussions APIStan Hu2019-08-151-0/+53
| | | | | | | | | | | | | | | | | | | | Previously, the API to retrieve discussions from merge requests often generated hundreds of Gitaly calls to determine whether a system note should be shown to the user. It did this by: 1. Rendering the Markdown 2. Extracting cross-references from the Markdown 3. For cross-references that were commits, a Gitaly FindCommit RPC would be issued to validate that the commit exists. The last step is unnecessary because we don't need to display a commit if the user doesn't have access to the project in the first place. `RendersNotes#prepare_notes_for_rendering` is already used in `MergeRequestsController`, which is why we don't see N+1 Gitaly calls there. We use it here to optimize the note redaction process. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65957
* Fix typos in the whole gitlab-ce projectYoginth2019-05-201-2/+2
|
* Allow replying to an individual note in the APIallow-replying-to-individual-notes-from-apiSean McGivern2019-05-061-2/+2
| | | | | | If you can do this in the UI, you should be able to do it in the API. If a discussion is not a single note discussion, or it is replyable, you can reply to it.
* Enable the Layout/ExtraSpacing cop56392-enable-the-layout-extraspacing-copRémy Coutable2019-01-241-1/+1
| | | | Signed-off-by: Rémy Coutable <remy@rymai.me>
* Merge request and commit discussions APIJan Provaznik2018-05-011-6/+27
|
* Add discussion APIjprovazn-apiJan Provaznik2018-03-071-0/+33
* adds basic discussions API for issues and snippets * reorganizes notes specs (so same tests can be used for all noteable types - issues, MRs, snippets)