| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Previously, this would issue a query for each unique `diff_refs_or_sha`
passed. This was because we didn't want to load other MR diffs into memory, as
they had some very large columns.
Now they are actually very small, and it's more efficient to just load them all
at once and do the finding in Ruby.
|
| | |
|
| |
|
|
|
|
| |
Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.
|
| |
|
|
|
| |
We only allow users that can merge the merge request to push to the
fork.
|
| |
|
|
|
|
| |
When a project is not private, and the source branch not protected the
user can now select the option to allow maintainers to push to this
branch
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
MergeRequest#rebase_in_progress? and MergeRequest#rebase_path were called
twice each time per request. This memoization helps reduce the overall number
of queries.
See https://gitlab.com/gitlab-org/gitlab-ee/-/jobs/51616319 as a failing
job.
Closes gitlab-org/gitlab-ee#4857
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On MySQL, at least, `Note#created_at` doesn't seem to store fractional seconds,
while `MergeRequest::Metrics#merged_at` does. This breaks the optimization
assumption that we only need to search for notes created *after* the MR has
been merged.
Unsynchronized system clocks also make this a dangerous assumption to make.
Adding a minute of leeway still optimizes away most notes, but allows both
cases to be handled more gracefully. If the system clocks are more than a
minute out, we'll still be broken, of course.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
into 'master'
Resolve "!15665 consistently 502s because it fetches every commit"
Closes #41807
See merge request gitlab-org/gitlab-ce!16320
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we search for notes before the MR was merged, we have to load every commit
that was ever part of the MR, or mentioned in a push. In extreme cases, this can
be tens of thousands of commits to load, but we know they can't revert the merge
commit, because they are from before the MR was merged.
In the (rare) case that we don't have a `merged_at` value for the MR, we can
still search all notes.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.
This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a project uses fast-forward merging strategy user has
to rebase MRs to target branch before it can be merged.
Now user can do rebase in UI by clicking 'Rebase' button
instead of doing rebase locally.
This feature was already present in EE, this is only backport
of the feature to CE. Couple of changes:
* removed rebase license check
* renamed migration (changed timestamp)
Closes #40301
|
| |\
| |
| |
| |
| | |
Clear caches before updating MR diffs
See merge request gitlab-org/gitlab-ce!15916
|
| | |
| |
| |
| |
| |
| | |
The hook ordering influenced the diffs being generated as these used
values from before the update due to the memoization still being in
place. This commit reorders them and tests against this behaviour.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Update issuable status icons
Closes #33926
See merge request gitlab-org/gitlab-ce!15898
|
| | |/
| |
| |
| |
| |
| |
| | |
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/33926
Changed file icons already addressed in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15367
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Prevent worker that updates merge requests head pipeline from failing jobs
Closes #41021
See merge request gitlab-org/gitlab-ce!15870
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Gitaly CommitService is being hammered by n + 1 calls, mostly when
finding commits. This leads to this gRPC being turned of on production:
https://gitlab.com/gitlab-org/gitaly/issues/514#note_48991378
Hunting down where it came from, most of them were due to
MergeRequest#show. To prove this, I set a script to request the
MergeRequest#show page 50 times. The GDK was being scraped by
Prometheus, where we have metrics on controller#action and their Gitaly
calls performed. On both occations I've restarted the full GDK so all
caches had to be rebuild.
Current master, 806a68a81f1baee, needed 435 requests
After this commit, 154 requests
|
| | |
|
| |
|
|
|
| |
the `ci_pipelines.sha` column is not the same type than the
`merge_request_diff_commits.sha` column (varchar, bytea)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This throttles the number of UPDATE queries that can be triggered by
calling "touch" on a Note, Issue, or MergeRequest. For Note objects we
also take care of updating the associated "noteable" relation in a
smarter way than Rails does by default.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Remove serialised diff and commit columns
Closes #39533
See merge request gitlab-org/gitlab-ce!15582
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The st_commits and st_diffs columns on merge_request_diffs historically held the
YAML-serialised data for a merge request diff, in a variety of formats.
Since 9.5, these have been migrated in the background to two new tables:
merge_request_diff_commits and merge_request_diff_files. That has the advantage
that we can actually query the data (for instance, to find out how many commits
we've stored), and that it can't be in a variety of formats, but must match the
new schema.
This is the final step of that journey, where we drop those columns and remove
all references to them. This is a breaking change to the importer, because we
can no longer import diffs created in the old format, and we cannot guarantee
the export will be in the new format unless it was generated after this commit.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
'40530-merge-request-generates-wrong-diff-when-branch-and-tag-have-the-same-name' into 'master'
Resolve "Merge request generates wrong diff when branch and tag have the same name"
Closes #40530
See merge request gitlab-org/gitlab-ce!15591
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a merge request was created with a branch name that also matched a tag name,
we'd generate a comparison to or from the tag respectively, rather than the
branch. Merging would still use the branch, of course.
To avoid this, ensure that when we get the branch heads, we prepend the
reference prefix for branches, which will ensure that we generate the correct
comparison.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Fix WIP system note not being created
Closes #40374
See merge request gitlab-org/gitlab-ce!15528
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When we consider 'all' pipelines for MRs, we now mean:
1. The last 10,000 commits (unordered).
2. From the last 100 MR versions (newest first).
This seems to fix the MRs that time out on GitLab.com.
|
| |\
| |
| |
| |
| |
| |
| | |
Use Commit#notes and Note.for_commit_id when possible to make sure we use all indexes available to us
Closes #34509
See merge request gitlab-org/gitlab-ce!15253
|
| | |
| |
| |
| | |
all the indexes available to us
|
| |/ |
|
| |
|
|
|
| |
reword the changelog
remove dead code in the specs
|
| |
|
|
|
|
|
|
| |
also, I refactored the MergeRequest#fetch_ref method to express
the side-effect that this method has.
MergeRequest#fetch_ref -> MergeRequest#fetch_ref!
Repository#fetch_source_branch -> Repository#fetch_source_branch!
|
| | |
|
