BigW Consortium Gitlab

Skip to content

G
gitlab-ce
Switch branch/tag
  1. 06 Jul, 2016 1 commit
  3. 05 Jul, 2016 7 commits
    • Add documentation for wildcard protected branches. · 5de79c4f
      Timothy Andrew authored
    • Add a feature spec for protected branch creation. · d8475276
      Timothy Andrew authored 
      1. Doesn't seem like there's an easy way to do this for the actual
   branch protection, since we'd have to test an actual `git push`.

2. Testing branch creation the web UI is also not straightforward,
   since the factory repo doesn't have any hooks, and so access checks
   at the `gitlab-shell` level aren't run.
    • Improve the error message displayed when branch creation fails. · eb16e1e3
      Timothy Andrew authored 
      Note: This feature was developed independently on master while this was
in review. I've removed the conflicting bits and left the relevant
additions, mainly a test for `Gitlab::Git::Hook`. The original commit
message follows:

1. `gitlab-shell` outputs errors to `stderr`, but we weren't using this
   information, prior to this commit. Now we capture the `stderr`, and
   display it in the flash message when branch creation fails.

2. This can be used to display better errors for other git operation
   failures with small tweaks.

3. The return value of `Gitlab::Git::Hook#trigger` is changed from a
   simple `true`/`false` to a tuple of `[status, errors]`. All usages
   and tests have been updated to reflect this change.

4. This is only relevant to branch creation _from the Web UI_, since SSH
   and HTTP pushes access `gitlab-shell` either directly or through
   `gitlab-workhorse`.

5. A few minor changes need to be made on the `gitlab-shell` end. Right
   now, the `stderr` message it outputs is prefixed by "GitLab: ", which
   shows up in our flash message. This is better removed.
    • Modify the frontend for wildcard protected branches. · 2a5cb7ec
      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.
    • Support wildcard matches for protected branches at the model level. · f51af496
      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.
    • Merge branch '19496-fix-build' into 'master' · ba9ef7f3
      Stan Hu authored 
      Assert against `ActionMailer::Base.deliveries` relatively

- Closes #19496 
- Fixes `master` build


See merge request !5082
    • Assert against `ActionMailer::Base.deliveries` relatively. · f617bd76
      Timothy Andrew authored 
      - Look for a `change` in its size rather than asserting against an
  actual size.

- This previously failed because another spec had an email in
  `ActionMailer::Base.deliveries`, which failed this `be_nil` assertion.
  5. 04 Jul, 2016 22 commits
  7. 03 Jul, 2016 5 commits
  9. 02 Jul, 2016 3 commits
  11. 01 Jul, 2016 2 commits
    • Merge branch 'git-http-kerberos-ce' into 'master' · fc3402b7
      Douwe Maan authored 
      Groundwork for Kerberos SPNEGO (EE feature)

Refactor Projecst::GitHttpController to allow Kerberos integration in GitLab EE.

Companion to https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/509

See merge request !5037
    • Merge branch 'explicit-requesters-scope' into 'master' · d1c94f03
      Douwe Maan authored 
      Exclude requesters from Project#members, Group#members and User#members

## What does this MR do?

It excludes requesters from the `Project#members`, `Group#members` and `User#members` associations, and adds new `Project#requesters` and `Group#requesters` associations.

## Are there points in the code the reviewer needs to double check?

No.

## Why was this MR needed?

Without this, if you call `project.members`, requesters are included in the results! This is at best misleading, and at worst can lead to security issues. By excluding requesters from the `#members` associations, we avoid introducing security inadvertently since you have to call the `#requesters` association explicitly to get requesters.

## What are the relevant issue numbers?

This is something I realized while fixing the security issue #19102.

## Does this MR meet the acceptance criteria?

- [x] I don't think this needs a CHANGELOG since this is an internal change
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

See merge request !4946