delta/gitlab/gitlab-ce.git/app/models/deploy_key.rb, branch bootstrap-markdown-code-highlight gitlab.com: gitlab-org/gitlab-ce.git Revert the addition of goldiloader 2018-04-18T13:51:39+00:00 Yorick Peterse yorickpeterse@gmail.com 2018-04-18T13:41:42+00:00 6f292eaa69c771cec8a81d2edaad19a26ab3eae6 This reverts the addition of the "goldiloader" Gem and all use of it. While this Gem is very promising it's causing a variety of problems on GitLab.com due to it eager-loading too much data in places where we don't expect/can handle this. At least for the time being this means we have to go back to manually fixing N+1 query problems, but at least those should not cause a negative impact on availability. 
This reverts the addition of the "goldiloader" Gem and all use of it.
While this Gem is very promising it's causing a variety of problems on
GitLab.com due to it eager-loading too much data in places where we
don't expect/can handle this. At least for the time being this means we
have to go back to manually fixing N+1 query problems, but at least
those should not cause a negative impact on availability.
Add cop for has_many :through without disabled autoloading 2018-04-09T11:47:04+00:00 Sean McGivern sean@gitlab.com 2018-04-09T11:19:18+00:00 4ef3e3491e2ecc34e7f4de1221d5ad7b8b4a1e24 Goldiloader is great, but has several issues with has_many :through relations: * https://github.com/salsify/goldiloader/issues/12 * https://github.com/salsify/goldiloader/issues/14 * https://github.com/salsify/goldiloader/issues/18 Rather than try to figure out which applies in each case, we should just do the drudge work of manually disabling autoloading for all relations of this type. We can always use regular preloading for specific cases, but this way we avoid generating invalid queries through Goldiloader's magic. 
Goldiloader is great, but has several issues with has_many :through relations:

* https://github.com/salsify/goldiloader/issues/12
* https://github.com/salsify/goldiloader/issues/14
* https://github.com/salsify/goldiloader/issues/18

Rather than try to figure out which applies in each case, we should just do the
drudge work of manually disabling autoloading for all relations of this type. We
can always use regular preloading for specific cases, but this way we avoid
generating invalid queries through Goldiloader's magic.
Fall back on ghost user when deploy key user is not set 2018-03-28T16:54:15+00:00 Douwe Maan douwe@selenight.nl 2018-03-28T16:54:15+00:00 7bca902a23d0cccaa3bce422fce7fdc71e722db4 






Merge branch 'sh-migrate-can-push-to-deploy-keys-projects-10-3' into 'security-10-3'
2018-01-17T01:04:51+00:00

Douwe Maan
douwe@gitlab.com

2018-01-05T15:23:44+00:00

536a47b4b70df0f2a8438ed0ada7654593fa5cd0

[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project`

See merge request gitlab/gitlabhq!2276

(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)

1f2bd3c0 Backport to 10.3





[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project`

See merge request gitlab/gitlabhq!2276

(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)

1f2bd3c0 Backport to 10.3







created services for keys
2017-09-15T15:35:24+00:00

haseeb
haseebeqx@gmail.com

2017-09-15T15:35:24+00:00

cc2daa74d83c98dc05dd92f0950a122b46b83c96












Added Cop to blacklist the use of `dependent:`
2017-07-06T10:01:36+00:00

Yorick Peterse
yorickpeterse@gmail.com

2017-06-08T15:16:27+00:00

8fbbf41e29f5e0f56b7eb9d37aadba856b68bcce

This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).





This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).







Don't notify user for deploy keys, feedback:
2016-11-17T17:23:04+00:00

Lin Jen-Shin
godfat@godfat.org

2016-11-17T17:23:04+00:00

2489332297b441b3ebc0c3df2e8ff14dc88a72cf

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18517263





https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18517263







Introduce has_access_to? so that we could reuse it
2016-11-16T12:31:23+00:00

Lin Jen-Shin
godfat@godfat.org

2016-11-16T12:31:08+00:00

a9765fb47fbbd1e1070434fc06cc76b25a42caa6

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18439108





Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18439108







Add more tests and fix write to project check
2016-11-11T13:44:33+00:00

Lin Jen-Shin
godfat@godfat.org

2016-11-11T13:44:33+00:00

71ae01fefe62caf396640affb8ca618fe68db5a0












Remove the annotate gem and delete old annotations
2016-05-09T16:00:28+00:00

Jeroen van Baarsen
jeroenvanbaarsen@gmail.com

2016-05-09T16:00:28+00:00

f1479b56b71bef63517b90fcde99e6508e9c54af

In 8278b763d96ef10c6494409b18b7eb541463af29 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382





In 8278b763d96ef10c6494409b18b7eb541463af29 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382