- Mar 17, 2020
-
-
GitLab Bot authored
-
- Mar 12, 2020
-
-
GitLab Bot authored
-
- Mar 05, 2020
-
-
GitLab Bot authored
-
- Feb 27, 2020
-
-
GitLab Bot authored
-
- Feb 26, 2020
-
-
GitLab Bot authored
-
- Feb 16, 2020
-
-
GitLab Bot authored
-
- Feb 13, 2020
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- Feb 12, 2020
-
-
GitLab Bot authored
-
- Feb 11, 2020
-
-
GitLab Bot authored
-
- Feb 06, 2020
-
-
GitLab Bot authored
-
- Feb 05, 2020
-
-
GitLab Bot authored
-
- Feb 04, 2020
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- Feb 03, 2020
-
-
GitLab Bot authored
-
- Feb 02, 2020
-
-
GitLab Bot authored
-
- Jan 28, 2020
-
-
GitLab Bot authored
-
- Jan 27, 2020
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- Jan 20, 2020
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- Jan 16, 2020
-
-
GitLab Bot authored
-
- Jan 07, 2020
-
-
GitLab Bot authored
-
- Dec 27, 2019
-
-
GitLab Bot authored
-
- Nov 29, 2019
-
-
GitLab Bot authored
-
- Nov 26, 2019
-
-
GitLab Bot authored
-
- Oct 06, 2019
-
-
GitLab Bot authored
-
- Sep 27, 2019
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- Sep 23, 2019
-
-
GitLab Bot authored
-
- Sep 19, 2019
-
-
GitLab Bot authored
-
- Sep 18, 2019
-
-
GitLab Bot authored
-
- Sep 13, 2019
-
-
GitLab Bot authored
-
- Sep 10, 2019
-
-
Nick Thomas authored
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.
-
Nick Thomas authored
This reverts commit c6ccc07f.
-
- Sep 03, 2019
-
-
Igor Drozdov authored
It performs an expensive operation, but isn't required in most of tests
-
- Aug 31, 2019
-
-
dineshpanda authored
-
- Aug 29, 2019
-
-
Nick Thomas authored
This reverts commit 0eff75fa.
-
- Aug 16, 2019
-
-
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
-
Nick Thomas authored
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.
-