mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
retitled topics
This commit is contained in:
Mark Bishop
@@ -62,19 +62,13 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
After you configure a pipeline, you can trigger it using different methods:
|
||||
|
||||
<<<<<<< HEAD
|
||||
Pipeline deploys multiple components on demand, i.e. when the first pipeline execution is triggered. It consists of a managed Jenkins engine, docker registry, and minio log storage. Built images are pushed to the internal registry by default but users can choose to push to their remote registry. For every build, it dynamically provisions a Kubernetes pod to run your CI tasks, and remove it when it is finished.
|
||||
|
||||
Webhooks are automatically added to the version control system when a repository is enabled. When users push the code, open a pull request or create a tag, the version control system can send a webhook to Rancher server and trigger a pipeline execution. This requires webhook management permission of the repo, therefore when users auth and fetch their repositories only those on which they have admin permission will be shown.
|
||||
|
||||
>**Note:** There are refactoring changes in Pipeline in v2.1. Therefore users who upgrade from v2.0.x to v2.1 need to reconfigure the pipelines. For documentation of previous version, please refer to [docs for v2.0.x](http://TODO)
|
||||
=======
|
||||
- **Manually:**
|
||||
|
||||
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:** 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 and triggers a pipeline execution.
|
||||
- **Automatically:**
|
||||
|
||||
To use this automation, webhook management permission is required for repo. Therefore, when users authenticate and fetch their repositories, only those on which they have admin permission will be shown.
|
||||
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.
|
||||
|
||||
>>>>>>> 592e04f3... edit on pipelines intro page
|
||||
To use this automation, webhook management permission is required for the repo. Therefore, when users authenticate and fetch their repositories, only those on which they have admin permission will be shown.
|
||||
|
||||
@@ -1,16 +1,22 @@
|
||||
---
|
||||
title: Concepts
|
||||
weight: 500
|
||||
title: Pipeline Terminology
|
||||
weight: 1000
|
||||
---
|
||||
|
||||
## Pipelines
|
||||
When setting up a pipeline, it's helpful to know a few related terms.
|
||||
|
||||
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`.
|
||||
- **Pipeline:**
|
||||
|
||||
## Stages
|
||||
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 stage consists of multiple steps. Stages are executed in the order defined in the pipeline file. The steps in a stage are executed concurrently. A stage starts when all steps in the former stage finish without failure.
|
||||
- **Stages:**
|
||||
|
||||
## Steps
|
||||
A pipeline stage consists of multiple steps. Stages are executed in the order defined in the pipeline file. The steps in a stage are executed concurrently. A stage starts when all steps in the former stage finish without failure.
|
||||
|
||||
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.
|
||||
- **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.
|
||||
|
||||
- **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.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Configurations
|
||||
title: Configuring Pipelines
|
||||
weight: 3725
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Docs for v2.0.x
|
||||
title: v2.0.x Pipeline Documentation
|
||||
weight: 9000
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Quick Start Guide
|
||||
weight: 1000
|
||||
title: Pipelines Quick Start Guide
|
||||
weight: 500
|
||||
---
|
||||
|
||||
## Configure Repositories
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Reference
|
||||
title: Pipeline Variable Reference
|
||||
weight: 8000
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user