summaryrefslogtreecommitdiff
path: root/app/models/deploy_key.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2023-02-011-0/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2023-01-311-2/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2023-01-121-1/+7
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2022-10-061-0/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2022-07-291-0/+5
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2022-07-201-0/+4
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2021-11-021-4/+4
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2021-07-031-0/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2021-03-251-2/+0
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-11-131-0/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-11-101-2/+10
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-12-121-3/+7
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-12-011-1/+2
|
* Use self.ignored_columns += instead of =Stan Hu2019-08-301-1/+1
| | | | This is to accomodate prepended modules.
* Remove dependency on IgnorableColumn concerndineshpanda2019-08-301-2/+1
|
* Speed up loading and filtering deploy keys and their projectsNick Thomas2019-08-051-2/+3
| | | | | | | | | | This commit changes how we eager-load projects, routes, and namespaces required by the deploy keys endpoint, getting a 10x improvement in my local testing. The endpoint still doesn't scale in-general, but going from ~13 seconds to dump a 63K result to generating the same thing in ~1.6 seconds seems like a good improvement to me.
* Stop using pluck to get deploy keys for a userNick Thomas2019-08-051-0/+1
|
* Fix rubocop Style/ZeroLengthPredicateSemyon Pupkov2018-09-181-1/+1
|
* Enable frozen string in app/models/*.rbrepo-forks/gitlab-ce-frozen-string-enable-app-modelsgfyoung2018-07-261-0/+2
| | | | Partially addresses #47424.
* Revert the addition of goldiloaderYorick Peterse2018-04-181-1/+1
| | | | | | | | | 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 autoloadingfix-n-plus-one-when-getting-notification-settings-for-recipientsSean McGivern2018-04-091-1/+1
| | | | | | | | | | | | | 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 setDouwe Maan2018-03-281-0/+4
|
* Merge branch 'sh-migrate-can-push-to-deploy-keys-projects-10-3' into ↵Douwe Maan2018-01-161-3/+17
| | | | | | | | | | | | 'security-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 keyshaseeb2017-09-151-6/+0
|
* Added Cop to blacklist the use of `dependent:`Yorick Peterse2017-07-061-1/+1
| | | | | | | | 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:Lin Jen-Shin2016-11-181-0/+6
| | | | https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18517263
* Introduce has_access_to? so that we could reuse itLin Jen-Shin2016-11-161-1/+5
| | | | | Feedback: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7383#note_18439108
* Add more tests and fix write to project checkLin Jen-Shin2016-11-111-0/+4
|
* Remove the annotate gem and delete old annotationsJeroen van Baarsen2016-05-091-15/+0
| | | | | | | | | 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
* Annotate the modelsZeger-Jan van de Weg2016-05-061-3/+3
|
* Re-annotate modelsStan Hu2015-05-031-1/+1
|
* Clean up code.Douwe Maan2015-04-031-1/+12
|
* Allow admin to create public deploy keys that are accessible to any project.Douwe Maan2015-04-031-0/+7
|
* Re-annotate modelsDmitriy Zaporozhets2014-04-091-2/+2
| | | | Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
* ReannotateDmitriy Zaporozhets2013-08-211-8/+8
|
* AnnotatedDmitriy Zaporozhets2013-06-191-0/+14
|
* Feature: Deploy keys between projectsDmitriy Zaporozhets2013-05-061-0/+2
|
* Create DeployKey & DeployKeysProject models. Bulding many to many relation ↵Dmitriy Zaporozhets2013-05-061-0/+4
between deploy keys and projects