1. 01 Dec, 2017 21 commits
  2. 29 Nov, 2017 1 commit
    • Bob Van Landuyt's avatar
      Create fork networks for forks for which the source was deleted. · 8202f0452dd9
      Bob Van Landuyt authored
      That way we can join forks-of-forks into the same network even if
      their original source was deleted.
      Consider the following:
        `awesome-oss/badger` is forked to `coolstuff/badger`, which is
        forked to `user-a/badger` which in turn is forked to
        When `awesome-oss/badger` is deleted, we will now create a fork
        network with `coolstuff/badger` as the root. The `user-a/badger`
        and `user-b/badger` projects will be added to the network.
  3. 23 Nov, 2017 1 commit
    • Yorick Peterse's avatar
      Added Rubocop config for background migrations · 160529ae7ce9
      Yorick Peterse authored
      This adds a Rubocop configuration file specific to
      lib/gitlab/background_migrations. This configuration will be used to
      (hopefully) make reviewing background migrations easier by enforcing
      stricter rules compared to the rest of GitLab. Because this
      configuration is directory specific it will only affect background
  4. 17 Nov, 2017 1 commit
  5. 14 Nov, 2017 1 commit
    • Bob Van Landuyt's avatar
      Don't try to create fork network memberships for forks of forks · 8de51094b5f5
      Bob Van Landuyt authored
      In case the root project of a Fork-of-fork is deleted, the ForkNetwork
      and the membership for that fork network is never created. In this
      case we shouldn't try to create the membership, since the parent
      membership will never be created.
      This means that these fork networks will be lost.
  6. 17 Oct, 2017 1 commit
  7. 09 Oct, 2017 1 commit
  8. 07 Oct, 2017 4 commits
  9. 05 Oct, 2017 2 commits
  10. 29 Sep, 2017 2 commits
    • Sean McGivern's avatar
      Make MR diff background migration less likely to time out · 12590f27c94e
      Sean McGivern authored
      This version does not use transactions, but individual statements. As we have
      unique constraints on the target tables for the inserts, we can just ignore
      uniqueness violations there (as long as we always insert the same batch size, in
      the same order).
      This means the spec now must use truncation, not a transaction, as the
      uniqueness violation means that the whole transaction for that spec would be
      invalid, which isn't what we'd want. In real-world use, this isn't run in a
      transaction anyway.
      This commit also wraps unhandled exceptions, for easier finding in Sentry, and
      logs with a consistent format, for easier searching.
    • Sean McGivern's avatar
      Insert at most 1,000 rows at once in MR diff background migration · 18726e90c42a
      Sean McGivern authored
      We were hitting the statement timeout for very large MR diffs. Now we insert at
      most 1,000 rows to `merge_request_diff_commits` in a single statement, or 100
      rows to `merge_request_diff_files`.
  11. 14 Sep, 2017 3 commits
  12. 18 Aug, 2017 1 commit
    • Sean McGivern's avatar
      Fix MR diffs background migration when file modes are missing · b50aaed65772
      Sean McGivern authored
      Guess the modes based on the following:
      1. If the file didn't exist, it's zero.
      2. If the diff contains 'Subproject commit', it might be a submodule, so 0600.
      3. Otherwise, it's 0644.
      This isn't perfect, but it doesn't have to be - it won't change file modes in
      the repository.
  13. 11 Aug, 2017 1 commit