1. 25 Jun, 2019 5 commits
  2. 24 Jun, 2019 8 commits
  3. 21 Jun, 2019 7 commits
  4. 20 Jun, 2019 3 commits
    • Mario de la Ossa's avatar
      18cf336cd0b4
    • Oswaldo Ferreira's avatar
      Automatically update MR merge-ref along merge status · b97da721ad9b
      Oswaldo Ferreira authored
      This couples the code that transitions the `MergeRequest#merge_status`
      and refs/merge-requests/:iid/merge ref update.
      
      In general, instead of directly telling `MergeToRefService` to update
      the merge ref, we should rely on `MergeabilityCheckService` to keep
      both the merge status and merge ref synced. Now, if the merge_status is
      `can_be_merged` it means the merge-ref is also updated to the latest.
      
      We've also updated the logic to be more systematic and less user-based.
      b97da721ad9b
    • Thong Kuah's avatar
      Run least expensive method first - has_metrics? · 6bf39b1e53f7
      Thong Kuah authored
      Success is relatively cheap compared to prometheus_adapter which can
      invoke deployment_platform which does a lot of work
      6bf39b1e53f7
  5. 19 Jun, 2019 4 commits
  6. 18 Jun, 2019 3 commits
    • Kartikey Tanna's avatar
      #57815 Password authentication disabled for UltraAuth users · 8910d051e5a2
      Kartikey Tanna authored
      Disabled password authentication for the users registered using
      omniauth-ultraauth strategy
      8910d051e5a2
    • Tiger's avatar
      Enable project-level JIT resource creation · 1c1961244115
      Tiger authored
      Previously this behaviour was only available to group
      and instance-level clusters, as some project clusters
      relied on Kubernetes credentials being passed through
      to the runner instead of having their resources managed
      by GitLab (which is not available when using JIT). These
      clusters have been migrated to unmanaged, so resources
      can be created on demand for the remaining managed clusters.
      1c1961244115
    • 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
  7. 17 Jun, 2019 2 commits
    • Tiger's avatar
      Allow switching clusters between managed/unmanaged · dede3eb4fa35
      Tiger authored
      Any resources created while the cluster was managed
      will be untouched, allowing users to set/unset this
      flag as they please.
      dede3eb4fa35
    • Tiger's avatar
      Don't use Kubernetes namespaces with no token · c3e3d11249f8
      Tiger authored
      Whenever we are selecting a namespace to use for a
      deployment or to query a cluster we want to exclude
      Kubernetes namespace records that don't have a token
      set as they will not have the required permissions.
      However when configuring clusters, we want to
      use the original namespace record even if it has no
      token, as a namespace has to be unique on a cluster.
      c3e3d11249f8
  8. 16 Jun, 2019 2 commits
  9. 14 Jun, 2019 4 commits
    • Nick Thomas's avatar
      66c8ddcee940
    • 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
    • Phil Hughes's avatar
      49132b0db6bc
    • Bob Van Landuyt's avatar
      Expose comments on Noteables in GraphQL · ad81ecf25a6f
      Bob Van Landuyt authored
      This exposes `Note`s on Issues & MergeRequests using a
      `Types::Notes::NoteableType` in GraphQL.
      
      Exposing notes on a new type can be done by implementing the
      `NoteableType` interface on the type. The presented object should
      be a `Noteable`.
      ad81ecf25a6f
  10. 13 Jun, 2019 2 commits