1. 06 Mar, 2019 1 commit
  2. 01 Mar, 2019 2 commits
  3. 28 Feb, 2019 1 commit
  4. 27 Feb, 2019 5 commits
  5. 26 Feb, 2019 2 commits
  6. 21 Feb, 2019 1 commit
  7. 20 Feb, 2019 1 commit
  8. 08 Feb, 2019 1 commit
  9. 07 Feb, 2019 1 commit
  10. 06 Feb, 2019 3 commits
  11. 05 Feb, 2019 1 commit
  12. 04 Feb, 2019 3 commits
  13. 28 Jan, 2019 1 commit
    • Mario de la Ossa's avatar
      Save sorting preference for Issues/MRs in BE · 49c74068
      Mario de la Ossa authored
      In order to let users' sorting preferences transfer between devices, we
      save the preference for issues and MRs (one preference for issues, one
      for MRs) in the backend inside the UserPreference object
      49c74068
  14. 25 Jan, 2019 1 commit
  15. 22 Jan, 2019 1 commit
  16. 17 Jan, 2019 1 commit
    • Shinya Maeda's avatar
      Cleanup legacy artifact background migration · ee79ee94
      Shinya Maeda authored
      Add migration and spec
      
      commit 3cc12e1268a6865f524d8fab1804f018312fdf5a
      Author: Shinya Maeda <shinya@gitlab.com>
      Date:   Tue Jan 8 19:34:31 2019 +0900
      
          Add changelog to this change
      
      commit 5006fc96e38db514956a35f53ae8ee536548a2e9
      Author: Shinya Maeda <shinya@gitlab.com>
      Date:   Tue Jan 8 19:32:56 2019 +0900
      
          Remove partial index from ci_builds artifact_file
      
          ok
      
          Update schema
      
      commit 3c956bdc02b195bc67d0327bf3748a631ea5466d
      Author: Shinya Maeda <shinya@gitlab.com>
      Date:   Mon Jan 7 21:41:27 2019 +0900
      
          Add frozen_string_literal: true
      
      commit 8c827cd616890160e6e8908843403a6f20c03236
      Author: Shinya Maeda <shinya@gitlab.com>
      Date:   Mon Jan 7 21:40:06 2019 +0900
      
          Set batch size 100
      
      commit aeee559777d3bdeadfd2b9bb61d460f2dc1fa8a6
      Author: Shinya Maeda <shinya@gitlab.com>
      Date:   Fri Jan 4 18:33:05 2019 +0900
      
          Cleanup legacy artifact background migration
      ee79ee94
  17. 15 Jan, 2019 1 commit
    • Stan Hu's avatar
      Only send one notification for failed remote mirror · 6fbbd4ab
      Stan Hu authored
      Retries in Sidekiq and in the remote mirror scheduler can cause repeated
      attempts in quick succession if the sync fails. Each failure will then
      send an e-mail to all project maintainers, which can spam users
      unnecessarily.
      
      Modify the logic to send one notification the first time the mirror
      fails by setting `error_notification_sent` to `true` and reset the
      flag after a successful sync.
      
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56222
      6fbbd4ab
  18. 07 Jan, 2019 1 commit
  19. 04 Jan, 2019 5 commits
  20. 03 Jan, 2019 2 commits
  21. 21 Dec, 2018 1 commit
  22. 19 Dec, 2018 1 commit
  23. 13 Dec, 2018 2 commits
  24. 07 Dec, 2018 1 commit
    • Zeger-Jan van de Weg's avatar
      Allow public forks to be deduplicated · 896c0bdb
      Zeger-Jan van de Weg authored
      When a project is forked, the new repository used to be a deep copy of everything
      stored on disk by leveraging `git clone`. This works well, and makes isolation
      between repository easy. However, the clone is at the start 100% the same as the
      origin repository. And in the case of the objects in the object directory, this
      is almost always going to be a lot of duplication.
      
      Object Pools are a way to create a third repository that essentially only exists
      for its 'objects' subdirectory. This third repository's object directory will be
      set as alternate location for objects. This means that in the case an object is
      missing in the local repository, git will look in another location. This other
      location is the object pool repository.
      
      When Git performs garbage collection, it's smart enough to check the
      alternate location. When objects are duplicated, it will allow git to
      throw one copy away. This copy is on the local repository, where to pool
      remains as is.
      
      These pools have an origin location, which for now will always be a
      repository that itself is not a fork. When the root of a fork network is
      forked by a user, the fork still clones the full repository. Async, the
      pool repository will be created.
      
      Either one of these processes can be done earlier than the other. To
      handle this race condition, the Join ObjectPool operation is
      idempotent. Given its idempotent, we can schedule it twice, with the
      same effect.
      
      To accommodate the holding of state two migrations have been added.
      1. Added a state column to the pool_repositories column. This column is
      managed by the state machine, allowing for hooks on transitions.
      2. pool_repositories now has a source_project_id. This column in
      convenient to have for multiple reasons: it has a unique index allowing
      the database to handle race conditions when creating a new record. Also,
      it's nice to know who the host is. As that's a short link to the fork
      networks root.
      
      Object pools are only available for public project, which use hashed
      storage and when forking from the root of the fork network. (That is,
      the project being forked from itself isn't a fork)
      
      In this commit message I use both ObjectPool and Pool repositories,
      which are alike, but different from each other. ObjectPool refers to
      whatever is on the disk stored and managed by Gitaly. PoolRepository is
      the record in the database.
      896c0bdb