1. 03 Oct, 2016 1 commit
  2. 01 Oct, 2016 3 commits
  3. 30 Sep, 2016 1 commit
  4. 29 Sep, 2016 30 commits
  5. 28 Sep, 2016 5 commits
    • Chris Wilson's avatar
      Update warn message for MySQL fix · 94696666
      Chris Wilson authored
      94696666
    • Robert Speicher's avatar
      Merge branch... · 2cae81ff
      Robert Speicher authored
      Merge branch '22352-cannot-install-gitlab-shell-on-ubuntu-server-with-no-previous-gitlab-install' into 'master'
      
      Correct gitlab-shell installation instructions in docs
      
      ## Why was this MR needed?
      
      With the introduction of repository storages validations it becomes necessary to add the flag `SKIP_STORAGE_VALIDATION` to the gitlab-shell install command, since that command will create the storage paths
      
      ## What are the relevant issue numbers?
      
      Closes #22352
      
      [ci skip]
      
      See merge request !6579
      2cae81ff
    • Alejandro Rodríguez's avatar
      [ci-skip] Correct gitlab-shell installation instructions in docs · 26221e7b
      Alejandro Rodríguez authored
      With the introduction of repository storages validations it becomes
      necessary to add the flag `SKIP_STORAGE_VALIDATION` to the gitlab-shell
      install command, since that command will create the storage paths
      26221e7b
    • Fatih Acet's avatar
      Merge branch 'pipelines-for-commit' into 'master' · 3830b857
      Fatih Acet authored
      Add Pipelines for Commit
      
      ## What does this MR do?
      This adds a Pipelines for Commit.
      
      I used existing view that we use to show pipelines. However, this is completely ugly with a lot of redundancy.
      
      ## Are there points in the code the reviewer needs to double check?
      
      ## Why was this MR needed?
      
      ## Screenshots (if relevant)
      ![Screen_Shot_2016-09-13_at_13.43.38](/uploads/0ac6e7d4825e32dba7ff7ab051da837c/Screen_Shot_2016-09-13_at_13.43.38.png)
      
      ## Does this MR meet the acceptance criteria?
      
      - [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
      - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
      - [ ] API support added
      - Tests
        - [ ] Added for this feature/bug
        - [ ] All builds are passing
      - [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
      - [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
      - [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
      - [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
      
      ## What are the relevant issue numbers?
      Resolves https://gitlab.com/gitlab-org/gitlab-ce/issues/18937
      
      See merge request !6322
      3830b857
    • Douwe Maan's avatar
      Merge branch 'lfs-ssh-authorization-fix' into 'master' · 029c0d79
      Douwe Maan authored
      Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called
      
      ## What does this MR do?
      
       Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called, instead return the saved token if one is present.
      
      This was causing a lot of 401s, leading to 403s, as state in #22527
      
      As it turns out, when pushing a lot of LFS objects, the LFS client was calling `git-lfs-authenticate` in the middle of the request again. This caused the `lfs_token` to be regenerated. The problem lies in that the LFS client was not aware of this change, and was still using the old token. This caused all subsequent requests to fail with a 401 error.
      
      Since HTTP Auth is protected by Rack Attack, this 401s where immediately flagged and resulted in the IP of the user being banned. 
      
      With this change, GitLab returns the value stored in Redis, if one is present, thus if the LFS client calls `git-lfs-authenticate` again during the request, the auth header will remain unchanged, allowing all subsequent requests to continue without issues.
      
      ## What are the relevant issue numbers?
      
      Fixes #22527
      
      cc @SeanPackham @jacobvosmaer-gitlab
      
      See merge request !6551
      029c0d79