diff options
Diffstat (limited to 'doc/topics/autodevops')
| -rw-r--r-- | doc/topics/autodevops/customize.md | 15 | ||||
| -rw-r--r-- | doc/topics/autodevops/index.md | 20 | ||||
| -rw-r--r-- | doc/topics/autodevops/quick_start_guide.md | 8 | ||||
| -rw-r--r-- | doc/topics/autodevops/stages.md | 19 |
4 files changed, 44 insertions, 18 deletions
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 2d6da4d322b..b5952494201 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -5,7 +5,8 @@ almost everything to fit your needs. Auto DevOps offers everything from custom [buildpacks](#custom-buildpacks), to [Dockerfiles](#custom-dockerfile), and [Helm charts](#custom-helm-chart). You can even copy the complete [CI/CD configuration](#customizing-gitlab-ciyml) into your project to enable -staging and canary deployments, and more. +staging and canary deployments, +[manage Auto DevOps with GitLab APIs](customize.md#extend-auto-devops-with-the-api), and more. ## Custom buildpacks @@ -77,6 +78,16 @@ Avoid passing secrets as Docker build arguments if possible, as they may be persisted in your image. See [this discussion of best practices with secrets](https://github.com/moby/moby/issues/13490) for details. +## Extend Auto DevOps with the API + +You can extend and manage your Auto DevOps configuration with GitLab APIs: + +- [Settings that can be accessed with API calls](../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls), + which include `auto_devops_enabled`, to enable Auto DevOps on projects by default. +- [Creating a new project](../../api/projects.md#create-project). +- [Editing groups](../../api/groups.md#update-group). +- [Editing projects](../../api/projects.md#edit-project). + ## Forward CI variables to the build environment > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) in GitLab 12.3, but available in versions 11.9 and above. @@ -381,7 +392,7 @@ these prefixed variables available to the deployed application as environment va To configure your application variables: -1. Go to your project's **{settings}** **Settings > CI/CD**, then expand the +1. Go to your project's **Settings > CI/CD**, then expand the **Variables** section. 1. Create a CI/CD variable, ensuring the key is prefixed with diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 01e61095fe2..e8a344a41d7 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -104,8 +104,10 @@ knowledge of the following: - [GitLab Runner](https://docs.gitlab.com/runner/) - [Prometheus](https://prometheus.io/docs/introduction/overview/) -Auto DevOps provides great defaults for all the stages and makes use of [CI templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates); you can, however, -[customize](customize.md) almost everything to your needs. +Auto DevOps provides great defaults for all the stages and makes use of +[CI templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates). You can, however, +[customize](customize.md) almost everything to your needs, and +[manage Auto DevOps with GitLab APIs](customize.md#extend-auto-devops-with-the-api). For an overview on the creation of Auto DevOps, read more [in this blog post](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/). @@ -130,7 +132,7 @@ any of the following places: [groups](../../user/group/clusters/index.md#base-domain) - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN` -- or as an instance-wide fallback in **{admin}** **Admin Area > Settings** under the +- or as an instance-wide fallback in **Admin Area > Settings** under the **Continuous Integration and Delivery** section The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence @@ -185,7 +187,7 @@ instance level. If enabling, check that your project does not have a `.gitlab-ci.yml`, or if one exists, remove it. -1. Go to your project's **{settings}** **Settings > CI/CD > Auto DevOps**. +1. Go to your project's **Settings > CI/CD > Auto DevOps**. 1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. 1. (Optional, but recommended) When enabling, you can add in the [base domain](#auto-devops-base-domain) Auto DevOps uses to @@ -207,7 +209,7 @@ is specifically enabled or disabled on the subgroup or project. To enable or disable Auto DevOps at the group level: -1. Go to your group's **{settings}** **Settings > CI/CD > Auto DevOps** page. +1. Go to your group's **Settings > CI/CD > Auto DevOps** page. 1. Select the **Default to Auto DevOps pipeline** checkbox to enable it. 1. Click **Save changes** for the changes to take effect. @@ -216,7 +218,7 @@ To enable or disable Auto DevOps at the group level: Even when disabled at the instance level, group owners and project maintainers can still enable Auto DevOps at the group and project level, respectively. -1. Go to **{admin}** **Admin Area > Settings > Continuous Integration and Deployment**. +1. Go to **Admin Area > Settings > Continuous Integration and Deployment**. 1. Select **Default to Auto DevOps pipeline for all projects** to enable it. 1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain), for Auto Deploy and Auto Review Apps to use. @@ -227,7 +229,7 @@ Auto DevOps at the group and project level, respectively. > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0. You can change the deployment strategy used by Auto DevOps by going to your -project's **{settings}** **Settings > CI/CD > Auto DevOps**. The following options +project's **Settings > CI/CD > Auto DevOps**. The following options are available: - **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy) @@ -276,14 +278,14 @@ The following table is an example of how to configure the three different cluste To add a different cluster for each environment: -1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**. +1. Navigate to your project's **Operations > Kubernetes**. 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. Wait for the Ingress IP address to be assigned. 1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the specified Auto DevOps domains. -1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**, +1. Navigate to each cluster's page, through **Operations > Kubernetes**, and add the domain based on its Ingress IP address. After completing configuration, you can test your setup by creating a merge request diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 4f8074f047e..6b9b461e76e 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -57,7 +57,7 @@ to deploy this project to. ## Create a Kubernetes cluster from within GitLab 1. On your project's landing page, click **Add Kubernetes cluster** - (note that this option is also available when you navigate to **{cloud-gear}** **Operations > Kubernetes**). + (note that this option is also available when you navigate to **Operations > Kubernetes**).  @@ -127,7 +127,7 @@ 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. Navigate to **{settings}** **Settings > CI/CD > Auto DevOps**, and click **Expand**. +1. Navigate to **Settings > CI/CD > Auto DevOps**, and click **Expand**. 1. Select **Default to Auto DevOps pipeline** to display more options. 1. In **Deployment strategy**, select your desired [continuous deployment strategy](index.md#deployment-strategy) to deploy the application to production after the pipeline successfully runs on the `master` branch. @@ -194,7 +194,7 @@ to monitor it. After successfully deploying your application, you can view its website and check on its health on the **Environments** page by navigating to -**{cloud-gear}** **Operations > Environments**. This page displays details about +**Operations > Environments**. This page displays details about the deployed applications, and the right-hand column displays icons that link you to common environment tasks: @@ -221,7 +221,7 @@ takes you to the pod's logs page. TIP: **Tip:** The example shows only one pod hosting the application at the moment, but you can add more pods by defining the [`REPLICAS` variable](customize.md#environment-variables) -in **{settings}** **Settings > CI/CD > Environment variables**. +in **Settings > CI/CD > Environment variables**. ### Work with branches diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md index bf1594130f4..7c6cf043820 100644 --- a/doc/topics/autodevops/stages.md +++ b/doc/topics/autodevops/stages.md @@ -90,6 +90,12 @@ Check the [currently supported languages](#currently-supported-languages). Auto Test uses tests you already have in your application. If there are no tests, it's up to you to add them. +NOTE: **Note:** +Not all buildpacks supported by [Auto Build](#auto-build) are supported by Auto Test. +Auto Test uses [Herokuish](https://gitlab.com/gitlab-org/gitlab/-/issues/212689), *not* +Cloud Native Buildpacks, and only buildpacks that implement the +[Testpack API](https://devcenter.heroku.com/articles/testpack-api) are supported. + ### Currently supported languages Note that not all buildpacks support Auto Test yet, as it's a relatively new @@ -454,8 +460,9 @@ For example, in a Rails application in an image built with Unless your repository contains a `Dockerfile`, your image is built with Herokuish, and you must prefix commands run in these images with -`/bin/herokuish procfile exec` to replicate the environment where your application -will run. +`/bin/herokuish procfile exec` (for Herokuish) or `/cnb/lifecycle/launcher` +(for Cloud Native Buildpacks) to replicate the environment where your +application runs. ### Upgrade auto-deploy-app Chart @@ -616,6 +623,12 @@ For example, to start a Rails console from the application root directory, run: /bin/herokuish procfile exec bin/rails c ``` +When using Cloud Native Buildpacks, instead of `/bin/herokuish procfile exec`, use + +```shell +/cnb/lifecycle/launcher $COMMAND +``` + ## Auto Monitoring After your application deploys, Auto Monitoring helps you monitor @@ -644,6 +657,6 @@ To use Auto Monitoring: 1. After the pipeline finishes successfully, open the [monitoring dashboard for a deployed environment](../../ci/environments/index.md#monitoring-environments) to view the metrics of your deployed application. To view the metrics of the - whole Kubernetes cluster, navigate to **{cloud-gear}** **Operations > Metrics**. + whole Kubernetes cluster, navigate to **Operations > Metrics**.  |