Read about our upcoming Code of Conduct on this issue

  1. 02 Oct, 2019 1 commit
  2. 01 Oct, 2019 1 commit
  3. 25 Sep, 2019 1 commit
  4. 17 Sep, 2019 1 commit
  5. 11 Sep, 2019 1 commit
  6. 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.
      8eb4ed3504e3
  7. 30 Aug, 2019 1 commit
  8. 26 Aug, 2019 1 commit
  9. 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.
      4aa933c70dc5
    • 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
      bfd278a4d12e
  10. 13 Aug, 2019 2 commits
    • Bob Van Landuyt's avatar
      Rework retry strategy for remote mirrors · cdbb24e018d6
      Bob Van Landuyt authored
      **Prevention of running 2 simultaneous updates**
      
      Instead of using `RemoteMirror#update_status` and raise an error if
      it's already running to prevent the same mirror being updated at the
      same time we now use `Gitlab::ExclusiveLease` for that.
      
      When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
      and reschedule. We'll reschedule faster for the protected branches.
      
      If the mirror already ran since it was scheduled, the job will be
      skipped.
      
      **Error handling: Remote side**
      
      When an update fails because of a `Gitlab::Git::CommandError`, we
      won't track this error in sentry, this could be on the remote side:
      for example when branches have diverged.
      
      In this case, we'll try 3 times scheduled 1 or 5 minutes apart.
      
      In between, the mirror is marked as "to_retry", the error would be
      visible to the user when they visit the settings page.
      
      After 3 tries we'll mark the mirror as failed and notify the user.
      
      We won't track this error in sentry, as it's not likely we can help
      it.
      
      The next event that would trigger a new refresh.
      
      **Error handling: our side**
      
      If an unexpected error occurs, we mark the mirror as failed, but we'd
      still retry the job based on the regular sidekiq retries with
      backoff. Same as we used to
      
      The error would be reported in sentry, since its likely we need to do
      something about it.
      cdbb24e018d6
    • 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
      
      Fic
      dd57e6317344
  11. 08 Aug, 2019 1 commit
  12. 07 Aug, 2019 1 commit
    • Tiger Watson's avatar
      Use separate Kubernetes namespaces per environment · 6ddbfa68b32a
      Tiger Watson authored
      Kubernetes deployments on new clusters will now have
      a separate namespace per project environment, instead
      of sharing a single namespace for the project.
      
      Behaviour of existing clusters is unchanged.
      
      All new functionality is controlled by the
      :kubernetes_namespace_per_environment feature flag,
      which is safe to enable/disable at any time.
      6ddbfa68b32a
  13. 06 Aug, 2019 1 commit
  14. 01 Aug, 2019 1 commit
  15. 31 Jul, 2019 1 commit
  16. 25 Jul, 2019 3 commits
  17. 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`
      8801f515165e
  18. 23 Jul, 2019 2 commits
  19. 22 Jul, 2019 1 commit
  20. 13 Jul, 2019 1 commit
  21. 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
      too.
      32bc6b32a61b
  22. 21 Jun, 2019 1 commit
  23. 18 Jun, 2019 1 commit
    • James Fargher's avatar
      Make KubernetesService readonly · 36cec6be92c8
      James Fargher authored
      We are deprecating this service in favor of instance wide clusters.
      Therefore we removed some code that is not anymore needed for a
      readonly cluster and also we added some flags to allow for this
      deprecation. These flags are to be removed in the next release when
      we finally completelly remove KubernetesService.
      36cec6be92c8
  24. 17 Jun, 2019 1 commit
  25. 16 Jun, 2019 1 commit
  26. 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
      0a12e5313a85
  27. 29 May, 2019 1 commit
  28. 24 May, 2019 1 commit
  29. 20 May, 2019 1 commit
  30. 14 May, 2019 1 commit
  31. 07 May, 2019 1 commit
  32. 20 Apr, 2019 1 commit
  33. 10 Apr, 2019 2 commits
  34. 09 Apr, 2019 1 commit