- 16 Aug, 2016 1 commit
-
-
Timothy Andrew authored
!581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
-
- 29 Jul, 2016 4 commits
-
-
Timothy Andrew authored
1. It makes sense to reuse these constants since we had them duplicated in the previous enum implementation. This also simplifies our `check_access` implementation, because we can use `project.team.max_member_access` directly. 2. Use `accepts_nested_attributes_for` to create push/merge access levels. This was a bit fiddly to set up, but this simplifies our code by quite a large amount. We can even get rid of `ProtectedBranches::BaseService`. 3. Move API handling back into the API (previously in `ProtectedBranches::BaseService#translate_api_params`. 4. The protected branch services now return a `ProtectedBranch` rather than `true/false`. 5. Run `load_protected_branches` on-demand in the `create` action, to prevent it being called unneccessarily. 6. "Masters" is pre-selected as the default option for "Allowed to Push" and "Allowed to Merge". 7. These changes were based on a review from @rymai in !5081.
-
Timothy Andrew authored
1. Reuse the same dropdown component that we used for updating these settings (`ProtectedBranchesAccessSelect`). Have it accept options for the parent container (so we can control the elements it sees) and whether or not to save changes via AJAX (we need this for update, but not create). 2. Change the "Developers" option to "Developers + Masters", which is clearer. 3. Remove `developers_can_push` and `developers_can_merge` from the model, since they're not needed anymore.
-
Timothy Andrew authored
1. Improve error handling while creating protected branches. 2. Modify coffeescript code so that the "Developers can *" checkboxes send a '1' or '0' even when using AJAX. This lets us keep the backend code simpler. 3. Use services for both creating and updating protected branches. Destruction is taken care of with `dependent: :destroy`
-
Timothy Andrew authored
- And hook up their associations.
-
- 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).
-
- 05 Jul, 2016 2 commits
-
-
Timothy Andrew authored
1. Allow entering any branch name for a protected branch. - Either pick from a list of options, or enter it manually - You can enter wildcards. 2. Display branches matching a protected branch. - Add a `ProtectedBranches#show` page that displays the branches matching the given protected branch, or a message if there are no matches. - On the `index` page, display the last commit for an exact match, or the number of matching branches for a wildcard match. - Add an `iid` column to `protected_branches` - this is what we use for the `show` page URL. - On the off chance that this feature is unnecessary, this commit encapsulates it neatly, so it can be removed without affecting anything else. 3. Remove the "Last Commit" column from the list of protected branches. - There's no way to pull these for wildcard protected branches, so it's best left for the `show` page. - Rename the `@branches` instance variable to `@protected_branches` - Minor styling changes with the "Unprotect" button - floated right like the "Revoke" button for personal access tokens 4. Paginate the list of protected branches. 5. Move the instructions to the left side of the page.
-
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.
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 09 May, 2016 1 commit
-
-
Jeroen van Baarsen authored
In 8278b763 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
-
- 06 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 24 Apr, 2015 1 commit
-
-
Douwe Maan authored
-
- 22 Jan, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 26 Jun, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 09 Apr, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 21 Mar, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 04 Feb, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 28 Jan, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 04 Jan, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 03 Jan, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 19 Nov, 2012 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 09 Oct, 2012 2 commits
-
-
Dmitriy Zaporozhets authored
-
Andrey Kumanyaev authored
-
- 27 Sep, 2012 2 commits
-
-
Nihad Abbasov authored
-
Nihad Abbasov authored
-
- 26 Sep, 2012 1 commit
-
-
Nihad Abbasov authored
-
- 02 Sep, 2012 1 commit
-
-
Sytse Sijbrandij authored
Merge branch 'master' into non-interactive-aws-install Conflicts: doc/installation.md Fix merge mess in installation.md
-
- 28 Aug, 2012 1 commit
-
-
randx authored
Simplified gitolite handle logic Stubn over monkeypatch Stub only specific methods in Gitlab:Gitolite Moved grach auth to lib added specs for keys observer removes SshKey role
-
- 26 Jun, 2012 1 commit
-
-
randx authored
-
- 26 May, 2012 1 commit
-
-
randx authored
-
- 05 Mar, 2012 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 15 Feb, 2012 1 commit
-
-
Dmitriy Zaporozhets authored
ProtectedBranches model, Master permission for repo\n Allow push to protected branch for masters only
-