Compared to the merge_request_diff association:
1. It's simpler to query. The query uses a foreign key to the
merge_request_diffs table, so no ordering is necessary.
2. It's faster for preloading. The merge_request_diff association has to load
every diff for the MRs in the set, then discard all but the most recent for
each. This association means that Rails can just query for N diffs from N
MRs.
3. It's more complicated to update. This is a bidirectional foreign key, so we
need to update two tables when adding a diff record. This also means we need
to handle this as a special case when importing a GitLab project.
There is some juggling with this association in the merge request model:
* `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
* `MergeRequest#merge_request_diff` reuses
`MergeRequest#latest_merge_request_diff` unless:
* Arguments are passed. These are typically to force-reload the association.
* It doesn't exist. That means we might be trying to implicitly create a
diff. This only seems to happen in specs.
* The association is already loaded. This is important for the reasons
explained in the comment, which I'll reiterate here: if we a) load a
non-latest diff, then b) get its `merge_request`, then c) get that MR's
`merge_request_diff`, we should get the diff we loaded in c), even though
that's not the latest diff.
Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
but not quite all.
And add support for additional query parameters:
- `author_id`: Returns merge requests created by the given user `id`
- `assignee_id`: Returns merge requests assigned to the given user `id`
- `scope`: Return merge requests for the given scope: `created-by-me`, `assigned-to-me` or `all`
New version of the gem returns 200 status code on delete with content
instead of 204 so we explicitly set status code to keep existing
behavior
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
When updating a merge request via the `/merge` endpoint we
check the `mergeable` and `mergeable_state` status, these will return
`false` if the application option only_allow_merge_if_pipeline_succeeds is
enabled. We should skip CI checks if the request uses the
merge_when_pipeline_succeeds param
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22740
- As opposed to the `id` that was previously being used.
- This brings the API routes closer to the web interface's routes.
- This is specific to API v4.
Rename column in the database
Rename fields related to import/export feature
Rename API endpoints
Rename documentation links
Rename the rest of occurrences in the code
Replace the images that contain the words "build succeeds" and docs referencing to them
Make sure pipeline is green and nothing is missing.
updated doc images
renamed only_allow_merge_if_build_succeeds in projects and fixed references
more updates
fix some spec failures
fix rubocop offences
fix v3 api spec
fix MR specs
fixed issues with partials
fix MR spec
fix alignment
add missing v3 to v4 doc
wip - refactor v3 endpoints
fix specs
fix a few typos
fix project specs
copy entities fully to V3
fix entity error
more fixes
fix failing specs
fixed missing entities in V3 API
remove comment
updated code based on feedback
typo
fix spec
New endpoints are:
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_estimate"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_time_estimate"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/add_spent_time"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_spent_time"
GET :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_stats"
* master: (110 commits)
Rewrite an HTTP link to use HTTPS
Edit /spec/features/profiles/preferences_spec.rb to match changes in 084d90ac
Add blue back to sub nav active
Remove JSX/React eslint plugins.
Fix a transient spec failure
Adds hoverstates for collapsed Issue/Merge Request sidebar
Moved groups above projects
Add StackProf to the Gemfile, along with a utility to get a profile for a spec
Update Sidekiq-cron to fix compatibility issues with Sidekiq 4.2.1
Add a CHANGELOG entry
Alert user when logged in user email is not the same as the invitation
Expose timestamp in build entity used by serializer
Rename `MergeRequest#pipeline` to `head_pipeline`
Remove unnecessary database indexes
CE-specific changes gitlab-org/gitlab-ee#1137
Fixing typo & Clarifying Key name
fix started_at check
fix blob controller spec failure - updated not to use file-path-
fix blob controller spec failure
Merge branch 'jej-use-issuable-finder-instead-of-access-check' into 'security'
...
Conflicts:
app/controllers/projects/merge_requests_controller.rb
lib/api/merge_requests.rb
spec/requests/api/merge_requests_spec.rb
Tony Rom
George Andrinopoulos
Sean McGivern
Mark Fletcher
Sean McGivern
Vitaliy @blackst0ne Klachkov
Luke "Jared" Bennett
haseeb
Jarka Kadlecova
Hiroyuki Sato
Robert Schilling
Robert Speicher
Travis Miller
Toon Claes
Dmitriy Zaporozhets
Stan Hu
Rémy Coutable
Kyle Bishop
Felipe Artur
mhasbini
Chris Wilson
Oswaldo Ferreira
Toon Claes
Timothy Andrew
Adam Niedzielski
James Lopez
James Edwards-Jones
Ruben Davila
Grzegorz Bizon