1. 01 Nov, 2019 7 commits
    • Ray Paik's avatar
      Merge branch 'master' into 'master' · 8c22409d
      Ray Paik authored
      Correct typo in documentation
      
      See merge request gitlab-org/gitlab!19462
      8c22409d
    • Evan Read's avatar
      Merge branch 'eb-document-report-download-workaround' into 'master' · da61134d
      Evan Read authored
      Update docs to show how to make report artifact downloadable
      
      See merge request gitlab-org/gitlab!19426
      da61134d
    • Michael Kozono's avatar
      Merge branch '46686-create-eks-cluster-from-gitlab' into 'master' · cf7adeff
      Michael Kozono authored
      GitLab EKS Cluster backend services
      
      See merge request gitlab-org/gitlab!16758
      cf7adeff
    • Ash McKenzie's avatar
      Merge branch '30082-graphql-schema' into 'master' · 62e217bf
      Ash McKenzie authored
      Add a machine-readable graphql schema
      
      See merge request gitlab-org/gitlab!19199
      62e217bf
    • Ash McKenzie's avatar
      Merge branch '26016-edit-release-be' into 'master' · 5091932b
      Ash McKenzie authored
      Add `edit` endpoint for Release page
      
      See merge request gitlab-org/gitlab!17858
      5091932b
    • Tiger's avatar
      EKS creation docs · b3d885be
      Tiger authored
      b3d885be
    • Tiger's avatar
      Services for creating an EKS cluster via GitLab · e1932b5c
      Tiger authored
      There are several steps to this process:
      
      * GitLab assumes the role provided by the user and stores
        a set of temporary credentials on the provider record. By default
        these credentials are valid for one hour.
      
      * A CloudFormation stack is created, based on the template in
        vendor/aws/cloudformation/eks_cluster.yaml. This triggers creation
        of all resources required for an EKS cluster.
      
      * GitLab polls the status of the stack until all resources are ready,
        which takes somewhere between 10 and 15 minutes in most cases.
      
      * When the cluster is ready, GitLab stores the cluster details and
        fetches another set of temporary credentials, this time to allow
        connecting to the cluster via Kubeclient. These credentials
        are valid for one minute.
      
      * GitLab configures the worker nodes so that they are able to
        authenticate to the cluster, and creates a service account for
        itself for future operations.
      
      * Finally, all details and credentials that are no longer required
        are removed.
      e1932b5c
  2. 31 Oct, 2019 33 commits