From f8ed41bad0ab7098b3cabf5871ad07236712d34d Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Tue, 25 Sep 2018 16:53:19 -0700 Subject: [PATCH] updating pipelines draft --- .../rancher/v2.x/en/tools/pipelines/_index.md | 28 +- .../en/tools/pipelines/concepts/_index.md | 6 +- .../tools/pipelines/configurations/_index.md | 432 ++++++++++-------- .../pipelines/quick-start-guide/_index.md | 16 +- 4 files changed, 278 insertions(+), 204 deletions(-) diff --git a/content/rancher/v2.x/en/tools/pipelines/_index.md b/content/rancher/v2.x/en/tools/pipelines/_index.md index 953c17900d2..6fab55ae92e 100644 --- a/content/rancher/v2.x/en/tools/pipelines/_index.md +++ b/content/rancher/v2.x/en/tools/pipelines/_index.md @@ -5,26 +5,40 @@ aliases: - /rancher/v2.x/en/concepts/ci-cd-pipelines/ - /rancher/v2.x/en/tasks/pipelines/ --- - -You can configure a pipeline to automate building, testing, and publishing for each of your Rancher projects. - >**Notes:** > >- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1. >- Still using v2.0.x? See the pipeline documentation for [previous versions](/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x). +A _pipeline_ is a software delivery process that is broken into different stages, allowing developers to deliver new software as quickly and efficiently as possible. Within Rancher, you can configure a pipeline for each of your Rancher projects. + +The pipeline stages are: + +- **Build:** + + Each time code is checked into your repository, the pipeline automatically clones the repo and builds a new iteration of your software. Throughout this process, the software is typically reviewed by automated tests. + +- **Publish:** + + After each build is completed, it's automatically published to a Docker registry, where it can be pulled for manual testing. + +- **Deploy:** + + A natural extension of the publish stage, the deploy stage lets you release your software to customers with the click of a button. + + ## Overview -Rancher Pipeline provides a simple CI/CD experience-use it to automatically checkout code, run builds, perform tests, publish docker images, and deploy Kubernetes resources to your clusters. +Rancher Pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds, perform tests, publish docker images, and deploy Kubernetes resources to your clusters. -You can configure a pipeline for each project in Rancher. Every project can have individual configurations and setup. +You can configure a pipeline for each project in Rancher. Every project can have individual configurations and setups. Pipelines are represented as pipeline files that are checked into source code repositories. Users can read and edit the pipeline configuration by either: - Using the Rancher UI. - Updating the configuration in the repository, using tools like Git CLI to trigger a build with the latest CI definition. ->**Note:** Rancher Pipeline is not meant to replace enterprise-grade Jenkins or any other CI tool your team uses. +>**Note:** Rancher Pipeline not a replacement for enterprise-grade Jenkins or any other CI tool your team uses. ## Supported Version Control Platforms @@ -71,7 +85,7 @@ After you configure a pipeline, you can trigger it using different methods: After you configure a pipeline, you can trigger a build using the latest CI definition from either Rancher UI or Git CLI. When a pipeline execution is triggered, Rancher dynamically provisions a Kubernetes pod to run your CI tasks and then remove it upon completion. -- **Automatically:** +- **Automatically:** When you enable a repository for a pipeline, webhooks are automatically added to the version control system. When project users interact with the repo—push code, open pull requests, or create a tag—the version control system sends a webhook to Rancher Server, triggering a pipeline execution. diff --git a/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md b/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md index a52e172f3c2..4c2d65e3c23 100644 --- a/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md +++ b/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md @@ -7,7 +7,7 @@ When setting up a pipeline, it's helpful to know a few related terms. - **Pipeline:** - A pipeline consists of stages and steps. It defines the process to build, test and deploy your code. Rancher Pipeline uses the pipeline as source code model and pipeline configuration is represented as a pipeline file in the source code repository, using the file name `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`. + A pipeline consists of stages and steps. It defines the process to build, test, and deploy your code. Rancher pipeline uses the [pipeline as code](https://jenkins.io/doc/book/pipeline-as-code/) model—pipeline configuration is represented as a pipeline file in the source code repository, using the file name `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`. - **Stages:** @@ -15,8 +15,8 @@ When setting up a pipeline, it's helpful to know a few related terms. - **Steps:** - A pipeline step is executed inside a specified container. A step fails when its commands get non-zero exit code, and it will cause the stage and the entire pipeline to fail and terminate. + A pipeline step is executed inside a specified stage. A step fails if it exits with a code other than `0`. If a step exits with this failure code, the entire pipeline fails and terminates. - **Workspace:** - The workspace is the working directory shared by all pipeline steps. In the beginning of a pipeline, source code is checked out to the workspace. The commands of every step bootstraps in the workspace. During a pipeline execution, the artifacts from a previous step will be available in future steps. The working directory is an ephemeral volume and will be cleaned out with the executor pod when a pipeline execution is finished. + The workspace is the working directory shared by all pipeline steps. In the beginning of a pipeline, source code is checked out to the workspace. The command for every step bootstraps in the workspace. During a pipeline execution, the artifacts from a previous step will be available in future steps. The working directory is an ephemeral volume and will be cleaned out with the executor pod when a pipeline execution is finished. diff --git a/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md b/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md index 41850713589..f798590d5a2 100644 --- a/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md +++ b/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md @@ -10,44 +10,241 @@ Configuring a pipeline automates the process of triggering and publishing builds - The [Basic Configuration](#basic-configuration) section provides sequential instruction on how to configure a functional pipeline. - The [Advanced Configuration](#advanced-configuration) section provides instructions for configuring pipeline options. ->**Note:** Before setting up a pipeline for a production environment, we recommend trying the [Pipeline Quick Start Guide]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/quick-start-guide). - -## Pipeline Configuration Outline - -Initial configuration of a pipeline in a production environment involves completion of several mandatory procedures. - - - - -- [1—Configuring Persistent Data for Pipeline Components](#1—configuring-persistent-data-for-pipeline-components) -- [2—Configuring Version Control Providers](#2—configuring-version-control-providers) -- [3—Configuring Pipeline Steps](#3—configuring-pipeline-steps) -- [Advanced Configuration](#advanced-configuration) - - ## Basic Configuration To configure a functional pipeline for your project, begin by completing the mandatory basic configuration steps. -### 1—Configuring Persistent Data for Pipeline Components +### Pipeline Configuration Outline -The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) store use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but it does not help in cases of disaster recovery. We recommend that you to configure these two deployments to persist their data. +Initial configuration of a pipeline in a production environment involves completion of several mandatory procedures. + +>**Note:** Before setting up a pipeline for a production environment, we recommend trying the [Pipeline Quick Start Guide]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/quick-start-guide). + + + + +### 1—Configuring Version Control Providers + +Begin configuration of your pipeline by enabling authentication with your version control provider. Rancher Pipeline supports integration with GitHub and GitLab. + +Select your provider's tab below and follow the directions. + +{{% tabs %}} +{{% tab "GitHub" %}} +1. From the context menu, open the project for which you're configuring a pipeline. + +1. From the main menu, select **Resources > Pipelines**. + +1. Follow the directions displayed to setup an OAuth application in GitHub. + + ![GitHub Pipeline Instructions]({{< baseurl >}}/img/rancher/github-pipeline.png) + +1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher. + +1. If you're using GitHub for enterprise, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation. + +1. Click **Authenticate**. + +1. Enable the repository for which you want to run a pipeline. Then click **Done**. + +{{% /tab %}} +{{% tab "GitLab" %}} +1. From the context menu, open the project for which you're configuring a pipeline. + +1. From the main menu, select **Resources > Pipelines**. + +1. Follow the directions displayed to setup a GitLab application. + + ![GitLab Pipeline Instructions]({{< baseurl >}}/img/rancher/gitlab-pipeline.png) + +1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher. + +1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation. + +1. Click **Authenticate**. + +1. Enable the repository for which you want to run a pipeline. Then click **Done**. + +>**Note:** If you use GitLab and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings. +{{% /tab %}} +{{% /tabs %}} + +**Result:** A pipeline is added to the project. + + + + + + + +### 2—Configuring Pipeline Stages and Steps + +Now that the pipeline is added to your project, you need to configure its automated stages and steps. For your convenience, there are multiple built-in step types for dedicated tasks. + +1. From your project's **Pipeline** tab, find your new pipeline, and select **Ellipsis (...) > Edit Config**. + + >**Note:** When configuring a pipeline, it takes a few moments for Rancher to check for an existing pipeline configuration. + +1. Click **Configure pipeline for this branch**. + +1. Add stages to your pipeline execution by clicking **Add Stage**. + +1. Add steps to each stage by clicking **Add a Step**. You can add multiple steps to each stage. + + >**Note:** As you build out each stage and step, click `Show advanced options` to make [Advanced Configurations](#advanced-configuration), such as rules to trigger or skip pipeline actions, add environment variables, or inject environment variables using secrets. Advanced options are available the pipeline, each stage, and each individual step. + + **Step types available include:** + + {{% accordion id="clone" label="Clone" %}} + +The first stage is preserved to be a cloning step that checks out source code from your repo. Rancher handles the cloning of the git repository. This action is equivalent to `git clone `. + + {{% /accordion %}} + {{% accordion id="run-script" label="Run Script" %}} + +The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience you can use variables to refer to metadata of a pipeline execution. Please go to [reference page](/rancher/v2.x/en/tools/pipelines/reference/#variable-substitution) for the list of available vairables. + +{{% tabs %}} + +{{% tab "By UI" %}} +
+ +1. From the **Step Type** drop-down, choose **Run Script** and fill in the form. + +1. Click **Add**. + +{{% /tab %}} + +{{% tab "By YAML" %}} + +```yaml +# example +stages: +- name: Build something + steps: + - runScriptConfig: + image: golang + shellScript: go build +``` +{{% /tab %}} + +{{% /tabs %}} + +{{% /accordion %}} +{{% accordion id="build-publish-image" label="Build and Publish Images" %}} + +The **Build and Publish Image** step builds and publishes a Docker image. This process requires a Dockerfile in your source code's repository to complete successfully. + +{{% tabs %}} + +{{% tab "By UI" %}} +1. From the **Step Type** drop-down, choose **Build and Publish**. + +1. Fill in the rest of the form. Descriptions for each field are listed below. When you're done, click **Add**. + + Field | Description | + ---------|----------| + Dockerfile Path | The relative path to the Dockerfile in the source code repo. By default, this path is `./Dockerfile`, which assumes the Dockerfile is in the root directory. You can set it to other paths in different use cases (`./path/to/myDockerfile` for example). | + Image Name | The image name in `name:tag` format. The registry address is not required. For example, to build `example.com/repo/my-image:dev`, enter `repo/my-image:dev`. | + Push image to remote repository | An option to set the registry that publishes the image that's built. To use this option, enable it and choose a registry from the drop-down. If this option is disabled, the image is pushed to the internal registry. | + Build Context

(**Show advanced options**)| By default, the root directory of the source code (`.`). For more details, see the Docker [build command documentation](https://docs.docker.com/engine/reference/commandline/build/). + +{{% /tab %}} + +{{% tab "By YAML" %}} +```yaml +# example +stages: +- name: Publish Image + steps: + - publishImageConfig: + dockerfilePath: ./Dockerfile + buildContext: . + tag: repo/app:v1 + pushRemote: true + registry: example.com +``` + +You can use specific arguments for Docker daemon and the build. They are not exposed in the UI, but they are available in pipeline YAML format, as indicated in the example above. Available variables includes: + +Variable Name | Description +------------------------|------------------------------------------------------------ +PLUGIN_DRY_RUN | Disable docker push +PLUGIN_DEBUG | Docker daemon executes in debug mode +PLUGIN_MIRROR | Docker daemon registry mirror +PLUGIN_INSECURE | Docker daemon allows insecure registries +PLUGIN_BUILD_ARGS | Docker build args, a comma separated list + +{{% /tab %}} + +{{% /tabs %}} + +{{% /accordion %}} +{{% accordion id="deploy-yaml" label="Deploy YAML" %}} + +This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). For available variables, refer to [Pipeline Variable Reference]({{< baseurl >}}rancher/v2.x/en/tools/pipelines/reference/). + +{{% tabs %}} + +{{% tab "By UI" %}} + +1. From the **Step Type** drop-down, choose **Deploy YAML** and fill in the form. + +1. Enter the **YAML Path**, which is the path to the manifest file in the source code. + +1. Click **Add**. + +{{% /tab %}} + +{{% tab "By YAML" %}} + +```yaml +# example +stages: +- name: Deploy + steps: + - applyYamlConfig: + path: ./deployment.yaml +``` + +{{% /tab %}} + +{{% /tabs %}} + +{{% /accordion %}} + +1. When you're finished adding stages and steps, click **Done.** + +### 3—Run Pipeline + +Run your pipeline for the first time. From the **Pipeline** tab, find your pipeline and select **Ellipsis (...) > Run**. + +During this initial run, your pipeline is tested, and the following [pipeline components](/Users/markbishop/Documents/GitHub/docs/content/rancher/v2.x/en/tools/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline: + +- `docker-registry` +- `jenkins` +- `minio` + +This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab. + +### 4—Configuring Persistent Data for Pipeline Components + +The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) wokrloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but it does not help in cases of disaster recovery. We recommend that you to configure these two deployments to persist their data. Complete both [A—Configuring Persistent Data for Docker Registry](#a—configuring-persistent-data-for-docker-registry) _and_ [B—Configuring Persistent Data for Minio](#b—configuring-persistent-data-for-minio). >**Prerequisites (for both parts A and B):** > ->- Pipeline components are deployed in the project. ->- [Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) are available in the cluster. +>[Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) must be available for the cluster. #### A—Configuring Persistent Data for Docker Registry -1. From the context menu, open the project for which you're going to create a pipeline. Then select the **Workloads** tab. +1. From the project that you're configuring a pipeline for, select the **Workloads** tab. 1. Find the `docker-registry` workload and select **Ellipsis (...) > Edit**. -1. Expand the **Volumes** section. Make one of the following selections from the **Add Volume** menu: +1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section: - **Add Volume > Add a new persistent volume (claim)** - **Add Volume > Use an existing persistent volume (claim)** @@ -93,7 +290,7 @@ Complete both [A—Configuring Persistent Data for Docker Registry](#a—configu 1. From the **Workloads** tab, find the `minio` workload and select **Ellipsis (...) > Edit**. -1. Expand the **Volumes** section. Make one of the following selections from the **Add Volume** menu: +1. Scroll to the **Volumes** section and expand it. Make one of the following selections from the **Add Volume** menu, which is near the bottom of the section: - **Add Volume > Add a new persistent volume (claim)** - **Add Volume > Use an existing persistent volume (claim)** @@ -134,161 +331,14 @@ Complete both [A—Configuring Persistent Data for Docker Registry](#a—configu 1. Click **Upgrade**. - - -### 2—Configuring Version Control Providers - -Rancher Pipeline supports integration with version control providers GitHub and GitLab. - -{{% tabs %}} -{{% tab "GitHub" %}} -1. From the context menu, open the project for which you're configuring a pipeline. - -1. From the main menu, select **Resources > Pipelines**. - -1. Follow the directions displayed to setup a GitHub application. - - ![GitHub Pipeline Instructions]({{< baseurl >}}/img/rancher/github-pipeline.png) - -1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher. - -1. If you're using GitHub for enterprise setup, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation. - -1. Click **Authenticate**. -{{% /tab %}} -{{% tab "GitLab" %}} -1. From the context menu, open the project for which you're configuring a pipeline. - -1. From the main menu, select **Resources > Pipelines**. - -1. Follow the directions displayed to setup a GitLab application. - - ![GitLab Pipeline Instructions]({{< baseurl >}}/img/rancher/gitlab-pipeline.png) - -1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher. - -1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation. - -1. Click **Authenticate**. - ->**Note:** If you use GitLab and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings. -{{% /tab %}} -{{% /tabs %}} - - - -### 3—Configuring Pipeline Steps - -For convenience, there are multiple built-in step types for dedicated tasks. - -#### Clone Step Type - -The first step is preserved to be a cloning step to check out the source code. - -#### Run Script Step Type - -`Run Script` step is to execute arbitrary commands inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. - -{{% tabs %}} -{{% tab "By UI" %}} -1. Go to EditConfig view. - -2. Click `Add a Step` in a stage. - -3. Choose `Run Script` in `Step Type` option, fill in an image and the commands in the form. You can optionally set environment variables and conditions by expanding advanced options. - -4. Click `Add` -{{% /tab %}} -{{% tab "By YAML" %}} - -```yaml -# example -stages: -- name: Build something - steps: - - runScriptConfig: - image: golang - shellScript: go build -``` -{{% /tab %}} -{{% /tabs %}} - -#### Build and Publish Image Step - -`Publish Image` step is to build and publish a docker image. To do that a Dockerfile is required to be present in the source code repository. - -{{% tabs %}} -{{% tab "By UI" %}} -1. Go to EditConfig view. - -1. Click `Add a Step` in a stage. - -1. Choose `Build and Publish Image` in `Step Type` option. - -1. Fill in the configuration form: - - `Dockerfile Path` is the relative path to the Dockerfile in the source code repo. It is `./Dockerfile` as default and suits the case when you put the Dockerfile in the root directory. You can, for example, set it to `./path/to/myDockerfile` in other cases. - - `Image Name` is the image name in 'name:tag' format. It doesn't need to contain the registry address. For example, to build `example.com/repo/my-image:dev`, input `repo/my-image:dev` here. - - `Push image to remote repository` option is to tell what registry to publish the built image. If it is disabled, the built image will be pushed to the internal registry. Or you can enable it and choose a registry from registry list of the project as the publish target. - - `Build Context` configuration is in advanced options. It is by default `.` representing the root directory of the source code. For more details please refer to [docs for docker build](https://docs.docker.com/engine/reference/commandline/build/) - -1. Click `Add` -{{% /tab %}} -{{% tab "By YAML" %}} -```yaml -# example -stages: -- name: Publish Image - steps: - - publishImageConfig: - dockerfilePath: ./Dockerfile - buildContext: . - tag: repo/app:v1 - pushRemote: true - registry: example.com -``` -You can use specific arguments for docker daemon and the build. They are not exposed in the UI but are available in pipeline yaml format, as indicated in the above example. Available variables includes: - -Variable Name | Description -------------------------|------------------------------------------------------------ -PLUGIN_DRY_RUN | Disable docker push -PLUGIN_DEBUG | Docker daemon executes in debug mode -PLUGIN_MIRROR | Docker daemon registry mirror -PLUGIN_INSECURE | Docker daemon allows insecure registries -PLUGIN_BUILD_ARGS | Docker build args, a comma separated list -{{% /tab %}} -{{% /tabs %}} - -#### Deploy YAML Step Type - -`Deploy YAML` step is to deploy arbitrary Kubernetes resources inside the project. To do that a Kubernetes manifest file is required to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. For available variables please refer to [variable reference](https://TODO). - -{{% tabs %}} -{{% tab "By UI" %}} -1. Go to EditConfig view. - -2. Click `Add a Step` in a stage. - -3. Choose `Deploy YAML` in `Step Type` option, fill in `YAML Path` which is the path to the manifest file in the source code. - -4. Click `Add` -{{% /tab %}} -{{% tab "By YAML" %}} -```yaml -# example -stages: -- name: Deploy - steps: - - applyYamlConfig: - path: ./deployment.yaml -``` -{{% /tab %}} -{{% /tabs %}} - - +**Result:** Persistent storage is configured for your pipeline components. ## Advanced Configuration +During the process of configuring a pipeline, you can configure advanced options for triggering the pipeline or configuring environment variables. + + ### Configuring the Executor Quota The executor quota decides how many builds can run simultaneously in the project. If the number of triggered builds exceeds the quota, subsequent builds will queue until a vacancy opens. By default, the quota is `2`, but you can change it. @@ -399,18 +449,20 @@ branch: {{% /tab %}} {{% /tabs %}} -### Timeout +### Configuring Timeouts -By default, A pipeline execution has 60 minutes timeout. To change that, +By default, A pipeline execution has 60 minutes timeout. +{{% tabs %}} +{{% tab "By UI" %}} 1. Go to EditConfig view. 2. Click Show advanced options. 3. Input timeout value in minutes. - -Or in yaml format: - + +{{% /tab %}} +{{% tab "By YAML" %}} ```yaml # example stages: @@ -420,12 +472,17 @@ stages: image: busybox shellScript: ls timeout: 30 -``` +``` +{{% /tab %}} +{{% /tabs %}} -### Environment Variables + +### Configuring Environment Variables You can set environment variables to individual steps. +{{% tabs %}} +{{% tab "By UI" %}} 1. Go to a step's configuration page. 2. Click `Show advanced options`. @@ -434,10 +491,9 @@ You can set environment variables to individual steps. 4. Fill in the name/value of the variable. -5. Click `Save` - -Or in yaml format: - +5. Click `Save` +{{% /tab %}} +{{% tab "By YAML" %}} ```yaml # example stages: @@ -449,9 +505,13 @@ stages: env: FIRST_KEY: VALUE SECOND_KEY: VALUE2 -``` +``` +{{% /tab %}} +{{% /tabs %}} -### Secrets + + +### Configuring Pipeline Secrets You can use Kubernetes secrets from the project in your pipeline steps. diff --git a/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md b/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md index 7531c221058..ed576139484 100644 --- a/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md +++ b/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md @@ -3,15 +3,15 @@ title: Pipelines Quick Start Guide weight: 500 --- -Rancher ships with several example repositories that help you setup a pipeline quickly and easily. Before you use pipelines with your own repositories in a production environment, we recommend setting up the example repository that most resembles your environment. Use this example repository as a sandbox for repo configuration, build demonstration, etc. Rancher includes example repositories for: +Rancher ships with several example repositories that you can use to familiarize yourself with pipelines. We recommend configuring and testing the example repository that most resembles your environment before using pipelines with your own repositories in a production environment. Use this example repository as a sandbox for repo configuration, build demonstration, etc. Rancher includes example repositories for: - Go - Maven - php -## 1. Configure Repositories +## 1—Configure Repositories -By default, the example pipeline repositories are disabled. Go enable one (or) more to test out the pipeline feature. +By default, the example pipeline repositories are disabled. Go enable one (or more) to test out the pipeline feature. 1. From the context menu, open the project for which you want to run a pipeline. @@ -21,7 +21,7 @@ By default, the example pipeline repositories are disabled. Go enable one (or) m **Step Result:** A list of example repositories displays. - >**Note:** Example repositories only display if you haven't fetched your own repositories. + >**Note:** Example repositories only display if you haven't fetched your own repos. 1. Click **Enable** for one of the example repos (e.g., `https://github.com/rancher/pipeline-example-go.git`). Then click **Done**. @@ -34,7 +34,7 @@ By default, the example pipeline repositories are disabled. Go enable one (or) m - `jenkins` - `minio` -## 2. Run Example Pipelines +## 2—Run Example Pipelines <<<<<<< HEAD 1. Click Run. @@ -46,15 +46,15 @@ By default, the example pipeline repositories are disabled. Go enable one (or) m ======= After configuring an example repository, run the pipeline to see how it works. -1. From the **Pipelines** tab, select **Ellipsis (...) > Run**. Then click **Run** to confirm the pipeline run. +1. From the **Pipelines** tab, select **Ellipsis (...) > Run**. >**Note:** When you run a pipeline the first time, it takes a few minutes to pull relevant images and provision necessary pipeline components. - To understand what the example pipeline is doing, select **Ellipsis (...) > Edit Config** for your repository. Alternatively, view the `.rancher-pipeline.yml` file in the example repositories. + To understand what the example pipeline is doing, select `Ellipsis (...) > Edit Config` for your repo. Alternatively, view the `.rancher-pipeline.yml` file in the example repositories. **Result:** The pipeline runs. ## What's Next? -For detailed information about setting up a pipeline configuration in production, see the [Configuration page]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/quick-start-guide/). +For detailed information about setting up a pipeline configuration in production, see the [Configuring Pipelines]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/configurations/).