- 24 11月, 2017 9 次提交
-
-
由 Douwe Maan 提交于
-
由 James Edwards-Jones 提交于
Previously these were duplicated so they could be different for push/merge, but this was no longer necessary after https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11232
-
由 James Edwards-Jones 提交于
Before an access_level was required in EE even when an it had been set for a user/group.
-
由 Filipa Lacerda 提交于
-
-
由 Pawel Chojnacki 提交于
-
由 Pawel Chojnacki 提交于
-
由 Pawel Chojnacki 提交于
-
由 Felipe Artur 提交于
-
- 23 11月, 2017 15 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Markus Koller 提交于
-
由 James Edwards-Jones 提交于
-
由 Sean McGivern 提交于
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.
-
由 Filipa Lacerda 提交于
-
由 Jarka Kadlecova 提交于
-
由 Lin Jen-Shin 提交于
-
由 Jose Ivan Vargas Lopez 提交于
-
由 Nick Thomas 提交于
-
由 Phil Hughes 提交于
-
由 Phil Hughes 提交于
-
由 Shinya Maeda 提交于
-
由 Travis Miller 提交于
-
由 Jose Ivan Vargas 提交于
-
- 22 11月, 2017 10 次提交
-
-
由 Phil Hughes 提交于
Closes #40338
-
由 Alessio Caiazza 提交于
-
-
由 Simon Knox 提交于
-
-
由 Jacob Vosmaer (GitLab) 提交于
-
由 Gabriel Mazetto 提交于
-
由 Nick Thomas 提交于
-
由 Yorick Peterse 提交于
This changes Ci::Pipeline#latest_builds_with_artifacts so it returns an Array instead of a relation. Whenever we use this data we do so in two steps: 1. Count the number of rows 2. If this number is greater than 0, iterate over the rows By returning an Array instead we only execute 1 query of which the total time/work is less than running either just a COUNT(*) or both queries (in the worst case). On GitLab.com this change should save us a few milliseconds per request to ProjectsController#show.
-
- 21 11月, 2017 6 次提交
-
-
由 Filipa Lacerda 提交于
-
由 Daniel Juarez 提交于
-
由 micael.bergeron 提交于
-
由 Felipe Artur 提交于
-
由 Zeger-Jan van de Weg 提交于
After installing a new gem, batch-loader, a construct can be used to queue data to be fetched in bulk. The gem was also introduced in both gitlab-org/gitlab-ce!14680 and gitlab-org/gitlab-ce!14846, but those mrs are not merged yet. For the generation of diffs, both the old blob and the new blob need to be loaded. This for every file in the diff, too. Now we collect all these so we do 1 fetch. Three `.allow_n_plus_1_calls` have been removed, which I expect to be valid, but this needs to be confirmed by a full CI run. Possibly closes: - https://gitlab.com/gitlab-org/gitlab-ce/issues/37445 - https://gitlab.com/gitlab-org/gitlab-ce/issues/37599 - https://gitlab.com/gitlab-org/gitlab-ce/issues/37431
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-