Read about our upcoming Code of Conduct on this issue

  1. 06 Jul, 2017 1 commit
    • Yorick Peterse's avatar
      Add many foreign keys to the projects table · 8b8987deee58
      Yorick Peterse authored
      This removes the need for relying on Rails' "dependent" option for data
      removal, which is _incredibly_ slow (even when using :delete_all) when
      deleting large amounts of data. This also ensures data consistency is
      enforced on DB level and not on application level (something Rails is
      really bad at).
      This commit also includes various migrations to add foreign keys to
      tables that eventually point to "projects" to ensure no rows get
      orphaned upon removing a project.
  2. 26 Jun, 2017 1 commit
  3. 21 Jun, 2017 1 commit
  4. 20 Jun, 2017 1 commit
  5. 16 Jun, 2017 1 commit
  6. 15 Jun, 2017 1 commit
  7. 31 May, 2017 2 commits
  8. 29 May, 2017 1 commit
  9. 23 May, 2017 2 commits
  10. 18 May, 2017 1 commit
  11. 12 May, 2017 2 commits
    • Sean McGivern's avatar
      Fix conflict resolution from corrupted upstream · acce5091d4bc
      Sean McGivern authored
      I don't know why this happens exactly, but given an upstream and fork repository
      from a customer, both of which required GC, resolving conflicts would corrupt
      the fork so badly that it couldn't be cloned.
      This isn't a perfect fix for that case, because the MR may still need to be
      merged manually, but it does ensure that the repository is at least usable.
      My best guess is that when we generate the index for the conflict
      resolution (which we previously did in the target project), we obtain a
      reference to an OID that doesn't exist in the source, even though we already
      fetch the refs from the target into the source.
      Explicitly setting the source project as the place to get the merge index from
      seems to prevent repository corruption in this way.
    • Valery Sizov's avatar
      Move update_assignee_cache_counts to the service · 502cc4b3f3b5
      Valery Sizov authored
  12. 09 May, 2017 1 commit
  13. 08 May, 2017 1 commit
  14. 04 May, 2017 1 commit
  15. 03 May, 2017 1 commit
  16. 26 Apr, 2017 1 commit
  17. 25 Apr, 2017 1 commit
    • Sean McGivern's avatar
      Show correct size when MR diff overflows · 5a29280b2387
      Sean McGivern authored
      The problem is that we often go via a diff object constructed from the diffs
      stored in the DB. Those diffs, by definition, don't overflow, so we don't have
      access to the 'correct' `real_size` - that is stored on the MR diff object
  18. 10 Apr, 2017 1 commit
  19. 08 Apr, 2017 3 commits
  20. 05 Apr, 2017 3 commits
  21. 03 Apr, 2017 2 commits
  22. 22 Mar, 2017 1 commit
  23. 21 Mar, 2017 1 commit
  24. 20 Mar, 2017 1 commit
  25. 14 Mar, 2017 1 commit
  26. 02 Mar, 2017 1 commit
  27. 01 Mar, 2017 1 commit
    • James Lopez's avatar
      Update occurrences of MWBS to MWPS · 060ee4e63884
      James Lopez authored
       Rename column in the database
       Rename fields related to import/export feature
       Rename API endpoints
       Rename documentation links
       Rename the rest of occurrences in the code
       Replace the images that contain the words "build succeeds" and docs referencing to them
       Make sure pipeline is green and nothing is missing.
      updated doc images
      renamed only_allow_merge_if_build_succeeds in projects and fixed references
      more updates
      fix some spec failures
      fix rubocop offences
      fix v3 api spec
      fix MR  specs
      fixed issues with partials
      fix MR spec
      fix alignment
      add missing v3 to v4 doc
      wip - refactor v3 endpoints
      fix specs
      fix a few typos
      fix project specs
      copy entities fully to V3
      fix  entity error
      more fixes
      fix failing specs
      fixed missing entities in V3 API
      remove comment
      updated code based on feedback
      fix spec
  28. 24 Feb, 2017 1 commit
    • Sean McGivern's avatar
      Only create unmergeable todos once · 18d882330379
      Sean McGivern authored
      Previously, we created an unmergeable todo when a merge request:
      1. Had merge when pipeline succeeds set.
      2. Became unmergeable.
      However, when merge when pipeline succeeds fails due to unmergeability,
      the flag isn't actually removed. And a merge request can become
      unmergeable multiple times, as every time the target branch is updated
      we need to re-check the mergeable status. This means that if the todo
      was marked done, and the MR was checked again, a new todo would be
      created for the same event.
      Instead of checking this, we should create the todo from the service
      responsible for merging when the pipeline succeeds. That way the todo is
      guaranteed to only be created when we care about it.
  29. 23 Feb, 2017 4 commits