diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-20 11:10:13 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-06-20 11:10:13 +0000 |
| commit | 0ea3fcec397b69815975647f5e2aa5fe944a8486 (patch) | |
| tree | 7979381b89d26011bcf9bdc989a40fcc2f1ed4ff /doc/topics | |
| parent | 72123183a20411a36d607d70b12d57c484394c8e (diff) | |
| download | gitlab-ce-0ea3fcec397b69815975647f5e2aa5fe944a8486.tar.gz | |
Add latest changes from gitlab-org/gitlab@15-1-stable-eev15.1.0-rc42
Diffstat (limited to 'doc/topics')
29 files changed, 443 insertions, 414 deletions
diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md new file mode 100644 index 00000000000..653fe11c59d --- /dev/null +++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ec2.md @@ -0,0 +1,36 @@ +--- +stage: Configure +group: Configure +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Use Auto DevOps to deploy to EC2 + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6. + +To use [Auto DevOps](../index.md) to deploy to EC2: + +1. Define [your AWS credentials as CI/CD variables](../../../ci/cloud_deployment/index.md#authenticate-gitlab-with-aws). +1. In your `.gitlab-ci.yml` file, reference the `Auto-Devops.gitlab-ci.yml` template. +1. Define a job for the `build` stage named `build_artifact`. For example: + + ```yaml + # .gitlab-ci.yml + + include: + - template: Auto-DevOps.gitlab-ci.yml + + variables: + AUTO_DEVOPS_PLATFORM_TARGET: EC2 + + build_artifact: + stage: build + script: + - <your build script goes here> + artifacts: + paths: + - <built artifact> + ``` + +<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> +For a video walkthrough of this process, view [Auto Deploy to EC2](https://www.youtube.com/watch?v=4B-qSwKnacA). diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md new file mode 100644 index 00000000000..a9b466653bf --- /dev/null +++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_ecs.md @@ -0,0 +1,38 @@ +--- +stage: Configure +group: Configure +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Use Auto DevOps to deploy to Amazon ECS + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0. + +You can choose to target AWS ECS as a deployment platform instead of using Kubernetes. + +To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable. +To do so, follow these steps: + +1. In GitLab, on the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > CI/CD**. +1. Expand **Auto DevOps**. +1. Specify which AWS platform to target during the Auto DevOps deployment + by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable with one of the following values: + - `FARGATE` if the service you're targeting must be of launch type FARGATE. + - `ECS` if you're not enforcing any launch type check when deploying to ECS. + +When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly +[entered AWS credentials as variables](../../../ci/cloud_deployment/index.md#authenticate-gitlab-with-aws), +your application is deployed to AWS ECS. + +If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project, +only the deployment to Kubernetes runs. + +WARNING: +Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs +defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml). +However, it's not recommended to [include](../../../ci/yaml/index.md#includetemplate) +it on its own. This template is designed to be used with Auto DevOps only. It may change +unexpectedly causing your pipeline to fail if included on its own. Also, the job +names within this template may also change. Do not override these jobs' names in your +own pipeline, as the override stops working when the name changes. diff --git a/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md new file mode 100644 index 00000000000..aceb1ed8910 --- /dev/null +++ b/doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md @@ -0,0 +1,331 @@ +--- +stage: Configure +group: Configure +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE)** + +In this tutorial, we'll help you to get started with [Auto DevOps](../index.md) +through an example of how to deploy an application to Google Kubernetes Engine (GKE). + +You are using the GitLab native Kubernetes integration, so you don't need +to create a Kubernetes cluster manually using the Google Cloud Platform console. +You are creating and deploying an application that you create from a GitLab template. + +These instructions also work for self-managed GitLab instances. +Ensure your own [runners are configured](../../../ci/runners/index.md) and +[Google OAuth is enabled](../../../integration/google.md). + +To deploy a project to Google Kubernetes Engine, follow the steps below: + +1. [Configure your Google account](#configure-your-google-account) +1. [Create a new project from a template](#create-a-new-project-from-a-template) +1. [Create a Kubernetes cluster from GitLab](#create-a-kubernetes-cluster-from-gitlab) +1. [Install Ingress](#install-ingress) +1. [Configure your base domain](#configure-your-base-domain) +1. [Enable Auto DevOps](#enable-auto-devops-optional) +1. [Deploy the application](#deploy-the-application) + +## Configure your Google account + +Before creating and connecting your Kubernetes cluster to your GitLab project, +you need a [Google Cloud Platform account](https://console.cloud.google.com). +Sign in with an existing Google account, such as the one you use to access Gmail +or Google Drive, or create a new one. + +1. Follow the steps described in the ["Before you begin" section](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin) + of the Kubernetes Engine documentation to enable the required APIs and related services. +1. Ensure you've created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account) + with Google Cloud Platform. + +NOTE: +Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial), +and in partnership with Google, GitLab is able to offer an additional $200 for new +GCP accounts to get started with the GitLab integration with Google Kubernetes Engine. +[Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form) +and apply for credit. + +## Create a new project from a template + +Use a GitLab project template to get started. As the name suggests, +those projects provide a bare-bones application built on some well-known frameworks. + +1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select + **New project/repository**. +1. Go to the **Create from template** tab, where you can choose a Ruby on + Rails, Spring, or NodeJS Express project. + For this tutorial, use the Ruby on Rails template. + +  + +1. Give your project a name, optionally a description, and make it public so that + you can take advantage of the features available in the + [GitLab Ultimate plan](https://about.gitlab.com/pricing/). + +  + +1. Select **Create project**. + +Now that you've created a project, create the Kubernetes cluster +to deploy this project to. + +## Create a Kubernetes cluster from GitLab + +1. On your project's landing page, select the button **Add Kubernetes cluster**. + +  + +1. On the **Kubernetes clusters** page, select the **Create a new cluster** option from the **Actions** dropdown menu. + +1. On the **Connect a Kubernetes cluster** page, select **Google GKE**. + +1. Connect with your Google account, and select **Allow** to allow access to your + Google account. (This authorization request is only displayed the first time + you connect GitLab with your Google account.) + + After authorizing access, the **Connect a Kubernetes cluster** page + is displayed. + +1. In the **Enter your Kubernetes cluster certificate details** section, provide + details about your cluster: + + - **Kubernetes cluster name** + - **Environment scope** - Leave this field unchanged. + - **Google Cloud Platform project** - Select a project. When you + [configured your Google account](#configure-your-google-account), a project + should have already been created for you. + - **Zone** - The [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to + create the cluster in. + - **Number of nodes** + - **Machine type** - For more information about + [machine types](https://cloud.google.com/compute/docs/machine-types), see Google's documentation. + - **Enable Cloud Run for Anthos** - Select this checkbox to use the + [Cloud Run](../../../user/project/clusters/add_gke_clusters.md#cloud-run-for-anthos), + Istio, and HTTP Load Balancing add-ons for this cluster. + - **GitLab-managed cluster** - Select this checkbox to + [allow GitLab to manage namespace and service accounts](../../../user/project/clusters/gitlab_managed_clusters.md) for this cluster. + +1. Select **Create Kubernetes cluster**. + +After a couple of minutes, the cluster is created. You can also see its +status on your [GCP dashboard](https://console.cloud.google.com/kubernetes). + +## Install Ingress + +After your cluster is running, you must install NGINX Ingress Controller as a +load balancer, to route traffic from the internet to your application. +Install the NGINX Ingress Controller +through the GitLab [Cluster management project template](../../../user/clusters/management_project_template.md), +or manually with Google Cloud Shell: + +1. Go to your cluster's details page, and select the **Advanced Settings** tab. +1. Select the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console. +1. On the GKE cluster page, select **Connect**, then select **Run in Cloud Shell**. +1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller: + + ```shell + kubectl create ns gitlab-managed-apps + helm repo add stable https://charts.helm.sh/stable + helm repo update + helm install ingress stable/nginx-ingress -n gitlab-managed-apps + + # Check that the ingress controller is installed successfully + kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps + ``` + +## Configure your base domain + +Follow these steps to configure the base domain where you access your apps. + +1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can + get the external IP address with the following command: + + ```shell + kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip' + ``` + + Replace `gitlab-managed-apps` if you have overwritten your namespace. + + Copy this IP address, as you need it in the next step. + +1. Go back to the cluster page on GitLab, and go to the **Details** tab. + - Add your **Base domain**. For this example, use the domain `<IP address>.nip.io`. + - Select **Save changes**. + +  + +## Enable Auto DevOps (optional) + +While Auto DevOps is enabled by default, Auto DevOps can be disabled at both +the instance level (for self-managed instances) and the group level. Complete +these steps to enable Auto DevOps if it's disabled: + +1. Go to **Settings > CI/CD > Auto DevOps**, and select **Expand**. +1. Select **Default to Auto DevOps pipeline** to display more options. +1. In **Deployment strategy**, select your desired [continuous deployment strategy](../requirements.md#auto-devops-deployment-strategy) + to deploy the application to production after the pipeline successfully runs on the default branch. +1. Select **Save changes**. + +  + +After you save your changes, GitLab creates a new pipeline. To view it, go to +**{rocket}** **CI/CD > Pipelines**. + +In the next section, we explain what each job does in the pipeline. + +## Deploy the application + +When your pipeline runs, what is it doing? + +To view the jobs in the pipeline, select the pipeline's status badge. The +**{status_running}** icon displays when pipeline jobs are running, and updates +without refreshing the page to **{status_success}** (for success) or +**{status_failed}** (for failure) when the jobs complete. + +The jobs are separated into stages: + + + +- **Build** - The application builds a Docker image and uploads it to your project's + [Container Registry](../../../user/packages/container_registry/index.md) ([Auto Build](../stages.md#auto-build)). +- **Test** - GitLab runs various checks on the application, but all jobs except `test` + are allowed to fail in the test stage: + + - The `test` job runs unit and integration tests by detecting the language and + framework ([Auto Test](../stages.md#auto-test)) + - The `code_quality` job checks the code quality and is allowed to fail + ([Auto Code Quality](../stages.md#auto-code-quality)) + - The `container_scanning` job checks the Docker container if it has any + vulnerabilities and is allowed to fail ([Auto Container Scanning](../stages.md#auto-container-scanning)) + - The `dependency_scanning` job checks if the application has any dependencies + susceptible to vulnerabilities and is allowed to fail + ([Auto Dependency Scanning](../stages.md#auto-dependency-scanning)) + - Jobs suffixed with `-sast` run static analysis on the current code to check for potential + security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast)) + - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection)) + - The `license_scanning` job searches the application's dependencies to determine each of their + licenses and is allowed to fail + ([Auto License Compliance](../stages.md#auto-license-compliance)) + +- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job. + To learn more, see [Dynamic Application Security Testing (DAST)](../../../user/application_security/dast/index.md). + +- **Production** - After the tests and checks finish, the application deploys in + Kubernetes ([Auto Deploy](../stages.md#auto-deploy)). + +- **Performance** - Performance tests are run on the deployed application + ([Auto Browser Performance Testing](../stages.md#auto-browser-performance-testing)). + +- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job. + +After running a pipeline, you should view your deployed website and learn how +to monitor it. + +### Monitor your project + +After successfully deploying your application, you can view its website and check +on its health on the **Environments** page by navigating to +**Deployments > Environments**. This page displays details about +the deployed applications, and the right-hand column displays icons that link +you to common environment tasks: + + + +- **Open live environment** (**{external-link}**) - Opens the URL of the application deployed in production +- **Monitoring** (**{chart}**) - Opens the metrics page where Prometheus collects data + about the Kubernetes cluster and how the application + affects it in terms of memory usage, CPU usage, and latency +- **Deploy to** (**{play}** **{chevron-lg-down}**) - Displays a list of environments you can deploy to +- **Terminal** (**{terminal}**) - Opens a [web terminal](../../../ci/environments/index.md#web-terminals-deprecated) + session inside the container where the application is running +- **Re-deploy to environment** (**{repeat}**) - For more information, see + [Retrying and rolling back](../../../ci/environments/index.md#retry-or-roll-back-a-deployment) +- **Stop environment** (**{stop}**) - For more information, see + [Stopping an environment](../../../ci/environments/index.md#stop-an-environment) + +GitLab displays the [deploy board](../../../user/project/deploy_boards.md) below the +environment's information, with squares representing pods in your +Kubernetes cluster, color-coded to show their status. Hovering over a square on +the deploy board displays the state of the deployment, and selecting the square +takes you to the pod's logs page. + +NOTE: +The example shows only one pod hosting the application at the moment, but you can add +more pods by defining the [`REPLICAS` CI/CD variable](../customize.md#cicd-variables) +in **Settings > CI/CD > Variables**. + +### Work with branches + +Following the [GitLab flow](../../gitlab_flow.md#working-with-feature-branches), +you should next create a feature branch to add content to your application: + +1. In your project's repository, go to the following file: `app/views/welcome/index.html.erb`. + This file should only contain a paragraph: `<p>You're on Rails!</p>`. +1. Open the GitLab [Web IDE](../../../user/project/web_ide/index.md) to make the change. +1. Edit the file so it contains: + + ```html + <p>You're on Rails! Powered by GitLab Auto DevOps.</p> + ``` + +1. Stage the file. Add a commit message, then create a new branch and a merge request + by selecting **Commit**. + +  + +After submitting the merge request, GitLab runs your pipeline, and all the jobs +in it, as [described previously](#deploy-the-application), in addition to +a few more that run only on branches other than the default branch. + + + +After a few minutes a test fails, which means a test was +'broken' by your change. Select the failed `test` job to see more information +about it: + +```plaintext +Failure: +WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]: +<You're on Rails!> expected but was +<You're on Rails! Powered by GitLab Auto DevOps.>.. +Expected 0 to be >= 1. + +bin/rails test test/controllers/welcome_controller_test.rb:4 +``` + +To fix the broken test: + +1. Return to your merge request. +1. In the upper right corner, select **Code**, then select **Open in Gitpod**. +1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb` + file, and select it to open it. +1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.` +1. Select **Commit**. +1. In the left-hand column, under **Unstaged changes**, select the checkmark icon + (**{stage-all}**) to stage the changes. +1. Write a commit message, and select **Commit**. + +Return to the **Overview** page of your merge request, and you should not only +see the test passing, but also the application deployed as a +[review application](../stages.md#auto-review-apps). You can visit it by selecting +the **View app** **{external-link}** button to see your changes deployed. + + + +After merging the merge request, GitLab runs the pipeline on the default branch, +and then deploys the application to production. + +## Conclusion + +After implementing this project, you should have a solid understanding of the basics of Auto DevOps. +You started from building and testing, to deploying and monitoring an application +all in GitLab. Despite its automatic nature, Auto DevOps can also be configured +and customized to fit your workflow. Here are some helpful resources for further reading: + +1. [Auto DevOps](../index.md) +1. [Multiple Kubernetes clusters](../multiple_clusters_auto_devops.md) +1. [Incremental rollout to production](../customize.md#incremental-rollout-to-production) +1. [Disable jobs you don't need with CI/CD variables](../customize.md#cicd-variables) +1. [Use your own buildpacks to build your application](../customize.md#custom-buildpacks) +1. [Prometheus monitoring](../../../user/project/integrations/prometheus.md) diff --git a/doc/topics/autodevops/img/guide_base_domain_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_base_domain_v12_3.png Binary files differindex 7d3b6a2f905..7d3b6a2f905 100644 --- a/doc/topics/autodevops/img/guide_base_domain_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_base_domain_v12_3.png diff --git a/doc/topics/autodevops/img/guide_create_project_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_create_project_v12_3.png Binary files differindex a22730520ef..a22730520ef 100644 --- a/doc/topics/autodevops/img/guide_create_project_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_create_project_v12_3.png diff --git a/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_enable_autodevops_v12_3.png Binary files differindex a3bcaeb99ae..a3bcaeb99ae 100644 --- a/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_enable_autodevops_v12_3.png diff --git a/doc/topics/autodevops/img/guide_environments_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_environments_v12_3.png Binary files differindex 87253f9929d..87253f9929d 100644 --- a/doc/topics/autodevops/img/guide_environments_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_environments_v12_3.png diff --git a/doc/topics/autodevops/img/guide_ide_commit_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_ide_commit_v12_3.png Binary files differindex afea0dc8fb4..afea0dc8fb4 100644 --- a/doc/topics/autodevops/img/guide_ide_commit_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_ide_commit_v12_3.png diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_merge_request_review_app_v12_3.png Binary files differindex e94654f4e50..e94654f4e50 100644 --- a/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_merge_request_review_app_v12_3.png diff --git a/doc/topics/autodevops/img/guide_merge_request_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_merge_request_v12_3.png Binary files differindex 5565be701cd..5565be701cd 100644 --- a/doc/topics/autodevops/img/guide_merge_request_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_merge_request_v12_3.png diff --git a/doc/topics/autodevops/img/guide_pipeline_stages_v13_0.png b/doc/topics/autodevops/cloud_deployments/img/guide_pipeline_stages_v13_0.png Binary files differindex fb102879556..fb102879556 100644 --- a/doc/topics/autodevops/img/guide_pipeline_stages_v13_0.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_pipeline_stages_v13_0.png diff --git a/doc/topics/autodevops/img/guide_project_landing_page_v12_10.png b/doc/topics/autodevops/cloud_deployments/img/guide_project_landing_page_v12_10.png Binary files differindex 54e7141dad2..54e7141dad2 100644 --- a/doc/topics/autodevops/img/guide_project_landing_page_v12_10.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_project_landing_page_v12_10.png diff --git a/doc/topics/autodevops/img/guide_project_template_v12_3.png b/doc/topics/autodevops/cloud_deployments/img/guide_project_template_v12_3.png Binary files differindex 2b8d7224747..2b8d7224747 100644 --- a/doc/topics/autodevops/img/guide_project_template_v12_3.png +++ b/doc/topics/autodevops/cloud_deployments/img/guide_project_template_v12_3.png diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index e2d984dbbff..dfc2828e383 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -409,6 +409,7 @@ applications. | `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | The builder used when building with Cloud Native Buildpacks. The default builder is `heroku/buildpacks:18`. [More details](stages.md#auto-build-using-cloud-native-buildpacks). | | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | Extra arguments to be passed to the `docker build` command. Note that using quotes doesn't prevent word splitting. [More details](#passing-arguments-to-docker-build). | | `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI/CD variable names](#forward-cicd-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). | +| `AUTO_DEVOPS_BUILD_IMAGE_CNB_PORT` | In GitLab 15.0 and later, port exposed by the generated Docker image. Set to `false` to prevent exposing any ports. Defaults to `5000`. | | `AUTO_DEVOPS_CHART` | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app). | | `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. | | `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | Used to set the name of the Helm repository. Defaults to `gitlab`. | @@ -466,6 +467,8 @@ The following table lists CI/CD variables related to the database. | `POSTGRES_VERSION` | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments uses the default version `9.6.2`. | | `POSTGRES_HELM_UPGRADE_VALUES_FILE` | In GitLab 13.8 and later, and when using [auto-deploy-image v2](upgrading_auto_deploy_dependencies.md), this variable allows the `helm upgrade` values file for PostgreSQL to be overridden. Defaults to `.gitlab/auto-deploy-postgres-values.yaml`. | | `POSTGRES_HELM_UPGRADE_EXTRA_ARGS` | In GitLab 13.8 and later, and when using [auto-deploy-image v2](upgrading_auto_deploy_dependencies.md), this variable allows extra PostgreSQL options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. | +| `POSTGRES_CHART_REPOSITORY` | Helm Chart repository used to search for PostgreSQL chart. Defaults to `https://raw.githubusercontent.com/bitnami/charts/eb5f9a9513d987b519f0ecd732e7031241c50328/bitnami`. | +| `POSTGRES_CHART_VERSION` | Helm Chart version used for PostgreSQL chart. Defaults to `8.2.1`. | ### Disable jobs @@ -669,7 +672,7 @@ The percentage is based on the `REPLICAS` CI/CD variable, and defines the number pods you want to have for your deployment. If the value is `10`, and you run the `10%` rollout job, there is `1` new pod and `9` old ones. -To start a job, click the play icon (**{play}**) next to the job's name. You're not +To start a job, select the play icon (**{play}**) next to the job's name. You're not required to go from `10%` to `100%`, you can jump to whatever job you want. You can also scale down by running a lower percentage job, just before hitting `100%`. Once you get to `100%`, you can't scale down, and you'd have to roll diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index c8efc40a4cd..6d4f6eb698e 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -234,16 +234,9 @@ and clear the **Default to Auto DevOps pipeline** checkbox. ### Quick start -To guide you through the process of setting up Auto DevOps to deploy to a Kubernetes cluster on -Google Kubernetes Engine (GKE), see the [quick start guide](quick_start_guide.md). - -You can also follow the quick start for the general steps, but deploy to -[AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs) instead. - -If you're a self-managed user, before deploying to GKE, a GitLab administrator needs to: - -1. Configure the [Google OAuth 2.0 OmniAuth Provider](../../integration/google.md). -1. Configure a cluster on GKE. +- [Use Auto DevOps to deploy to a Kubernetes cluster on Google Kubernetes Engine (GKE)](cloud_deployments/auto_devops_with_gke.md) +- [Use Auto DevOps to deploy to EC2](cloud_deployments/auto_devops_with_ec2.md) +- [Use Auto DevOps to deploy to ECS](cloud_deployments/auto_devops_with_ecs.md) ## Upgrade Auto DevOps dependencies when updating GitLab diff --git a/doc/topics/autodevops/multiple_clusters_auto_devops.md b/doc/topics/autodevops/multiple_clusters_auto_devops.md index 8156ae7c7ac..9c766385e66 100644 --- a/doc/topics/autodevops/multiple_clusters_auto_devops.md +++ b/doc/topics/autodevops/multiple_clusters_auto_devops.md @@ -35,7 +35,8 @@ To add a different cluster for each environment: 1. Navigate to your project's **Infrastructure > Kubernetes clusters**. 1. Create the Kubernetes clusters with their respective environment scope, as described from the table above. -1. After creating the clusters, navigate to each cluster and [install Ingress](quick_start_guide.md#install-ingress). +1. After creating the clusters, navigate to each cluster and + [install Ingress](cloud_deployments/auto_devops_with_gke.md#install-ingress). Wait for the Ingress IP address to be assigned. 1. Make sure you've [configured your DNS](requirements.md#auto-devops-base-domain) with the specified Auto DevOps domains. diff --git a/doc/topics/autodevops/prepare_deployment.md b/doc/topics/autodevops/prepare_deployment.md index 7c9bf5a770e..22a50df7f54 100644 --- a/doc/topics/autodevops/prepare_deployment.md +++ b/doc/topics/autodevops/prepare_deployment.md @@ -51,7 +51,7 @@ as other environment [variables](../../ci/variables/index.md#cicd-variable-prece If you don't specify the base domain in your projects and groups, Auto DevOps uses the instance-wide **Auto DevOps domain**. -Auto DevOps requires a wildcard DNS A record matching the base domains. For +Auto DevOps requires a wildcard DNS `A` record matching the base domains. For a base domain of `example.com`, you'd need a DNS entry like: ```plaintext diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 8d1bf7adc7f..a524b6e6451 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -1,331 +1,11 @@ --- -stage: Configure -group: Configure -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +redirect_to: '../autodevops/cloud_deployments/auto_devops_with_gke.md' +remove_date: '2022-09-18' --- -# Tutorial: Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE)** +This document was moved to [another location](../autodevops/cloud_deployments/auto_devops_with_gke.md). -In this tutorial, we'll help you to get started with [Auto DevOps](index.md) -through an example of how to deploy an application to Google Kubernetes Engine (GKE). - -You are using the GitLab native Kubernetes integration, so you don't need -to create a Kubernetes cluster manually using the Google Cloud Platform console. -You are creating and deploying an application that you create from a GitLab template. - -These instructions also work for self-managed GitLab instances. -Ensure your own [runners are configured](../../ci/runners/index.md) and -[Google OAuth is enabled](../../integration/google.md). - -To deploy a project to Google Kubernetes Engine, follow the steps below: - -1. [Configure your Google account](#configure-your-google-account) -1. [Create a new project from a template](#create-a-new-project-from-a-template) -1. [Create a Kubernetes cluster from GitLab](#create-a-kubernetes-cluster-from-gitlab) -1. [Install Ingress](#install-ingress) -1. [Configure your base domain](#configure-your-base-domain) -1. [Enable Auto DevOps](#enable-auto-devops-optional) -1. [Deploy the application](#deploy-the-application) - -## Configure your Google account - -Before creating and connecting your Kubernetes cluster to your GitLab project, -you need a [Google Cloud Platform account](https://console.cloud.google.com). -Sign in with an existing Google account, such as the one you use to access Gmail -or Google Drive, or create a new one. - -1. Follow the steps described in the ["Before you begin" section](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin) - of the Kubernetes Engine documentation to enable the required APIs and related services. -1. Ensure you've created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account) - with Google Cloud Platform. - -NOTE: -Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial), -and in partnership with Google, GitLab is able to offer an additional $200 for new -GCP accounts to get started with the GitLab integration with Google Kubernetes Engine. -[Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form) -and apply for credit. - -## Create a new project from a template - -Use a GitLab project template to get started. As the name suggests, -those projects provide a bare-bones application built on some well-known frameworks. - -1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select - **New project/repository**. -1. Go to the **Create from template** tab, where you can choose a Ruby on - Rails, Spring, or NodeJS Express project. - For this tutorial, use the Ruby on Rails template. - -  - -1. Give your project a name, optionally a description, and make it public so that - you can take advantage of the features available in the - [GitLab Ultimate plan](https://about.gitlab.com/pricing/). - -  - -1. Select **Create project**. - -Now that you've created a project, create the Kubernetes cluster -to deploy this project to. - -## Create a Kubernetes cluster from GitLab - -1. On your project's landing page, select the button **Add Kubernetes cluster**. - -  - -1. On the **Kubernetes clusters** page, select the **Create a new cluster** option from the **Actions** dropdown menu. - -1. On the **Connect a Kubernetes cluster** page, select **Google GKE**. - -1. Connect with your Google account, and select **Allow** to allow access to your - Google account. (This authorization request is only displayed the first time - you connect GitLab with your Google account.) - - After authorizing access, the **Connect a Kubernetes cluster** page - is displayed. - -1. In the **Enter your Kubernetes cluster certificate details** section, provide - details about your cluster: - - - **Kubernetes cluster name** - - **Environment scope** - Leave this field unchanged. - - **Google Cloud Platform project** - Select a project. When you - [configured your Google account](#configure-your-google-account), a project - should have already been created for you. - - **Zone** - The [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to - create the cluster in. - - **Number of nodes** - - **Machine type** - For more information about - [machine types](https://cloud.google.com/compute/docs/machine-types), see Google's documentation. - - **Enable Cloud Run for Anthos** - Select this checkbox to use the - [Cloud Run](../../user/project/clusters/add_gke_clusters.md#cloud-run-for-anthos), - Istio, and HTTP Load Balancing add-ons for this cluster. - - **GitLab-managed cluster** - Select this checkbox to - [allow GitLab to manage namespace and service accounts](../../user/project/clusters/gitlab_managed_clusters.md) for this cluster. - -1. Select **Create Kubernetes cluster**. - -After a couple of minutes, the cluster is created. You can also see its -status on your [GCP dashboard](https://console.cloud.google.com/kubernetes). - -## Install Ingress - -After your cluster is running, you must install NGINX Ingress Controller as a -load balancer, to route traffic from the internet to your application. -Install the NGINX Ingress Controller -through the GitLab [Cluster management project template](../../user/clusters/management_project_template.md), -or manually with Google Cloud Shell: - -1. Go to your cluster's details page, and select the **Advanced Settings** tab. -1. Select the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console. -1. On the GKE cluster page, select **Connect**, then select **Run in Cloud Shell**. -1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller: - - ```shell - kubectl create ns gitlab-managed-apps - helm repo add stable https://charts.helm.sh/stable - helm repo update - helm install ingress stable/nginx-ingress -n gitlab-managed-apps - - # Check that the ingress controller is installed successfully - kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps - ``` - -## Configure your base domain - -Follow these steps to configure the base domain where you access your apps. - -1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can - get the external IP address with the following command: - - ```shell - kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip' - ``` - - Replace `gitlab-managed-apps` if you have overwritten your namespace. - - Copy this IP address, as you need it in the next step. - -1. Go back to the cluster page on GitLab, and go to the **Details** tab. - - Add your **Base domain**. For this example, use the domain `<IP address>.nip.io`. - - Select **Save changes**. - -  - -## Enable Auto DevOps (optional) - -While Auto DevOps is enabled by default, Auto DevOps can be disabled at both -the instance level (for self-managed instances) and the group level. Complete -these steps to enable Auto DevOps if it's disabled: - -1. Go to **Settings > CI/CD > Auto DevOps**, and select **Expand**. -1. Select **Default to Auto DevOps pipeline** to display more options. -1. In **Deployment strategy**, select your desired [continuous deployment strategy](requirements.md#auto-devops-deployment-strategy) - to deploy the application to production after the pipeline successfully runs on the default branch. -1. Select **Save changes**. - -  - -After you save your changes, GitLab creates a new pipeline. To view it, go to -**{rocket}** **CI/CD > Pipelines**. - -In the next section, we explain what each job does in the pipeline. - -## Deploy the application - -When your pipeline runs, what is it doing? - -To view the jobs in the pipeline, select the pipeline's status badge. The -**{status_running}** icon displays when pipeline jobs are running, and updates -without refreshing the page to **{status_success}** (for success) or -**{status_failed}** (for failure) when the jobs complete. - -The jobs are separated into stages: - - - -- **Build** - The application builds a Docker image and uploads it to your project's - [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](stages.md#auto-build)). -- **Test** - GitLab runs various checks on the application, but all jobs except `test` - are allowed to fail in the test stage: - - - The `test` job runs unit and integration tests by detecting the language and - framework ([Auto Test](stages.md#auto-test)) - - The `code_quality` job checks the code quality and is allowed to fail - ([Auto Code Quality](stages.md#auto-code-quality)) - - The `container_scanning` job checks the Docker container if it has any - vulnerabilities and is allowed to fail ([Auto Container Scanning](stages.md#auto-container-scanning)) - - The `dependency_scanning` job checks if the application has any dependencies - susceptible to vulnerabilities and is allowed to fail - ([Auto Dependency Scanning](stages.md#auto-dependency-scanning)) - - Jobs suffixed with `-sast` run static analysis on the current code to check for potential - security issues, and are allowed to fail ([Auto SAST](stages.md#auto-sast)) - - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](stages.md#auto-secret-detection)) - - The `license_scanning` job searches the application's dependencies to determine each of their - licenses and is allowed to fail - ([Auto License Compliance](stages.md#auto-license-compliance)) - -- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job. - To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md). - -- **Production** - After the tests and checks finish, the application deploys in - Kubernetes ([Auto Deploy](stages.md#auto-deploy)). - -- **Performance** - Performance tests are run on the deployed application - ([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)). - -- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job. - -After running a pipeline, you should view your deployed website and learn how -to monitor it. - -### Monitor your project - -After successfully deploying your application, you can view its website and check -on its health on the **Environments** page by navigating to -**Deployments > Environments**. This page displays details about -the deployed applications, and the right-hand column displays icons that link -you to common environment tasks: - - - -- **Open live environment** (**{external-link}**) - Opens the URL of the application deployed in production -- **Monitoring** (**{chart}**) - Opens the metrics page where Prometheus collects data - about the Kubernetes cluster and how the application - affects it in terms of memory usage, CPU usage, and latency -- **Deploy to** (**{play}** **{angle-down}**) - Displays a list of environments you can deploy to -- **Terminal** (**{terminal}**) - Opens a [web terminal](../../ci/environments/index.md#web-terminals-deprecated) - session inside the container where the application is running -- **Re-deploy to environment** (**{repeat}**) - For more information, see - [Retrying and rolling back](../../ci/environments/index.md#retry-or-roll-back-a-deployment) -- **Stop environment** (**{stop}**) - For more information, see - [Stopping an environment](../../ci/environments/index.md#stop-an-environment) - -GitLab displays the [deploy board](../../user/project/deploy_boards.md) below the -environment's information, with squares representing pods in your -Kubernetes cluster, color-coded to show their status. Hovering over a square on -the deploy board displays the state of the deployment, and selecting the square -takes you to the pod's logs page. - -NOTE: -The example shows only one pod hosting the application at the moment, but you can add -more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables) -in **Settings > CI/CD > Variables**. - -### Work with branches - -Following the [GitLab flow](../gitlab_flow.md#working-with-feature-branches), -you should next create a feature branch to add content to your application: - -1. In your project's repository, go to the following file: `app/views/welcome/index.html.erb`. - This file should only contain a paragraph: `<p>You're on Rails!</p>`. -1. Open the GitLab [Web IDE](../../user/project/web_ide/index.md) to make the change. -1. Edit the file so it contains: - - ```html - <p>You're on Rails! Powered by GitLab Auto DevOps.</p> - ``` - -1. Stage the file. Add a commit message, then create a new branch and a merge request - by selecting **Commit**. - -  - -After submitting the merge request, GitLab runs your pipeline, and all the jobs -in it, as [described previously](#deploy-the-application), in addition to -a few more that run only on branches other than the default branch. - - - -After a few minutes a test fails, which means a test was -'broken' by your change. Select the failed `test` job to see more information -about it: - -```plaintext -Failure: -WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]: -<You're on Rails!> expected but was -<You're on Rails! Powered by GitLab Auto DevOps.>.. -Expected 0 to be >= 1. - -bin/rails test test/controllers/welcome_controller_test.rb:4 -``` - -To fix the broken test: - -1. Return to your merge request. -1. In the upper right corner, select **Code**, then select **Open in Gitpod**. -1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb` - file, and select it to open it. -1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.` -1. Select **Commit**. -1. In the left-hand column, under **Unstaged changes**, select the checkmark icon - (**{stage-all}**) to stage the changes. -1. Write a commit message, and select **Commit**. - -Return to the **Overview** page of your merge request, and you should not only -see the test passing, but also the application deployed as a -[review application](stages.md#auto-review-apps). You can visit it by selecting -the **View app** **{external-link}** button to see your changes deployed. - - - -After merging the merge request, GitLab runs the pipeline on the default branch, -and then deploys the application to production. - -## Conclusion - -After implementing this project, you should have a solid understanding of the basics of Auto DevOps. -You started from building and testing, to deploying and monitoring an application -all in GitLab. Despite its automatic nature, Auto DevOps can also be configured -and customized to fit your workflow. Here are some helpful resources for further reading: - -1. [Auto DevOps](index.md) -1. [Multiple Kubernetes clusters](multiple_clusters_auto_devops.md) -1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) -1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables) -1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks) -1. [Prometheus monitoring](../../user/project/integrations/prometheus.md) +<!-- This redirect file can be deleted after <2022-09-18>. --> +<!-- Redirects that point to other docs in the same project expire in three months. --> +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
\ No newline at end of file diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md index 039d98efd47..02485ebafff 100644 --- a/doc/topics/autodevops/requirements.md +++ b/doc/topics/autodevops/requirements.md @@ -14,17 +14,16 @@ To prepare the deployment: 1. Define the [deployment strategy](#auto-devops-deployment-strategy). 1. Prepare the [base domain](#auto-devops-base-domain). -1. Define where you want to deploy it to: +1. Define where you want to deploy it: 1. [Kubernetes](#auto-devops-requirements-for-kubernetes). - 1. [Amazon Elastic Container Service (ECS)](#auto-devops-requirements-for-amazon-ecs). - 1. [Amazon EC2](#auto-devops-requirements-for-amazon-ec2). + 1. [Amazon Elastic Container Service (ECS)](cloud_deployments/auto_devops_with_ecs.md). + 1. [Amazon Elastic Kubernetes Service (EKS)](https://about.gitlab.com/blog/2020/05/05/deploying-application-eks/). + 1. [Amazon EC2](cloud_deployments/auto_devops_with_ec2.md). + 1. [Google Kubernetes Engine](cloud_deployments/auto_devops_with_gke.md). 1. [Bare metal](#auto-devops-requirements-for-bare-metal). -When done: - 1. [Enable Auto DevOps](index.md#enable-or-disable-auto-devops). -1. See the [quick start](quick_start_guide.md) process. ## Auto DevOps deployment strategy @@ -173,50 +172,6 @@ are skipped. After all requirements are met, you can [enable Auto DevOps](index.md#enable-or-disable-auto-devops). -## Auto DevOps requirements for Amazon ECS - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0. - -You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes. - -To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable. -To do so, follow these steps: - -1. In GitLab, on the top bar, select **Menu > Projects** and find your project. -1. On the left sidebar, select **Settings > CI/CD**. -1. Expand **Auto DevOps**. -1. Specify which AWS platform to target during the Auto DevOps deployment - by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable with one of the following values: - - `FARGATE` if the service you're targeting must be of launch type FARGATE. - - `ECS` if you're not enforcing any launch type check when deploying to ECS. - -When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly -[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs), -your application is deployed to AWS ECS. - -If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project, -only the deployment to Kubernetes runs. - -WARNING: -Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs -defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml). -However, it's not recommended to [include](../../ci/yaml/index.md#includetemplate) -it on its own. This template is designed to be used with Auto DevOps only. It may change -unexpectedly causing your pipeline to fail if included on its own. Also, the job -names within this template may also change. Do not override these jobs' names in your -own pipeline, as the override stops working when the name changes. - -## Auto DevOps requirements for Amazon EC2 - -[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6. - -You can target [AWS EC2](../../ci/cloud_deployment/index.md) -as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a -specific CI/CD variable. - -For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#custom-build-job-for-auto-devops) -for deployments to AWS EC2. - ## Auto DevOps requirements for bare metal According to the [Kubernetes Ingress-NGINX docs](https://kubernetes.github.io/ingress-nginx/deploy/baremetal/): diff --git a/doc/topics/git/feature_branch_development.md b/doc/topics/git/feature_branch_development.md index ae1485741a5..b205cedbdaa 100644 --- a/doc/topics/git/feature_branch_development.md +++ b/doc/topics/git/feature_branch_development.md @@ -75,7 +75,7 @@ In this case, the feature branch would be `release-X-Y`. Assuming the `release-X  -1. After you click **Create merge request**, an option to **Change branches** displays. Select that option. +1. After you select **Create merge request**, an option to **Change branches** displays. Select that option. 1. In the **New Merge Request** screen, you can now select the **Source** and **Target** branches. In the screenshot shown, @@ -83,7 +83,7 @@ we have selected `test-branch` as the source, and `release-13-0` as the target.  -1. Once you've selected the Source and Target branches, click **Compare branches and continue**. +1. Once you've selected the Source and Target branches, select **Compare branches and continue**. You should see an entry similar to: ```plaintext @@ -94,7 +94,7 @@ we have selected `test-branch` as the source, and `release-13-0` as the target. An entry like this confirms your merge request's destination. -1. Make any additional changes in the **New Merge Request** screen, and click **Submit merge request**. +1. Make any additional changes in the **New Merge Request** screen, and select **Submit merge request**. 1. In the new merge request, look for **Request to merge**. An entry similar to this displays: ```plaintext diff --git a/doc/topics/git/feature_branching.md b/doc/topics/git/feature_branching.md index d3b2510f4e8..4e9b43d66f8 100644 --- a/doc/topics/git/feature_branching.md +++ b/doc/topics/git/feature_branching.md @@ -16,7 +16,7 @@ comments: false ## Feature branching sample workflow -1. Create a new feature branch called 'squash_some_bugs' +1. Create a new feature branch called `squash_some_bugs` 1. Edit '`bugs.rb`' and remove all the bugs. 1. Commit 1. Push diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md index 87fce0b29ff..1e118f98ca5 100644 --- a/doc/topics/git/git_rebase.md +++ b/doc/topics/git/git_rebase.md @@ -180,7 +180,7 @@ the operation you want to perform in each commit. To do so, edit the commits in your terminal's text editor. For example, with [Vim](https://www.vim.org/) as the text editor in -a macOS's `ZSH` shell, you can `squash` or `fixup` (combine) all three commits: +a macOS's Zsh shell, you can `squash` or `fixup` (combine) all three commits: <!-- vale gitlab.FirstPerson = NO --> diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md index 410d2150de5..d40690d86c6 100644 --- a/doc/topics/git/lfs/index.md +++ b/doc/topics/git/lfs/index.md @@ -29,7 +29,7 @@ Documentation for GitLab instance administrators is under [LFS administration do ## Requirements -- Git LFS must be [enabled in project settings](../../../user/project/settings/index.md#sharing-and-permissions). +- Git LFS must be [enabled in project settings](../../../user/project/settings/index.md#configure-project-visibility-features-and-permissions). - [Git LFS client](https://git-lfs.github.com) version 1.0.1 or higher must be installed. ## Known limitations @@ -198,11 +198,7 @@ If the status `error 501` is shown, it is because: remove the line and try to update your Git LFS client. Only version 1.0.1 and newer are supported. -<!-- vale gitlab.Spelling = NO --> - -### getsockopt: connection refused - -<!-- vale gitlab.Spelling = YES --> +### `getsockopt: connection refused` If you push an LFS object to a project and receive an error like this, the LFS client is trying to reach GitLab through HTTPS. However, your GitLab @@ -262,11 +258,7 @@ If you are storing LFS files outside of GitLab you can disable LFS on the projec It is possible to host LFS objects externally by setting a custom LFS URL with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`. -<!-- vale gitlab.Spelling = NO --> - -You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store, +You might choose to do this if you are using an appliance like a Nexus Repository to store LFS data. If you choose to use an external LFS store, GitLab can't verify LFS objects. Pushes then fail if you have GitLab LFS support enabled. -<!-- vale gitlab.Spelling = YES --> - To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md), which also disables GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS). diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md index 32e3b6e2f72..864615e7264 100644 --- a/doc/topics/git/lfs/migrate_to_git_lfs.md +++ b/doc/topics/git/lfs/migrate_to_git_lfs.md @@ -121,7 +121,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs- 1. Navigate to your project's **Settings > Repository** and expand **Protected branches**. - 1. Scroll down to locate the protected branches and click + 1. Scroll down to locate the protected branches and select **Unprotect** the default branch. 1. Force-push to GitLab: @@ -162,7 +162,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs- 1. Select the default branch from the **Branch** dropdown menu, and set up the **Allowed to push** and **Allowed to merge** rules. - 1. Click **Protect**. + 1. Select **Protect**. <!-- ## Troubleshooting diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md index 91ff4d69c2f..eeae0d78638 100644 --- a/doc/topics/git/partial_clone.md +++ b/doc/topics/git/partial_clone.md @@ -160,7 +160,7 @@ For more details, see the Git documentation for ``` WARNING: - Git integrations with `bash`, `zsh`, etc and editors that automatically + Git integrations with `bash`, Zsh, etc and editors that automatically show Git status information often run `git fetch` which fetches the entire repository. Disabling or reconfiguring these integrations might be required. diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index d35eba0d782..034c822671d 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -34,7 +34,7 @@ After getting used to these three steps, the next challenge is the branching mod Because many organizations new to Git have no conventions for how to work with it, their repositories can quickly become messy. The biggest problem is that many long-running branches emerge that all contain part of the changes. People have a hard time figuring out which branch has the latest code, or which branch to deploy to production. -Frequently, the reaction to this problem is to adopt a standardized pattern such as [Git flow](https://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html). +Frequently, the reaction to this problem is to adopt a standardized pattern such as [Git flow](https://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](https://scottchacon.com/2011/08/31/github-flow.html). We think there is still room for improvement. In this document, we describe a set of practices we call GitLab flow. For a video introduction of how this works in GitLab, see [GitLab Flow](https://youtu.be/InKNIvky2KE). diff --git a/doc/topics/offline/index.md b/doc/topics/offline/index.md index a48ac9feb1a..13207c8c612 100644 --- a/doc/topics/offline/index.md +++ b/doc/topics/offline/index.md @@ -1,5 +1,5 @@ --- -stage: Enablement +stage: Systems group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md index 4426f955cb7..901a2dc750c 100644 --- a/doc/topics/offline/quick_start_guide.md +++ b/doc/topics/offline/quick_start_guide.md @@ -1,5 +1,5 @@ --- -stage: Enablement +stage: Systems group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- @@ -202,7 +202,7 @@ done. ### Disable Version Check and Service Ping The Version Check and Service Ping services improve the GitLab user experience and ensure that -users are on the most up-to-date instances of GitLab. These two services can be turned off for air-gapped +users are on the most up-to-date instances of GitLab. These two services can be turned off for offline environments so that they do not attempt and fail to reach out to GitLab services. Learn more about [disabling usage statistics](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics). diff --git a/doc/topics/set_up_organization.md b/doc/topics/set_up_organization.md index 877dbe95e70..c8183a0757e 100644 --- a/doc/topics/set_up_organization.md +++ b/doc/topics/set_up_organization.md @@ -10,7 +10,7 @@ Configure your organization and its users. Determine user roles and give everyone access to the projects they need. - [Members](../user/project/members/index.md) -- [Workspace](../user/workspace/index.md) _(Coming soon)_ +- [Workspace](../user/workspace/index.md) _(In development)_ - [Groups](../user/group/index.md) - [User account options](../user/profile/index.md) - [SSH keys](../user/ssh.md) |
