1. 11 Jan, 2019 1 commit
  2. 07 Jan, 2019 5 commits
    • Gabriel Mazetto's avatar
      Only set as `read_only` when starting the per-project migration · 10d9a7b13e9f
      Gabriel Mazetto authored
      In the previous code, we locked the project during the migration
      scheduling step, which works fine for small setups, but can be
      problematic in really big installations.
      We now moved the logic to inside the worker, so we minimize the time a
      project will be read-only. We also make sure we only do that if
      reference counter is `0` (no current operation is in progress).
    • Reuben Pereira's avatar
      Add table and model for error tracking settings · 56c4cbadc13e
      Reuben Pereira authored
    • Steve Azzopardi's avatar
      Add explicit test for #latest_successful_build_for! · adbd6b49ae38
      Steve Azzopardi authored
      project.latest_successful_build_for! is being tested inside of `describe
      explicit. In doing so some duplication was generated but not
      `#latest_successful_build_for!` has full coverage unlike before.
      Move `create_pipeline` & `create_build` as helper methods for this spec
      to reduce duplication.
    • Steve Azzopardi's avatar
      Create `get_build` for project model · 4f7020aeb1af
      Steve Azzopardi authored
      Inside of `Projects::ArtifactsController` and
      `Projects::BuildArtifactsController` we fetching the build by id using
      active record directly which violates `CodeReuse/ActiveRecord` rubocop
      rule. Create `get_build` inside of `project` model which does the same
    • Steve Azzopardi's avatar
      Refactor project.latest_successful_builds_for def · 50a1dd6a79ff
      Steve Azzopardi authored
      `project.latest_successful_builds_for(ref)` is being used to find a
      single job all the time. This results into us having to call `find_by`
      inside of the controller which violates our CodeReuse/ActiveRecord
      rubocop rule.
      Refactor `project.latest_successful_builds_for(ref)` to
      `project.latest_successful_build_for(job_name, ref)` which will execute
      the `find_by` inside of the model.
      Also create `project.latest_successful_build_for!(job_name, ref)` which
      raises an exception instead of returning nil.
  3. 04 Jan, 2019 2 commits
  4. 03 Jan, 2019 3 commits
  5. 02 Jan, 2019 3 commits
  6. 21 Dec, 2018 1 commit
  7. 19 Dec, 2018 2 commits
  8. 13 Dec, 2018 1 commit
  9. 12 Dec, 2018 1 commit
  10. 08 Dec, 2018 12 commits
  11. 07 Dec, 2018 2 commits
    • Zeger-Jan van de Weg's avatar
      Allow public forks to be deduplicated · f837c22a38b1
      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.
    • Steve Azzopardi's avatar
      Add endpoint to download single artifact by ref · f5acf8e2b0ff
      Steve Azzopardi authored
      Add a new endpoint
      which is the close the web URL for consistency sake. This endpoint can
      be used to download a single file from artifacts for the specified ref
      and job.
      closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54626
  12. 06 Dec, 2018 1 commit
    • Jan Provaznik's avatar
      Use FastDestroy for deleting uploads · 7e0007c1cf72
      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.
  13. 05 Dec, 2018 2 commits
  14. 04 Dec, 2018 4 commits
    • Thong Kuah's avatar
      Unify into :group_clusters feature flag · 8954128c2d2d
      Thong Kuah authored
      With this MR, group clusters is now functional, so default to enabled.
      Have a single setting on the root ancestor group to enabled or disable
      group clusters feature as a whole
    • Thong Kuah's avatar
      Various improvements to hierarchy sorting · 25aaac800b56
      Thong Kuah authored
      - Rename ordered_group_clusters_for_project ->
      - Improve name of order option. It makes much more sense to have `hierarchy_order: :asc`
      and `hierarchy_order: :desc`
      - Allow ancestor_clusters_for_clusterable for group
      - Re-use code already present in Project
    • Thong Kuah's avatar
      Create k8s namespace for project in group clusters · afce416eb849
      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
    • Thong Kuah's avatar
      Teach Project about #all_clusters · c3bafafd4301
      Thong Kuah authored
      This returns a union of the project level clusters and group level
      clusters associated with this project.