1. 08 May, 2020 1 commit
    • Georges Racinet's avatar
      Gitlab::Mercurial adopted method for repo creation · d9eac4fb23dd
      Georges Racinet authored
      The main advantage is that this looks more uniform from the
      upper layers, at the price of making
      `Git::Repository.create_repository` accept arbitrary
      Also `Gitlab::Shell` is slowly being faded away. By
      calling the raw repo's `create_repository` we are
      actually anticipating on later versions.
      The saner structure can be also be felt in that we
      don't need to give some methods a classmethod
      version any more.
      branch : heptapod
  2. 31 Mar, 2020 1 commit
    • Georges Racinet's avatar
      hashed storage: adapting path to group HGRC · 3c0b374e853d
      Georges Racinet authored
      In the case of the hashed storage, we keep a
      subset of the directory hierarchy for namespaces
      and the repo HGRC includes from that, hence depending
      on the namespace path from the storage root and the
      depth of the hashed storage (currently a constant, at
      two intermediate subdirectories).
      In both the hashed and non-hashed cases, this is provided by
      `relative_path_from`, whose result is just `../../hgrc` in
      the non hashed case.
      The inclusion path is relative to the storage root, hence
      this independent of the storage location, which can
      change (reconfig, change of host by backup & restore)
      with no need to crawl through repositories.
      This partially defeats one of the advantages of the
      hash storage: avoiding too much top level directories.
      This shouldn't be critical for Heptapod because
      1. By the time we have instances that big that this cluttering
         is a problem, assuming we just don't use a FS with hashmap
         directories (XFS for instance), we'll be able to come up
         with other mechanisms
      2. It's about namespaces having either HGRC settings or subgroups.
         These should be the minority. After all, using subgroups
         reduces the number of toplevel groups.
      branch : heptapod
  3. 18 Feb, 2020 1 commit
  4. 25 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Gitaly compat: Mercurial repo creation · c6194361da75
      Georges Racinet authored
      Before this change, Mercurial repo creation wasn't
      executed if the Git repo was to be created with Gitaly.
      This is also the occasion to simplify the diff with respect
      to GitLab.
      The add_hg_repository method has useless blocks in this
      commit, just so that the diff against the parent stays
      We also take care of the wiki even though it's not it use
      within Heptapod so that
      - we don't make it worse
      - we don't got in the way of repo destruction (the Git wiki
        repo is removed only after successful remove of the Mercurial)
      branch : heptapod
  5. 05 Jan, 2020 1 commit
    • Georges Racinet's avatar
      Removing Gemnasium dependencies · 2e64dcb2a4fa
      Georges Racinet authored
      The gemnasium-gitlab-service gem is not available anymore,
      making the Rails app impossible to build and start from the
      given Gemfile.
      It would be completely useless anyway, because the Gemnasium
      service has closed, following the buyout by GitLab.
      Hence we remove anything about Gemnasium from Heptapod.
      branch : heptapod
  6. 17 Dec, 2019 1 commit
    • Georges Racinet's avatar
      Resynced to common ancestor of 10.4.0-rc2 and 10.5.0.pre · 9c3bdb25d5b0
      Georges Racinet authored
      Actually, 10.4.0-rc2 was not in the main history line that
      was Git master at the time, so we're reverting to b40d600d09d9.
      Also, we had some remnants from
      10.3.x security fixes (notably the wrapping of HTTParty into
      GitLab::HTTP, and the symlink protection in imports)
      Of course concrete Heptapod versions will be made with merges
      from GitLab stable branches that will put all stability and
      security fixes back.
      It's probably more interesting to look at the resulting diff
      with b40d600d09d9 than at the diff of the present revision.
      branch : heptapod
  7. 10 Nov, 2019 1 commit
  8. 01 Oct, 2019 1 commit
  9. 20 Sep, 2019 1 commit
  10. 18 Sep, 2019 2 commits
  11. 17 Sep, 2019 1 commit
  12. 16 Sep, 2019 1 commit
  13. 13 Sep, 2019 2 commits
  14. 10 Sep, 2019 2 commits
  15. 09 Sep, 2019 1 commit
  16. 05 Sep, 2019 1 commit
    • Fabio Pitino's avatar
      CE port for pipelines for external pull requests · 8eb4ed3504e3
      Fabio Pitino authored
      Detect if pipeline runs for a GitHub pull request
      When using a mirror for CI/CD only we register a pull_request
      webhook. When a pull_request webhook is received, if the
      source branch SHA matches the actual head of the branch in the
      repository we create immediately a new pipeline for the
      external pull request. Otherwise we store the
      pull request info for when the push webhook is received.
      When using "only/except: external_pull_requests" we can detect
      if the pipeline has a open pull request on GitHub and create or
      not the job based on that.
  17. 31 Aug, 2019 1 commit
  18. 30 Aug, 2019 1 commit
  19. 29 Aug, 2019 1 commit
  20. 28 Aug, 2019 1 commit
    • Victor Zagorodny's avatar
      Update CE files for GSD projects filter · 39182fb3be18
      Victor Zagorodny authored
      A new param with_security_reports was added to
      GET /groups/:id/projects API and the code to
      support this logic in GroupProjectsFinder and
      Project model. Also, a DB index was added to
      ci_job_artifacts table to speed up the search
      of security reports artifacts for projects
  21. 26 Aug, 2019 1 commit
  22. 21 Aug, 2019 1 commit
    • George Koltsov's avatar
      Add SortingPreference concern · 3c45523d4c1c
      George Koltsov authored
      Sorting preference functionality has been extracted
      from `IssuableCollections` to a new `SortingPreference`
      concern in order to reuse this functionality in projects
      (and groups in the future).
  23. 15 Aug, 2019 2 commits
    • Adam Hegyi's avatar
      Migrations for Cycle Analytics backend · 4aa933c70dc5
      Adam Hegyi authored
      This change lays the foundation for customizable cycle analytics stages.
      The main reason for the change is to extract the event definitions to
      separate objects (start_event, end_event) so that it could be easily
      customized later on.
    • Brett Walker's avatar
      Allow disabling group/project email notifications · bfd278a4d12e
      Brett Walker authored
      - Adds UI to configure in group and project settings
      - Removes notification configuration for users when
      disabled at group or project level
  24. 13 Aug, 2019 1 commit
    • Stan Hu's avatar
      Reduce Gitaly calls in PostReceive · dd57e6317344
      Stan Hu authored
      This commit reduces I/O load and memory utilization during PostReceive
      for the common case when no project hooks or services are set up.
      We saw a Gitaly N+1 issue in `CommitDelta` when many tags or branches
      are pushed. We can reduce this overhead in the common case because we
      observe that most new projects do not have any Web hooks or services,
      especially when they are first created. Previously, `BaseHooksService`
      unconditionally iterated through the last 20 commits of each ref to
      build the `push_data` structure. The `push_data` structured was used in
      numerous places:
      1. Building the push payload in `EventCreateService`
      2. Creating a CI pipeline
      3. Executing project Web or system hooks
      4. Executing project services
      5. As the return value of `BaseHooksService#execute`
      6. `BranchHooksService#invalidated_file_types`
      We only need to generate the full `push_data` for items 3, 4, and 6.
      Item 1: `EventCreateService` only needs the last commit and doesn't
      actually need the commit deltas.
      Item 2: In addition, `Ci::CreatePipelineService` only needed a subset of
      the parameters.
      Item 5: The return value of `BaseHooksService#execute` also wasn't being
      used anywhere.
      Item 6: This is only used when pushing to the default branch, so if
      many tags are pushed we can save significant I/O here.
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65878
  25. 08 Aug, 2019 1 commit
  26. 07 Aug, 2019 2 commits
  27. 06 Aug, 2019 1 commit
  28. 05 Aug, 2019 1 commit
    • Nick Thomas's avatar
      Speed up loading and filtering deploy keys and their projects · 81c8ec8cedc4
      Nick Thomas authored
      This commit changes how we eager-load projects, routes, and namespaces
      required by the deploy keys endpoint, getting a 10x improvement in my
      local testing.
      The endpoint still doesn't scale in-general, but going from ~13 seconds
      to dump a 63K result to generating the same thing in ~1.6 seconds seems
      like a good improvement to me.
  29. 31 Jul, 2019 1 commit
  30. 25 Jul, 2019 1 commit
    • Matija Čupić's avatar
      Rename latest_successful to be more explicit · 3526fc9f8660
      Matija Čupić authored
      * Reword Project#latest_successful_build_for to
      * Reword Ci::Pipeline#latest_successful_for to
  31. 24 Jul, 2019 1 commit
    • Kamil Trzciński's avatar
      Optimise import performance · 8801f515165e
      Kamil Trzciński authored
      - Fix `O(n)` complexity of `append_or_update_attribute`,
        we append objects to an array and re-save project
      - Remove the usage of `keys.include?` as it performs `O(n)`
        search, instead use `.has_key?`
      - Remove the usage of `.keys.first` as it performs a copy
        of all keys, instead use `.first.first`
  32. 23 Jul, 2019 2 commits
  33. 22 Jul, 2019 1 commit
  34. 19 Jul, 2019 1 commit
    • Nick Thomas's avatar
      Fix the project auto devops API · ebdaca6de2b4
      Nick Thomas authored
      If `project_auto_devops.enabled` is nil for a project, when setting any
      auto devops values via the API, we try to create a new row in the DB,
      instead of re-using the existing one. This leads to the project_id
      being set to nil, and the database `NOT NULL` constraint leading to a
      500 response.
      This commit resolves the issue by correctly detecting the presence of a
      ProjectAutoDevops row and re-using it. Persistence is also moved away
      from explicit `update!` calls and into relying on `autosave: true` on
      the model.