1. 07 Jan, 2019 1 commit
  2. 21 Dec, 2018 1 commit
  3. 19 Dec, 2018 1 commit
  4. 12 Dec, 2018 1 commit
  5. 07 Dec, 2018 2 commits
    • 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.
    • Douwe Maan's avatar
      Remove RemoveOldWebHookLogsWorker · 536c1e40
      Douwe Maan authored
  6. 06 Dec, 2018 2 commits
    • Jan Provaznik's avatar
      Use FastDestroy for deleting uploads · 239fdc78
      Jan Provaznik authored
      It gathers list of file paths to delete before destroying
      the parent object. Then after the parent_object is destroyed
      these paths are scheduled for deletion asynchronously.
      Carrierwave needed associated model for deleting upload file.
      To avoid this requirement, simple Fog/File layer is used directly
      for file deletion, this allows us to use just a simple list of paths.
    • Nick Thomas's avatar
      Use BFG object maps to clean projects · 9395d198
      Nick Thomas authored
  7. 04 Dec, 2018 1 commit
    • Thong Kuah's avatar
      Create k8s namespace for project in group clusters · d54791e0
      Thong Kuah authored
      AFAIK the only relevant place is Projects::CreateService, this gets
      called when user creates a new project, forks a new project and does
      those things via the api.
      Also create k8s namespace for new group hierarchy
      when transferring project between groups
      Uses new Refresh service to create k8s namespaces
      - Ensure we use Cluster#cluster_project
      If a project has multiple clusters (EE), using Project#cluster_project
      is not guaranteed to return the cluster_project for this cluster. So
      switch to using Cluster#cluster_project - at this stage a cluster can
      only have 1 cluster_project.
      Also, remove rescue so that sidekiq can retry
  8. 19 Nov, 2018 1 commit
  9. 06 Nov, 2018 1 commit
  10. 02 Nov, 2018 1 commit
  11. 02 Oct, 2018 2 commits
  12. 07 Sep, 2018 1 commit
    • Stan Hu's avatar
      Delete a container registry asynchronously · 5830d114
      Stan Hu authored
      When a container registry has many tags, it's easy for the DELETE call to take more
      than 60 seconds and fail. This can also leave the registry in a bad state with
      null bytes since some of the images have been deleted with tags still pointing to them.
      In addition, we have to prevent users from accidentally initiating the delete multiple
      times or this could leave the registry with orphaned tags.
      This commit also adds a flash message to notify the user the registry is scheduled
      for deletion.
      Closes #49926, #51063
  13. 06 Sep, 2018 1 commit
  14. 06 Aug, 2018 1 commit
  15. 01 Aug, 2018 1 commit
    • Zeger-Jan van de Weg's avatar
      Add repository languages for projects · 79a5d768
      Zeger-Jan van de Weg authored
      Our friends at GitHub show the programming languages for a long time,
      and inspired by that this commit means to create about the same
      Language detection is done through Linguist, as before, where the
      difference is that we cache the result in the database. Also, Gitaly can
      incrementaly scan a repository. This is done through a shell out, which
      creates overhead of about 3s each run. For now this won't be improved.
      Scans are triggered by pushed to the default branch, usually `master`.
      However, one exception to this rule the charts page. If we're requesting
      this expensive data anyway, we just cache it in the database.
      Edge cases where there is no repository, or its empty are caught in the
      Repository model. This makes use of Redis caching, which is probably
      already loaded.
      The added model is called RepositoryLanguage, which will make it harder
      if/when GitLab supports multiple repositories per project. However, for
      now I think this shouldn't be a concern. Also, Language could be
      confused with the i18n languages and felt like the current name was
      suiteable too.
      Design of the Project#Show page is done with help from @dimitrieh. This
      change is not visible to the end user unless detections are done.
  16. 31 Jul, 2018 1 commit
  17. 30 Jul, 2018 1 commit
  18. 18 Jul, 2018 1 commit
  19. 06 Jul, 2018 1 commit
  20. 02 Jul, 2018 1 commit
  21. 27 Jun, 2018 1 commit
  22. 24 Jun, 2018 1 commit
  23. 06 Jun, 2018 5 commits
  24. 24 May, 2018 1 commit
    • Oswaldo Ferreira's avatar
      Persist truncated note diffs on a new table · bb8f2520
      Oswaldo Ferreira authored
      We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
      With this change we solve this problem and simplify a lot fetching this piece of info.
  25. 07 May, 2018 2 commits
  26. 04 May, 2018 2 commits
  27. 02 May, 2018 2 commits
  28. 25 Apr, 2018 1 commit
    • Sean McGivern's avatar
      Move NotificationService calls to Sidekiq · b5042e53
      Sean McGivern authored
      The NotificationService has to do quite a lot of work to calculate the
      recipients for an email. Where possible, we should try to avoid doing this in an
      HTTP request, because the mail are sent by Sidekiq anyway, so there's no need to
      schedule those emails immediately.
      This commit creates a generic Sidekiq worker that uses Global ID to serialise
      and deserialise its arguments, then forwards them to the NotificationService.
      The NotificationService gains an `#async` method, so you can replace:
          notification_service.new_issue(issue, current_user)
          notification_service.async.new_issue(issue, current_user)
      And have everything else work as normal, except that calculating the recipients
      will be done by Sidekiq, which will then schedule further Sidekiq jobs to send
      each email.
  29. 24 Apr, 2018 1 commit
  30. 20 Apr, 2018 1 commit