Read about our upcoming Code of Conduct on this issue

  1. 13 Nov, 2019 1 commit
  2. 12 Nov, 2019 1 commit
  3. 07 Nov, 2019 1 commit
  4. 05 Nov, 2019 1 commit
  5. 29 Oct, 2019 1 commit
  6. 24 Oct, 2019 1 commit
    • Bob Van Landuyt's avatar
      Only assign merge params when allowed · 69ea48debb0f
      Bob Van Landuyt authored
      When a user updates a merge request coming from a fork, they should
      not be able to set `force_remove_source_branch` if they cannot push
      code to the source project.
      
      Otherwise developers of the target project could remove the source
      branch of the source project by setting this flag through the API.
      69ea48debb0f
  7. 22 Oct, 2019 2 commits
  8. 21 Oct, 2019 1 commit
  9. 18 Oct, 2019 1 commit
  10. 10 Oct, 2019 1 commit
  11. 07 Oct, 2019 1 commit
  12. 18 Sep, 2019 1 commit
  13. 16 Sep, 2019 1 commit
  14. 13 Sep, 2019 1 commit
  15. 11 Sep, 2019 1 commit
  16. 07 Sep, 2019 1 commit
    • Jan Provaznik's avatar
      Use delete_all for deleting events · 0890bd20df0f
      Jan Provaznik authored
      Because we don't have any destroy callbacks (or other logic
      triggered on event destroy), there is no reason for deleting events
      inefficiently one by one, instead we can use :delete_all.
      0890bd20df0f
  17. 05 Sep, 2019 2 commits
  18. 03 Sep, 2019 1 commit
  19. 15 Aug, 2019 1 commit
    • Nick Thomas's avatar
      Only read rebase status from the model · 73774848de2f
      Nick Thomas authored
      Prior to 12.1, rebase status was looked up directly from Gitaly. In
      https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
      column was added to track the status instead. However, we couldn't stop
      looking at the gitaly status immediately, since some rebases may been
      running across the upgrade.
      
      Now that we're in 12.3, it is safe to remove the direct-to-gitaly
      lookup. This also happens to fix a 500 error that is seen when viewing
      an MR for a fork where the source project has been removed.
      
      We still look at the Gitaly status in the service, just in case Gitaly
      and Sidekiq get out of sync - I assume this is possible, and it's a
      relatively cheap check.
      
      Since we atomically check and set `merge_requests.rebase_jid`, we
      should never enqueue two `RebaseWorker` jobs in parallel.
      73774848de2f
  20. 09 Aug, 2019 1 commit
    • Igor's avatar
      Split MR widget into cached and non-cached serializers · 088ddc115489
      Igor authored
      Splits auto-refreshing of MR widget into 2 requests:
      
      - the one which uses etag-caching and invalidates the fields on change
      - the one without caching
      
      The idea is to gradually move all the fields to etag-cached endpoint
      088ddc115489
  21. 08 Aug, 2019 1 commit
  22. 31 Jul, 2019 1 commit
    • Oswaldo Ferreira's avatar
      Add exclusive lease to mergeability check process · d91dac70de97
      Oswaldo Ferreira authored
      Concurrent calls to UserMergeToRef RPC updating a single ref
      can lead to an opaque fail that is being rescued at Gitaly.
      
      So this commit adds an exclusive lease to the mergeability
      check process with the key as the current MR ID.
      d91dac70de97
  23. 29 Jul, 2019 1 commit
  24. 15 Jul, 2019 2 commits
  25. 11 Jul, 2019 1 commit
  26. 08 Jul, 2019 1 commit
    • Shinya Maeda's avatar
      Fix race condition on merge train ref generation · bb3feaf9bef9
      Shinya Maeda authored
      Today, Pipelines for merge train run on `refs/merge`,
      however, this causes a race condition that it can be
      overwritten by CheckMergeabilityService.
      
      This patch fixes the problem by generating `refs/train`
      for those pipelines.
      bb3feaf9bef9
  27. 04 Jul, 2019 1 commit
    • Nick Thomas's avatar
      Allow asynchronous rebase operations to be monitored · cc1c5b50197a
      Nick Thomas authored
      This MR introduces tracking of the `rebase_jid` for merge requests. As
      with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
      rebase is proceeding in sidekiq.
      
      After one release, we should remove the Gitaly-based lookup of rebases.
      It is much better to track this kind of thing via the database.
      cc1c5b50197a
  28. 03 Jul, 2019 1 commit
  29. 25 Jun, 2019 2 commits
    • Fabio Pitino's avatar
      Use actual_head_pipeline to enforce presence · 124ff4a2d65d
      Fabio Pitino authored
      124ff4a2d65d
    • Fabio Pitino's avatar
      Require pipeline if "Pipeline must succeed" is set · be4d4af76daf
      Fabio Pitino authored
      When a user sets only_allow_merge_if_pipeline_succeeds, also named
      as "Pipeline must succeed" project setting, we require the pipeline
      to be present.
      
      This solves race condition issues especially with external CI
      providers when a build is triggered externally but no pipelines are
      created in GitLab yet.
      
      Document that a head pipeline is expected when using "Pipeline
      must succeed" setting. Also explain limitations with the use of
      only/except where there may not be any jobs created and the merge
      request will not be allowed to be merged.
      be4d4af76daf
  30. 21 Jun, 2019 1 commit
  31. 20 Jun, 2019 1 commit
    • Oswaldo Ferreira's avatar
      Automatically update MR merge-ref along merge status · b97da721ad9b
      Oswaldo Ferreira authored
      This couples the code that transitions the `MergeRequest#merge_status`
      and refs/merge-requests/:iid/merge ref update.
      
      In general, instead of directly telling `MergeToRefService` to update
      the merge ref, we should rely on `MergeabilityCheckService` to keep
      both the merge status and merge ref synced. Now, if the merge_status is
      `can_be_merged` it means the merge-ref is also updated to the latest.
      
      We've also updated the logic to be more systematic and less user-based.
      b97da721ad9b
  32. 13 Jun, 2019 1 commit
  33. 11 Jun, 2019 1 commit
  34. 06 Jun, 2019 1 commit
  35. 03 Jun, 2019 1 commit
    • Shinya Maeda's avatar
      Abstract auto merge processes · 50ce7ba2ff35
      Shinya Maeda authored
      We have one auto merge strategy today - Merge When Pipeline
      Succeeds.
      
      In order to add more strategies for Merge Train feature,
      we abstract the architecture to be more extensible.
      
      Removed arguments
      
      Fix spec
      50ce7ba2ff35
  36. 31 May, 2019 1 commit