- 12 1月, 2018 1 次提交
-
-
由 Lin Jen-Shin 提交于
with StrongMemoize
-
- 19 7月, 2017 2 次提交
-
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
I realized where the N+1 queries were actually coming from project.protected_branches, but how come we cannot preload this, or cache this at all? Then I found that this is somehow a Rails limitation. What we're doing before, eventually come to: project.protected_branches.matching But why it's not cached? (project.protected_branches.loaded? is always false) It's because matching is a class method, which is called on the proxy. In this case, Rails cannot cache the result. I don't know if this is possible to implement or not, because clearly this would require some tricks to implement class methods on associations. So instead, we could just pass project.protected_branches to ProtectedRef.matching, then it would work regularly. With this change, there's no more N+1 queries.
-
- 18 7月, 2017 3 次提交
-
-
由 Lin Jen-Shin 提交于
Also make sure pipeline would also check against tag as well
-
由 Lin Jen-Shin 提交于
-
由 Lin Jen-Shin 提交于
-
- 17 7月, 2017 1 次提交
-
-
由 Lin Jen-Shin 提交于
I don't like the idea of `RequestStore` at all, because it's just a global state which shouldn't be used at all. But we have a number of places calling `ProtectedBranch.protected?` and `ProtectedTag.protected?` in a loop for the same user, project, and ref whenever we're checking against if the jobs for a given pipeline is accessible for a given user. This means we're effectively making N queries for the same thing over and over. To properly fix this, we need to change how we check the permission, and that could be a huge work. To solve this quickly, adding a cache layer for the given request would be quite simple to do. We're already doing this in Commit#author, and this is extending that idea and make it generalized.
-
- 04 7月, 2017 2 次提交
-
-
由 Lin Jen-Shin 提交于
So that we cache the result of UserAccess#can_push_or_merge_to_branch? in RequestStore, avoiding querying ProtectedBranch over and over for the list of pipelines (i.e. in PipelineSerializer) I don't think this is ideal because I don't like the idea of RequestStore in general, but this is the easiest way to cache it without changing the architecture. In the future we should cache more explicitly rather than this kind of global store.
-
由 Lin Jen-Shin 提交于
updating builds and updating pipelines. We check against being able to merge or push if the ref is protected.
-
- 08 5月, 2017 1 次提交
-
-
由 Sam Rose 提交于
-
- 28 4月, 2017 1 次提交
-
-
由 Pawel Chojnacki 提交于
-
- 04 4月, 2017 4 次提交
-
-
由 James Edwards-Jones 提交于
-
由 James Edwards-Jones 提交于
-
由 James Edwards-Jones 提交于
-
由 James Edwards-Jones 提交于
-
- 01 4月, 2017 1 次提交
-
-
由 James Edwards-Jones 提交于
-
- 10 3月, 2017 2 次提交
-
-
由 http://jneen.net/ 提交于
-
由 http://jneen.net/ 提交于
-
- 13 1月, 2017 1 次提交
-
-
由 Pawel Chojnacki 提交于
if user has either push or merge permissions + Change log entry for fix to creating a branch matching a wildcard fails
-
- 16 11月, 2016 1 次提交
-
-
由 Lin Jen-Shin 提交于
checking user permission.
-
- 16 8月, 2016 1 次提交
-
-
由 Timothy Andrew 提交于
1. Change a few incorrect `access_level` to `access_levels.first` that were missed in e805a647. 2. `API::Entities` can iterate over all access levels instead of just the first one. This makes no difference to CE, and makes it more compatible with EE.
-
- 05 8月, 2016 1 次提交
-
-
由 tiagonbotelho 提交于
-
- 29 7月, 2016 1 次提交
-
-
由 Timothy Andrew 提交于
1. The crux of this change is in `UserAccess`, which looks through all the access levels, asking each if the user has access to push/merge for the current project. 2. Update the `protected_branches` factory to create access levels as necessary. 3. Fix and augment `user_access` and `git_access` specs.
-
- 18 7月, 2016 1 次提交
-
-
由 Rémy Coutable 提交于
This reverts commit 530f5158. See !4892. Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 14 7月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
This reverts commit 9ca633eb, reversing changes made to fb229bbf.
-
- 13 7月, 2016 1 次提交
-
-
由 Timothy Andrew 提交于
1. Don't use case statements for dispatch anymore. This leads to a lot of duplication, and makes the logic harder to follow. 2. Remove duplicated logic. - For example, the `can_push_to_branch?` exists, but we also have a different way of checking the same condition within `change_access_check`. - This kind of duplication is removed, and the `can_push_to_branch?` method is used in both places. 3. Move checks returning true/false to `UserAccess`. - All public methods in `GitAccess` now return an instance of `GitAccessStatus`. Previously, some methods would return true/false as well, which was confusing. - It makes sense for these kinds of checks to be at the level of a user, so the `UserAccess` class was repurposed for this. The prior `UserAccess.allowed?` classmethod is converted into an instance method. - All external uses of these checks have been migrated to use the `UserAccess` class 4. Move the "change_access_check" into a separate class. - Create the `GitAccess::ChangeAccessCheck` class to run these checks, which are quite substantial. - `ChangeAccessCheck` returns an instance of `GitAccessStatus` as well. 5. Break out the boolean logic in `ChangeAccessCheck` into `if/else` chains - this seems more readable. 6. I can understand that this might look like overkill for !4892, but I think this is a good opportunity to clean it up. - http://martinfowler.com/bliki/OpportunisticRefactoring.html
-
- 10 3月, 2016 2 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Jacob Vosmaer 提交于
-
- 07 8月, 2014 1 次提交
-
-
由 Jacob Vosmaer 提交于
This changes the number of LDAP calls when users access GitLab via Git-over-SSH or the API. LDAP check results are cached for 1 hour.
-
- 15 5月, 2014 1 次提交
-
-
由 Jacob Vosmaer 提交于
-