1. 01 Apr, 2019 1 commit
    • Stan Hu's avatar
      Force a full GC after importing a project · d4c6a3af
      Stan Hu authored
      During a project import, it's possible that new branches are created by
      the importer to handle pull requests that have been created from forked
      projects, which would increment the `pushes_since_gc` value via
      `HousekeepingService.increment!` before a full garbage collection gets
      to run. This causes HousekeepingService to skip the full `git gc` and
      move to the incremental repack mode. To ensure that a garbage collection
      is run to pack refs and objects, explicitly execute the task.
      
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/59477
      d4c6a3af
  2. 25 Mar, 2019 1 commit
    • Sean McGivern's avatar
      Remove N+1 queries from users autocomplete · c5f9b2be
      Sean McGivern authored
      Both of these were related to groups:
      
      1. We need to preload routes (using the `with_route` scope) if we're
         going to get the group's path.
      2. We were counting each group's members separately.
      
      They're in the same commit because the spec for N+1 detection wouldn't
      pass with only one of these fixes.
      c5f9b2be
  3. 20 Mar, 2019 1 commit
  4. 13 Mar, 2019 1 commit
  5. 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
  6. 01 Mar, 2019 6 commits
  7. 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
  8. 20 Feb, 2019 1 commit
  9. 06 Feb, 2019 1 commit
  10. 04 Feb, 2019 1 commit
  11. 31 Jan, 2019 3 commits
  12. 25 Jan, 2019 4 commits
  13. 24 Jan, 2019 1 commit
  14. 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
  15. 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
  16. 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
  17. 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
  18. 09 Jan, 2019 1 commit
  19. 07 Jan, 2019 3 commits
  20. 06 Jan, 2019 1 commit
  21. 21 Dec, 2018 2 commits
  22. 18 Dec, 2018 1 commit
  23. 14 Dec, 2018 1 commit
  24. 11 Dec, 2018 1 commit