- 02 11月, 2017 1 次提交
-
-
由 Shinya Maeda 提交于
Fix out of sync with KubernetesService. Remove namespace pramas from controller. Use time_with_zone in schema. Remove Gcp::Clusters from safe_model_attributes.ym
-
- 01 11月, 2017 6 次提交
-
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-
由 Shinya Maeda 提交于
-
由 Shinya Maeda 提交于
-
由 Eric Eastwood 提交于
-
由 Douwe Maan 提交于
-
- 31 10月, 2017 5 次提交
-
-
由 Gabriel Mazetto 提交于
-
由 Shinya Maeda 提交于
-
由 Gabriel Mazetto 提交于
-
由 Alejandro Rodríguez 提交于
-
由 Jacopo 提交于
Pipeline hook data now includes the project_id
-
- 30 10月, 2017 4 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Shinya Maeda 提交于
-
由 Oswaldo Ferreira 提交于
-
由 Shinya Maeda 提交于
-
- 28 10月, 2017 2 次提交
-
-
由 Oswaldo Ferreira 提交于
-
由 Gabriel Mazetto 提交于
When project storage_version is `2` means attachments are using hashed storage.
-
- 27 10月, 2017 5 次提交
-
-
由 Lin Jen-Shin (godfat) 提交于
-
由 Brett Walker 提交于
-
由 Sean McGivern 提交于
For MRs with many thousands of commits, `SELECT DISTINCT(sha)` will be very slow. What we can't do to fix this: 1. Add an index. Postgres won't use it for DISTINCT without a lot of ceremony. 2. Do the `uniq` in Ruby. That can still be very slow with hundreds of thousands of commits. 3. Use a subquery. We haven't removed the `st_commits` column yet, but we will soon. Until 3 is available to us, we can just do 2, but also add a limit clause. There is no ordering, so this may return different results, but our goal with these MRs is just to get them to load, so it's not a huge deal.
-
由 Zeger-Jan van de Weg 提交于
Now, when requesting a commit from the Repository model, the results are not cached. This means we're fetching the same commit by oid multiple times during the same request. To prevent us from doing this, we now cache results. Caching is done only based on object id (aka SHA). Given we cache on the Repository model, results are scoped to the associated project, eventhough the change of two repositories having the same oids for different commits is small.
-
由 Alessio Caiazza 提交于
-
- 26 10月, 2017 1 次提交
-
-
由 Francisco Lopez 提交于
Closes #25142
-
- 25 10月, 2017 1 次提交
-
-
由 Alejandro Rodríguez 提交于
We also delete some unused code related to the aforementioned feature.
-
- 24 10月, 2017 1 次提交
-
-
由 Robert Schilling 提交于
-
- 23 10月, 2017 4 次提交
-
-
由 Bob Van Landuyt 提交于
-
由 Shinya Maeda 提交于
-
由 Kamil Trzcinski 提交于
-
由 Stan Hu 提交于
Environment names that contained a space would cause an error in GitLab 10.1 because a new guard clause was introduced in Repository#write_ref to prevent such references from existing. Use the slug instead to ensure that the name is valid. Closes #39182
-
- 22 10月, 2017 3 次提交
-
-
由 Travis Miller 提交于
-
由 Nick Thomas 提交于
-
由 Kamil Trzcinski 提交于
-
- 21 10月, 2017 1 次提交
-
-
由 Nick Thomas 提交于
-
- 20 10月, 2017 1 次提交
-
-
由 Alejandro Rodríguez 提交于
This saves us Rugged/gRPC invocations
-
- 19 10月, 2017 1 次提交
-
-
由 Kamil Trzcinski 提交于
-
- 18 10月, 2017 1 次提交
-
-
由 Jen-Shin Lin 提交于
Security fixes for 10.1 RC See merge request gitlab/gitlabhq!2209
-
- 17 10月, 2017 3 次提交
-
-
由 Bob Van Landuyt 提交于
The problem would occur when the `ForkedProjectLink` was deleted, but the `ForkNetworkMember` was not. The delete would be rolled back and retried. But the error would not be saved because `Project#forked?` would still be true, because the `ForkNetworkMember` exists. But the `Project#forked_project_link` would be `nil`. So the validation for the visibility level would fail.
-
由 Bob Van Landuyt 提交于
-
由 Annabel Dunstone Gray 提交于
-