summaryrefslogtreecommitdiff
path: root/app/models/repository.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@13-1-stable-eeGitLab Bot2020-06-181-5/+3
|
* Add latest changes from gitlab-org/gitlab@13-0-stable-eeGitLab Bot2020-05-201-0/+11
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-03-171-2/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-03-121-9/+0
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-03-051-4/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-271-4/+5
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-261-0/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-161-2/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-131-10/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-131-2/+6
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-121-20/+12
|
* Add latest changes from gitlab-org/gitlab@master76926-follow-up-from-resolve-multi-selection-for-delete-on-registry-pageGitLab Bot2020-02-111-0/+6
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-061-18/+0
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-051-4/+0
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-041-18/+23
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-041-4/+0
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-031-4/+38
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-02-021-2/+4
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-281-11/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-271-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-271-0/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-201-0/+4
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-201-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-161-2/+6
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-01-071-2/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-12-271-7/+7
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-11-291-1/+16
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-11-261-11/+12
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-10-061-1/+1
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-271-1/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-271-0/+2
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-231-4/+4
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-191-9/+19
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-181-27/+3
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-09-131-0/+2
|
* Don't use the redis set cache yetNick Thomas2019-09-101-4/+4
| | | | | | | | | | | | | | | | | | For zero-downtime deployed in a mixed code environment between 12.2 and 12.3, the branch and tag name cache is incorrectly invalidated - a push to an old machine will not clear the redis set version of the cache on the new machine. This commit ensures that, in 12.3, both set and non-set versions of the cache are invalidated, but does not write or consult the set version of the cache. . In 12.4, it will be safe to switch branch and tag names to the redis set cache both it and the legacy cache will be invalidated appropriately in such a mixed code environment. This delays the full implementation of the feature by one release, but in the absence of a credible feature-flagging strategy, and amidst an abundance of caution about the effects of too-eager cache expiration, I believe this is the best approach available to us.
* Revert "Revert "Cache branch and tag names as Redis sets""Nick Thomas2019-09-101-4/+8
| | | | This reverts commit c6ccc07f48c7c1f9da43ecd82015500a4340544d.
* Stub DetectRepositoryLanguagesWorker for all testsIgor2019-09-031-0/+4
| | | | | It performs an expensive operation, but isn't required in most of tests
* Avoid calling freeze on already frozen strings in app/modelsdineshpanda2019-09-011-3/+3
|
* Revert "Cache branch and tag names as Redis sets"Nick Thomas2019-08-291-8/+4
| | | | This reverts commit 0eff75fa2b6691b6fba31fcc2842f51debd249a9.
* Merge branch '64251-branch-name-set-cache' into 'master'Robert Speicher2019-08-191-4/+8
|\ | | | | | | | | Cache branch and tag names as Redis sets See merge request gitlab-org/gitlab-ce!30476
| * Cache branch and tag names as Redis setsNick Thomas2019-08-161-4/+8
| | | | | | | | | | | | This allows us to check inclusion for the *_exists? methods without downloading the full list of branch names, which is over 100KiB in size for gitlab-ce at the moment.
* | Expire project caches once per push instead of once per refStan Hu2019-08-161-2/+6
|/ | | | | | | | | | | | | | | | | | | | | | Previously `ProjectCacheWorker` would be scheduled once per ref, which would generate unnecessary I/O and load on Sidekiq, especially if many tags or branches were pushed at once. `ProjectCacheWorker` would expire three items: 1. Repository size: This only needs to be updated once per push. 2. Commit count: This only needs to be updated if the default branch is updated. 3. Project method caches: This only needs to be updated if the default branch changes, but only if certain files change (e.g. README, CHANGELOG, etc.). Because the third item requires looking at the actual changes in the commit deltas, we schedule one `ProjectCacheWorker` to handle the first two cases, and schedule a separate `ProjectCacheWorker` for the third case if it is needed. As a result, this brings down the number of `ProjectCacheWorker` jobs from N to 2. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52046
* Only expire tag cache once per pushsh-only-flush-tags-once-per-pushStan Hu2019-08-131-5/+9
| | | | | | | | | | Previously each tag in a push would invoke the Gitaly `FindAllTags` RPC since the tag cache would be invalidated with every tag. We can eliminate those extraneous calls by expiring the tag cache once in `PostReceive` and taking advantage of the cached tags. Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/65795
* Invalidate branches cache on PostReceivePatrick Bajao2019-08-091-4/+4
| | | | | | | | | | | | | | | | Whenever `PostReceive` is enqueued, `UpdateMergeRequestsWorker` is enqueued and `MergeRequests::RefreshService` is called, it'll check if the source branch of each MR asssociated to the push exists or not via `MergeRequest#source_branch_exists?`. The said method will call `Repository#branch_exists?` which is cached in `Rails.cache`. When the cache contains outdated data and the source branch actually exists, the `MergeRequests#RefreshService` job will close associated MRs which is not correct. The fix is to expire the branches cache of the project so we have updated data during the post receive hook which will help in the accuracy of the check if we need to close associated MRs or not.
* Merge branch 'add-caching-to-archive-endpoint' into 'master'Grzegorz Bizon2019-07-251-0/+3
|\ | | | | | | | | Return an ETag header for the archive endpoint See merge request gitlab-org/gitlab-ce!30581
| * Return an ETag headers for the archive endpointadd-caching-to-archive-endpointAhmad Sherif2019-07-231-0/+3
| | | | | | | | We use the relative path of the archive to check for archive staleness.
* | Add a rubocop for Rails.loggerMayra Cabrera2019-07-101-1/+3
|/ | | | | | Suggests to use a JSON structured log instead Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102
* Fix race condition on merge train ref generationrun-pipeline-for-merge-train-at-train-ref-ceShinya Maeda2019-07-081-0/+4
| | | | | | | | | Today, Pipelines for merge train run on `refs/merge`, however, this causes a race condition that it can be overwritten by CheckMergeabilityService. This patch fixes the problem by generating `refs/train` for those pipelines.
* Extend MergeToRefService for creating merge ref from the other refShinya Maeda2019-07-051-2/+2
| | | | | | | Currently, MergeToRefService is specifically designed for createing merge commits from source branch and target branch of merge reqeusts. We extend this behavior to source branch and any target ref paths.
View Lorry Controller Status