1. 02 Apr, 2019 1 commit
  2. 20 Mar, 2019 1 commit
  3. 05 Mar, 2019 1 commit
    • Gabriel Mazetto's avatar
      Skip project validation when switching storage layouts · b4f20502
      Gabriel Mazetto authored
      This is a fix for the Hashed Storage migration and Rollback procedure
      to ignore any project-level validation error that can happen in a
      long-running instance.
      
      There are many situations where defaults and acceptable values changed
      but, because we didn't provide a migration to "valid" attributes, it
      can happen that project will not be `valid? => true`.
      
      Because the changes we are making are limited to setting a project as
      read_only or changing the storage_level, it's safe to bypass validation.
      b4f20502
  4. 01 Mar, 2019 6 commits
  5. 27 Feb, 2019 1 commit
    • Jacopo's avatar
      Add project http fetch statistics API · 5ae9a44a
      Jacopo authored
      The API get projects/:id/traffic/fetches allows user with write
      access to the repository to get the number of clones for the
      last 30 days.
      5ae9a44a
  6. 20 Feb, 2019 1 commit
  7. 06 Feb, 2019 1 commit
  8. 04 Feb, 2019 1 commit
  9. 31 Jan, 2019 3 commits
  10. 25 Jan, 2019 4 commits
  11. 24 Jan, 2019 1 commit
  12. 22 Jan, 2019 2 commits
    • Kamil Trzciński's avatar
      Extract GitLab Pages using RubyZip · 1a8100cf
      Kamil Trzciński authored
      RubyZip allows us to perform strong validation of
      expanded paths where we do extract file.
      
      We introduce the following additional checks
      to extract routines:
      
      1. None of path components can be symlinked,
      2. We drop privileges support for directories,
      3. Symlink source needs to point within the target directory,
         like `public/`,
      4. The symlink source needs to exist ahead of time.
      1a8100cf
    • Gabriel Mazetto's avatar
      Refactored AfterRenameService to reduce coupling · d391dfb4
      Gabriel Mazetto authored
      We still rely on the Dirty API for project rename (before/after) values,
      but we don't access the dirty api from the service class anymore.
      
      The previous value is now part of the initialization, which makes it
      easier to test and the behavior is clearer.
      
      The same was done with the `rename_repo` on the Storage classes, we now
      provide before and after values as part of the method signature.
      d391dfb4
  13. 21 Jan, 2019 2 commits
    • Gabriel Mazetto's avatar
      Fixed legacy storage renaming code · 7a7948e6
      Gabriel Mazetto authored
      During a previous refactor on project model, code related to the
      hashed storage was extracted into AfterRenameService, see
      4b9c17f1.
      
      The "path_before" was changed from using `previous_changes['path']` to
      `path_was`. They are not equivalent. `path_was` exists reliably only
      *before* persisting to the database. After database persistence is
      confirmed, the value is moved to `previous_changes[:attribute_name]`.
      
      Because the repository/attachments rename or storage upgrade happens
      after it was persisted to the database, we were in fact not informing
      the right parameters (and therefore not doing what it was supposed to).
      7a7948e6
    • Francisco Javier López's avatar
  14. 18 Jan, 2019 1 commit
    • Oswaldo Ferreira's avatar
      Cleanup stale +deleted repo paths on project removal · 4fd848fc
      Oswaldo Ferreira authored
      1. When removing projects, we can end-up leaving the +deleted
      repo path dirty and not successfully removing the non-deleted
      namespace (mv process is not atomic and can be killed without
      fully moving the path).
      
      2. In order to solve that, we're adding a clean-up phase on
      ensure which will schedule possible staled +deleted path deletion.
      Note that we don't check the current state (if there is or not a
      repo) in order to schedule the deletion. That's intentional
      in order to leverage Gitlab::GitalyClient::NamespaceService#remove
      idempotency and ensure consistency.
      4fd848fc
  15. 16 Jan, 2019 2 commits
    • Yorick Peterse's avatar
      Refactor code for protecting default branches · 52eeb56b
      Yorick Peterse authored
      This refactors some of the logic used for protecting default branches,
      in particular Project#after_create_default_branch. The logic for this
      method is moved into a separate service class. Ideally we'd get rid of
      Project#after_create_default_branch entirely, but unfortunately
      Project#after_import depends on it. This means it has to stick around
      until we also refactor Project#after_import.
      
      For branch protection levels we introduce
      Gitlab::Access::BranchProtection, which provides a small wrapper around
      Integer based branch protection levels. Using this class removes the
      need for having to constantly refer to Gitlab::Access::PROTECTION_*
      constants.
      52eeb56b
    • Kamil Trzciński's avatar
  16. 09 Jan, 2019 1 commit
  17. 07 Jan, 2019 3 commits
  18. 06 Jan, 2019 1 commit
  19. 21 Dec, 2018 2 commits
  20. 18 Dec, 2018 1 commit
  21. 14 Dec, 2018 1 commit
  22. 11 Dec, 2018 1 commit
  23. 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
  24. 06 Dec, 2018 1 commit