1. 03 Oct, 2019 1 commit
  2. 01 Oct, 2019 1 commit
  3. 30 Sep, 2019 1 commit
  4. 27 Sep, 2019 1 commit
  5. 25 Sep, 2019 1 commit
  6. 19 Sep, 2019 1 commit
  7. 18 Sep, 2019 1 commit
  8. 17 Sep, 2019 1 commit
  9. 04 Sep, 2019 1 commit
    • Eugenia Grieff's avatar
      Add service to transfer group milestones · ef45d0dff70c
      Eugenia Grieff authored
      - Add new service that transfers milestones
      from a group to a project
      - Include new service in Projects transfer service
      - Include FromUnion module in Milestone model
      to use in transfer service
      - Add specs for new milestones service
      - Add specs for transferring milestones in
      project transfer service
  10. 27 Aug, 2019 2 commits
  11. 20 Aug, 2019 1 commit
    • Luke Duncalfe's avatar
      Add service classes for mutating AwardEmoji · 1ac01388e243
      Luke Duncalfe authored
      Adding, destroying and toggling emoji previously lacked services and
      instead were performed through methods called on Awardable models.
      This led to inconsistencies where relevant todos would be marked as done
      only when emoji were awarded through our controllers, but not through
      the API. Todos could also be marked as done when an emoji was being
      Behaviour changes
      - Awarding emoji through the API will now mark a relevant Todo as done
      - Toggling an emoji off (destroying it) through our controllers will no
        longer mark a relevant Todo as done
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63372
  12. 15 Aug, 2019 2 commits
  13. 13 Aug, 2019 1 commit
    • 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
      **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
      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.
  14. 09 Aug, 2019 1 commit
  15. 07 Aug, 2019 1 commit
    • David Wilkins's avatar
      Convert RestClient to Gitlab::HTTP for Prometheus Monitor · fff37463b829
      David Wilkins authored
      - Closes #60024
      - Change PrometheusClient.new to accept a base url instead of an
        already created RestClient
      - Use Gitlab::HTTP in PrometheusClient instead of creating RestClient
        in PrometheusService
      - Move http_options from PrometheusService to
        PrometheusClient (follow_redirects: false)
      - ensure that base urls don't have the trailing slash
      - Created a `PrometheusClient#url` method that might not be strictly
      - Change rescued exceptions from RestClient::* to
        HTTParty::ResponseError where possible and StandardError for the
  16. 06 Aug, 2019 1 commit
  17. 02 Aug, 2019 1 commit
    • George Koltsov's avatar
      Add outbound requests setting for system hooks · 229fc90e22e0
      George Koltsov authored
      This MR adds new application setting to network section
      `allow_local_requests_from_system_hooks`. Prior to this change
      system hooks were allowed to do local network requests by default
      and we are adding an ability for admins to control it.
  18. 30 Jul, 2019 1 commit
  19. 29 Jul, 2019 1 commit
    • Thong Kuah's avatar
      Write out sham_rack gem · c1620a3bc3de
      Thong Kuah authored
      This means we have one less Net::HTTP monkeypatch.
      sham_rack cannot handle IPv6 addresses which means it breaks Net::HTTP
      connections because it monkey-patches Net::HTTP
  20. 25 Jul, 2019 1 commit
  21. 17 Jul, 2019 1 commit
  22. 25 Jun, 2019 1 commit
  23. 17 Jun, 2019 1 commit
  24. 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
  25. 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
  26. 06 Jun, 2019 2 commits
    • Krasimir Angelov's avatar
      Forks get default_git_depth 0 if the origin is nil · 795f726d5cd4
      Krasimir Angelov authored
      If the origin project has no default_git_depth set (i.e. nil) set the
      fork's default_git_depth to 0
    • 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
  27. 05 Jun, 2019 1 commit
  28. 31 May, 2019 1 commit
    • Shinya Maeda's avatar
      Remove legacy artifact related code · 4aaab394ff9e
      Shinya Maeda authored
      We've already migrated all the legacy artifacts to the new realm,
      which is ci_job_artifacts table.
      It's time to remove the old code base that is no longer used.
  29. 30 May, 2019 1 commit
    • Douwe Maan's avatar
      Protect Gitlab::HTTP against DNS rebinding attack · 1604aaa369ef
      Douwe Maan authored
      Gitlab::HTTP now resolves the hostname only once, verifies the IP is not
      blocked, and then uses the same IP to perform the actual request, while
      passing the original hostname in the `Host` header and SSL SNI field.
  30. 29 May, 2019 1 commit
  31. 21 May, 2019 1 commit
  32. 17 May, 2019 1 commit
  33. 10 May, 2019 1 commit
  34. 09 May, 2019 2 commits
  35. 06 May, 2019 1 commit
  36. 02 May, 2019 1 commit
    • Jan Provaznik's avatar
      Use git_garbage_collect_worker to run pack_refs · f3fc4142eab8
      Jan Provaznik authored
      PackRefs is not an expensive gitaly call - we want to
      call it more often (than as part of full `gc`) because
      it helps to keep number of refs files small - too many
      refs file may be a problem for deployments with
      slow storage.