1. 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.
  2. 31 Aug, 2019 1 commit
  3. 30 Aug, 2019 1 commit
  4. 29 Aug, 2019 1 commit
  5. 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
  6. 26 Aug, 2019 1 commit
  7. 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).
  8. 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
  9. 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
  10. 08 Aug, 2019 1 commit
  11. 07 Aug, 2019 2 commits
  12. 06 Aug, 2019 1 commit
  13. 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.
  14. 31 Jul, 2019 1 commit
  15. 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
  16. 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`
  17. 23 Jul, 2019 2 commits
  18. 22 Jul, 2019 1 commit
  19. 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.
  20. 15 Jul, 2019 1 commit
  21. 13 Jul, 2019 1 commit
  22. 12 Jul, 2019 2 commits
  23. 10 Jul, 2019 2 commits
  24. 09 Jul, 2019 1 commit
  25. 03 Jul, 2019 1 commit
  26. 28 Jun, 2019 1 commit
  27. 27 Jun, 2019 1 commit
    • Thong Kuah's avatar
      Remove group_clusters feature flag · 32bc6b32a61b
      Thong Kuah authored
      Now we have terminals for instance and group clusters we can remove the
      FF now. Deploying to group clusters has been working without complaints
  28. 26 Jun, 2019 1 commit
  29. 24 Jun, 2019 1 commit
    • Stan Hu's avatar
      Re-add ignore_column for import columns · be7ad9d5fcf4
      Stan Hu authored
      This `ignore_column` was present for a while but recently removed, but
      to ensure we don't get error 500s let's keep it for a while.
  30. 19 Jun, 2019 1 commit
  31. 16 Jun, 2019 1 commit
  32. 14 Jun, 2019 1 commit
    • Stan Hu's avatar
      Fix inability to set visibility_level on project via API · 0a12e5313a85
      Stan Hu authored
      Consider the scenario:
      1. The default visibility level is set to internal
      2. A user attempts to create a private project within a private group
      Previously this would always fail because default_value_for would
      overwrite the private visibility setting, no matter what
      visibility_level were specified. This was happening because
      default_value_for was confused by the default value of 0 specified by
      the database schema.
      default_value_for attempts to assign the default value in the block by
      checking whether the attribute has changed. The problem is that since
      the default value by the database was 0, and the user requested 0, this
      appeared as though no changes were made. As a result, default_value_for
      would always overwrite the user's preference.
      To fix this, we remove the use of default_value_for and only set the
      visibility level to the default application setting when no preference
      has been given at creation time.
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63158
  33. 12 Jun, 2019 1 commit
    • Fabio Pitino's avatar
      Expose ci_default_git_depth via project API · 4534a11f54fe
      Fabio Pitino authored
      Enable Get and Update of ci_default_git_depth for
      Project API.
      Renaming Project#default_git_depth to :ci_default_git_depth
      to give more context through the API usage.
      Add API documentation
  34. 06 Jun, 2019 1 commit
    • Krasimir Angelov's avatar
      Add project level git depth setting · 4bf5744f969a
      Krasimir Angelov authored
      Introduce default_git_depth in project's CI/CD settings and set it to
      50. Use it if there is no GIT_DEPTH variable specified. Apply this
      default only to newly created projects and keep it nil for old ones
      in order to not break pipelines that rely on non-shallow clones.
      default_git_depth can be updated from CI/CD Settings in the UI, must be
      either nil or integer between 0 and 1000 (incl).
      Inherit default_git_depth from the origin project when forking projects.
      MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it
      contains unique commit (i.e. merge commit) which doesn't exist in the
      other branch/tags refs. We need to add it cause otherwise it may break
      pipelines for old projects that have already enabled Pipelines for merge
      results and have git depth 0.
      Document new default_git_depth project CI/CD setting
  35. 29 May, 2019 1 commit