- 09 Aug, 2016 2 commits
-
-
Stan Hu authored
This is in preparation to address the DB load caused by the counting in gitlab-com/infrastructure#303.
-
tiagonbotelho authored
-
- 04 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 02 Aug, 2016 1 commit
-
-
tiagonbotelho authored
developer cannot push to protected branch when project is empty or he has not been granted permission to do so
-
- 29 Jul, 2016 1 commit
-
-
Timothy Andrew authored
1. Remove `Project#developers_can_push_to_protected_branch?` since it isn't used anymore. 2. Remove `Project#developers_can_merge_to_protected_branch?` since it isn't used anymore.
-
- 27 Jul, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 26 Jul, 2016 1 commit
-
-
Alejandro Rodríguez authored
-
- 21 Jul, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 20 Jul, 2016 11 commits
-
-
Alejandro Rodríguez authored
Currently, even when searching for all authorized issues of *one* project, we run the `Users#authorized_projects` query (which can be rather slow). This update checks if we are handling issues of just one project and does the authorization check locally. It does have the downside of basically repeating the logic of `Users#authorized_projects` on `Project#authorized_for_user`.
-
-
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
So we no longer join anything, just find the latest pipeline and load builds from there to avoid mixing builds. Thanks Kamil for the help and tests.
-
-
Lin Jen-Shin authored
this should properly test that it's really getting the builds from the latest successful pipelines and latest successful builds.
-
- 19 Jul, 2016 3 commits
-
-
Eugene Howe authored
* This method previously iterated over all services in a project. Now it will directly query the ExternalWikiService for the project and filter by active state. * The presence of an external wiki is also cached * When an external wiki is added or removed, the cached value is updated
-
Lin Jen-Shin authored
This was extracted from !5142 and implementing part of #4255. We split it from !5142 because we want to ship it in 8.10 while !5142 was not ready yet.
- 18 Jul, 2016 1 commit
-
-
Stan Hu authored
preventing settings from being saved
-
- 12 Jul, 2016 3 commits
-
-
Robert Speicher authored
-
James Lopez authored
fixes a few issues to do with import_url not being saved correctly for imports. This should prevent the import_data to be created when it should not and output an error properly validating before creating it.
-
- 07 Jul, 2016 1 commit
-
-
Timothy Andrew authored
1. The `open_branches` method is used to provide a list of branches while creating a protected branch. 2. It makes sense to include branches which are matched by one or more wildcard protected branches, since the user might want to make exact protected branches from these as well. 3. This also provides a large performance improvement. On my machine, in a project with 5000 branches and 2000 protected branches, the `ProtectedBranches#index` page went from a 40 seconds load time to 4 seconds (10x speedup).
-
- 06 Jul, 2016 1 commit
-
-
Douwe Maan authored
-
- 05 Jul, 2016 1 commit
-
-
Timothy Andrew authored
1. The main implementation is in the `ProtectedBranch` model. The wildcard is converted to a Regex and compared. This has been tested thoroughly. - While `Project#protected_branch?` is the main entry point, `project#open_branches` and `project#developers_can_push_to_protected_branch?` have also been modified to work with wildcard protected branches. - The regex is memoized (within the `ProtectedBranch` instance) 2. Improve the performance of `Project#protected_branch?` - This method is called from `Project#open_branches` once _per branch_ in the project, to check if that branch is protected or not. - Before, `#protected_branch?` was making a database call every time it was invoked (in the above case, that amounts to once per branch), which is expensive. - This commit caches the list of protected branches in memory, which reduces the number of database calls down to 1. - A downside to this approach is that `#protected_branch?` _could_ return a stale value (due to the caching), but this is an acceptable tradeoff. 3. Remove the (now) unused `Project#protected_branch_names` method. - This was previously used to check for protected branch status.
-
- 01 Jul, 2016 1 commit
-
-
Rémy Coutable authored
And create new Project#requesters, Group#requesters scopes. Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 30 Jun, 2016 2 commits
-
-
Alejandro Rodríguez authored
-
Alejandro Rodríguez authored
-
- 27 Jun, 2016 1 commit
-
-
Ruben Davila authored
This fix avoids exposing the information from the wiki repository of other project.
-
- 24 Jun, 2016 1 commit
-
-
Lin Jen-Shin authored
Feedback from: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3363#note_12669123
-
- 23 Jun, 2016 1 commit
-
-
Lin Jen-Shin authored
Which would return the email address for creating a new issue by sending an email to that particular address.
-
- 22 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 17 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 16 Jun, 2016 3 commits
-
-
Yorick Peterse authored
This ensures that Project.find_with_namespace returns a row matching literally as the first value, instead of returning a random value. The ordering here is _only_ applied to Project.find_with_namespace and _not_ Project.where_paths_in as currently there's no code that requires Project.where_paths_in to return rows in a certain order. Since this method also returns all rows that match there's no real harm in not setting a specific order either. Another reason is that generating all the "WHEN" arms for multiple values in Project.where_paths_in becomes really messy. On MySQL we have to use the "BINARY" operator to turn a "WHERE" into a case-sensitive WHERE as otherwise MySQL may still end up returning rows in an unpredictable order. Fixes gitlab-org/gitlab-ce#18603
-
James Lopez authored
This reverts commit 429cd5e57fb1.
-
James Lopez authored
-