diff --git a/content/rancher/v2.x/en/tools/pipelines/_index.md b/content/rancher/v2.x/en/tools/pipelines/_index.md
index 0a3bbd79d40..ee118a242e4 100644
--- a/content/rancher/v2.x/en/tools/pipelines/_index.md
+++ b/content/rancher/v2.x/en/tools/pipelines/_index.md
@@ -6,130 +6,20 @@ aliases:
- /rancher/v2.x/en/tasks/pipelines/
---
-Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline.
+## Overview
-You can set up your pipeline to run a series of stages and steps to test your code and deploy it.
+Rancher Pipeline is designed to provide a simple CI/CD experience, but it is not meant to replace enterprise-grade Jenkins or any other CI tool your team is using. With pipeline you can automatically checkout code, do build, test, publish docker images and deploy Kubernetes resources to your clusters.
-
- - Pipelines
- - Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.
- - Stages
- - Executed sequentially. The next stage will not execute until all of the steps within the stage execute.
- - Steps
- - Are executed in parallel within a stage.
-
+Pipeline is scoped per project. Every project can have individual configurations and setup.
-## Enabling CI Pipelines
+Pipelines are represented as pipeline files that are checked into source code repositories. Users can read and edit the pipeline configuration from Rancher UI, or update the configuration in the repository using tools like git cli to trigger a build with the latest CI definition.
-1. Select cluster from drop down.
+Currently, Integrations with GitHub and GitLab are supported, and more options for version control system is coming; Deploying Kubernetes yaml file is supported, and catalog deployment will be added in future release.
-2. Under tools menu select pipelines.
+## How it works
-3. Follow instructions for setting up github auth on page.
+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.
-## Creating CI Pipelines
-
-1. Go to the project you want this pipeline to run in.
-
-2. Select workloads from the top level Nav bar
-
-3. Select pipelines from from the secondary Nav bar
-
-4. Click Add pipeline button.
-
-5. Enter in your repository name (Autocomplete should help zero in on it quickly).
-
-6. Select Branch options.
-
- - Only the branch {BRANCH NAME}: Only events triggered by changes to this branch will be built.
-
- - Evertyhing but {BRANCH NAME}: Build any branch that triggered an event EXCEPT events from this branch.
-
- - All branches: Regardless of the branch that triggered the event always build.
-
- >**Note:** If you want one path for master, but another for PRs or development/test/feature branches, create two separate pipelines.
-
-7. Select the build trigger events. By default, builds will only happen by manually clicking build now in Rancher UI.
-
- - Automatically build this pipeline whenever there is a git commit. (This respects the branch selection above)
-
- - Automatically build this pipeline whenever there is a new PR.
-
- - Automatically build the pipeline. (Allows you to configure scheduled builds similar to Cron)
-
-8. Click Add button.
-
- By default, Rancher provides a three stage pipeline for you. It consists of a build stage where you would compile, unit test, and scan code. The publish stage has a single step to publish a docker image.
-
-
-8. Add a name to the pipeline in order to complete adding a pipeline.
-
-9. Click on the ‘run a script’ box under the ‘Build’ stage.
-
- Here you can set the image, or select from pre-packaged envs.
-
-10. Configure a shell script to run inside the container when building.
-
-11. Click Save to persist the changes.
-
-12. Click the “publish an image’ box under the “Publish” stage.
-
-13. Set the location of the Dockerfile. By default it looks in the root of the workspace. Instead, set the build context for building the image relative to the root of the workspace.
-
-14. Set the image information.
-
- The registry is the remote registry URL. It is defaulted to Docker hub.
- Repository is the `/` in the repository.
-
-15. Select the Tag. You can hard code a tag like ‘latest’ or select from a list of available variables.
-
-16. If this is the first time using this registry, you can add the username/password for pushing the image. You must click save for the registry credentials AND also save for the modal.
-
-
-
-
-## Creating a New Stage
-
-1. To add a new stage the user must click the ‘add a new stage’ link in either create or edit mode of the pipeline view.
-
-2. Provide a name for the stage.
-
-3. Click save.
-
-
-## Creating a New Step
-
-1. Go to create / edit mode of the pipeline.
-
-2. Click “Add Step” button in the stage that you would like to add a step in.
-
-3. Fill out the form as detailed above
-
-
-## Environment Variables
-
-For your convenience the following environment variables are available in your build steps:
-
-Variable Name | Description
-------------------------|------------------------------------------------------------
-CICD_GIT_REPO_NAME | Repository Name (Stripped of Github Organization)
-CICD_PIPELINE_NAME | Name of the pipeline
-CICD_GIT_BRANCH | Git branch of this event
-CICD_TRIGGER_TYPE | Event that triggered the build
-CICD_PIPELINE_ID | Rancher ID for the pipeline
-CICD_GIT_URL | URL of the Git repository
-CICD_EXECUTION_SEQUENCE | Build number of the pipeline
-CICD_EXECUTION_ID | Combination of {CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}
-CICD_GIT_COMMIT | Git commit ID being executed.
-
-
-## Importing a Pipeline From YAML
-
-If there is a ##YAML FILE### already checked into the github repository click import.
+>**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)
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md b/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md
new file mode 100644
index 00000000000..9efb2cdc24c
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/pipelines/concepts/_index.md
@@ -0,0 +1,16 @@
+---
+title: Concepts
+weight: 500
+---
+
+## Pipelines
+
+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`.
+
+## Stages
+
+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.
+
+## 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.
diff --git a/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md b/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md
new file mode 100644
index 00000000000..b528f29737e
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/pipelines/configurations/_index.md
@@ -0,0 +1,302 @@
+---
+title: Configurations
+weight: 3725
+---
+
+## Version Control Providers
+
+
+Rancher Pipeline supports for integration with version control providers including GitHub and GitLab.
+
+### GitHub
+
+1. Go to the project that you want to run pipelines.
+
+2. Under resources menu select pipeline.
+
+3. Follow the directions displayed to Setup a GitHub Application.
+
+4. From GitHub, copy the Client ID and Client Secret. Paste them into Rancher.
+
+5. For GitHub enterprise setup, enable the `Use a private github enterprise installation` option. Fill in the host address of your GitHub installation.
+
+6. Click Authenticate.
+
+
+### GitLab
+
+1. Go to the project that you want to run pipelines.
+
+2. Under resources menu select pipeline.
+
+3. Follow the directions displayed to Setup a GitLab Application.
+
+4. From GitLab, copy the Client ID and Client Secret. Paste them into Rancher.
+
+5. For private GitLab setup, enable the `Use a private gitlab enterprise installation` option. Fill in the host address of your GitLab installation.
+
+6. Click Authenticate.
+
+>**Note:** If you use GitLab and your rancher setup is in a local network, make sure to enable ‘Allow requests to the local network from hooks and services’ option in GitLab admin settings.
+
+## Executor Quota
+
+Executor quota decides how many builds can be running simultaneously in the project. If the number of triggered builds exceeds the quota, excess builds will be kept in queueing state until there is a vacant slot for it. By default, the quota is 2.
+
+To change that,
+
+1. Go to the project as a project owner.
+
+2. Under resources menu select pipeline.
+
+3. Under `The maximum number of pipeline executors` setting click the button to change the quota. A number less than or equal to zero stands for unlimited quota.
+
+
+## Pipeline Trigger
+
+When a repository is enabled, the webhook is automatically set in version control system. By default, pipeline trigger for "push" event is enabled.
+
+To change that,
+
+1. Go to the pipeline tab of a project.
+
+2. For an enabled repository, click and expand the action button on the right.
+
+3. Click `Settting`
+
+4. On the pop-up window, toggle trigger for "Push", "Push Request" and "Tag" events according to your need.
+
+5. Click `Save`
+
+
+## Pipeline Steps
+
+For convenience, there are multiple built-in step types for dedicated tasks.
+
+### Clone step
+
+The first step is preserved to be a cloning step to check out the source code.
+
+### Run Script step
+
+`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.
+
+To add a `Run Script` step,
+
+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`
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+- name: Build something
+ steps:
+ - runScriptConfig:
+ image: golang
+ shellScript: go build
+```
+
+### 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.
+
+To add a `Publish Image` step,
+
+1. Go to EditConfig view.
+
+2. Click `Add a Step` in a stage.
+
+1. Choose `Build and Publish Image` in `Step Type` option.
+
+2. 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/)
+
+3. Click `Add`
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+- name: Publish Image
+ steps:
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: repo/app:v1
+ pushRemote: true
+ registry: example.com
+```
+
+### Deploy YAML step
+
+`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).
+
+To add a `Deploy YAML` step,
+
+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`
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+- name: Deploy
+ steps:
+ - applyYamlConfig:
+ path: ./deployment.yaml
+```
+
+## Conditions
+
+You can set conditions for a pipeline/stage/step. If all conditions evaluate to true the pipeline/stage/step is executed, otherwise it is skipped. When a stage/step is skipped, it is considered as SUCCESS and follow-up stages/steps continue to run. Wildcard character(`*`) expansion is supported in conditions.
+
+To set branch conditions of a pipeline,
+
+1. Go to EditConfig view.
+
+2. Click Show advanced options for the pipeline configuration.
+
+3. Click Add Rule button in Trigger Rules to set rules for branch conditions.
+
+For a stage/step,
+
+1. Click on a stage or a step.
+
+2. Click Show advanced options.
+
+3. Click Add Rule button in Trigger Rules.
+
+4. Choose Branch or Event in Type drop-down, input Value for branch conditions, or choose Value for event conditions.
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+ - name: Build something
+ # Conditions for stages
+ when:
+ branch: master
+ event: [ push, pull_request ]
+ # Multiple steps run concurrently
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: date -R
+ # Conditions for steps
+ when:
+ branch: [ master, dev ]
+ event: push
+# branch conditions for the pipeline
+branch:
+ include: [ master, feature/*]
+ exlclude: [ dev ]
+```
+
+## Timeout
+
+By default, A pipeline execution has 60 minutes timeout. To change that,
+
+1. Go to EditConfig view.
+
+2. Click Show advanced options.
+
+3. Input timeout value in minutes.
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: ls
+timeout: 30
+```
+
+## Environment Variables
+
+You can set environment variables to individual steps.
+
+1. Go to a step's configuration page.
+
+2. Click `Show advanced options`.
+
+3. Under `Environment Variables` click `Add Variable` button.
+
+4. Fill in the name/value of the variable.
+
+5. Click `Save`
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${FIRST_KEY} && echo ${SECOND_KEY}
+ env:
+ FIRST_KEY: VALUE
+ SECOND_KEY: VALUE2
+```
+
+## Secrets
+
+You can use Kubernetes secrets from the project in your pipeline steps.
+
+>**Note:** Secret injection is disabled on pull request events.
+
+1. Go to the project page.
+
+2. Under Resources menu, click Secrets.
+
+3. Add a secret available to all namespaces in this project.
+
+4. Go to `Edit Config` view of the pipeline, create or edit a Run Script step.
+
+5. Click Show advanced options.
+
+6. Click Add From Secret.
+
+7. Choose the secret created above and choose the key. You can optionally input an alias.
+
+8. Now the secret is injected as environment variables for this step.
+
+Or in yaml format:
+
+```yaml
+# example
+stages:
+ - name: Build something
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${ALIAS_ENV}
+ # environment variables from project secrets
+ envFrom:
+ - sourceName: my-secret
+ sourceKey: secret-key
+ targetKey: ALIAS_ENV
+```
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md b/content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md
new file mode 100644
index 00000000000..ca45f74f67e
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x/_index.md
@@ -0,0 +1,121 @@
+---
+title: Docs for v2.0.x
+weight: 9000
+---
+
+Pipelines help you automate the software delivery process. You can integrate Rancher with GitHub to create a pipeline.
+
+You can set up your pipeline to run a series of stages and steps to test your code and deploy it.
+
+
+ - Pipelines
+ - Contain a series of stages and steps. Out-of-the-box, the pipelines feature supports fan out and in capabilities.
+ - Stages
+ - Executed sequentially. The next stage will not execute until all of the steps within the stage execute.
+ - Steps
+ - Are executed in parallel within a stage.
+
+
+## Enabling CI Pipelines
+
+1. Select cluster from drop down.
+
+2. Under tools menu select pipelines.
+
+3. Follow instructions for setting up github auth on page.
+
+
+## Creating CI Pipelines
+
+1. Go to the project you want this pipeline to run in.
+
+2. Select workloads from the top level Nav bar
+
+3. Select pipelines from the secondary Nav bar
+
+4. Click Add pipeline button.
+
+5. Enter in your repository name (Autocomplete should help zero in on it quickly).
+
+6. Select Branch options.
+
+ - Only the branch {BRANCH NAME}: Only events triggered by changes to this branch will be built.
+
+ - Evertyhing but {BRANCH NAME}: Build any branch that triggered an event EXCEPT events from this branch.
+
+ - All branches: Regardless of the branch that triggered the event always build.
+
+ >**Note:** If you want one path for master, but another for PRs or development/test/feature branches, create two separate pipelines.
+
+7. Select the build trigger events. By default, builds will only happen by manually clicking build now in Rancher UI.
+
+ - Automatically build this pipeline whenever there is a git commit. (This respects the branch selection above)
+
+ - Automatically build this pipeline whenever there is a new PR.
+
+ - Automatically build the pipeline. (Allows you to configure scheduled builds similar to Cron)
+
+8. Click Add button.
+
+ By default, Rancher provides a three stage pipeline for you. It consists of a build stage where you would compile, unit test, and scan code. The publish stage has a single step to publish a docker image.
+
+
+8. Add a name to the pipeline in order to complete adding a pipeline.
+
+9. Click on the ‘run a script’ box under the ‘Build’ stage.
+
+ Here you can set the image, or select from pre-packaged envs.
+
+10. Configure a shell script to run inside the container when building.
+
+11. Click Save to persist the changes.
+
+12. Click the “publish an image’ box under the “Publish” stage.
+
+13. Set the location of the Dockerfile. By default it looks in the root of the workspace. Instead, set the build context for building the image relative to the root of the workspace.
+
+14. Set the image information.
+
+ The registry is the remote registry URL. It is defaulted to Docker hub.
+ Repository is the `/` in the repository.
+
+15. Select the Tag. You can hard code a tag like ‘latest’ or select from a list of available variables.
+
+16. If this is the first time using this registry, you can add the username/password for pushing the image. You must click save for the registry credentials AND also save for the modal.
+
+
+
+
+## Creating a New Stage
+
+1. To add a new stage the user must click the ‘add a new stage’ link in either create or edit mode of the pipeline view.
+
+2. Provide a name for the stage.
+
+3. Click save.
+
+
+## Creating a New Step
+
+1. Go to create / edit mode of the pipeline.
+
+2. Click “Add Step” button in the stage that you would like to add a step in.
+
+3. Fill out the form as detailed above
+
+
+## Environment Variables
+
+For your convenience the following environment variables are available in your build steps:
+
+Variable Name | Description
+------------------------|------------------------------------------------------------
+CICD_GIT_REPO_NAME | Repository Name (Stripped of Github Organization)
+CICD_PIPELINE_NAME | Name of the pipeline
+CICD_GIT_BRANCH | Git branch of this event
+CICD_TRIGGER_TYPE | Event that triggered the build
+CICD_PIPELINE_ID | Rancher ID for the pipeline
+CICD_GIT_URL | URL of the Git repository
+CICD_EXECUTION_SEQUENCE | Build number of the pipeline
+CICD_EXECUTION_ID | Combination of {CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}
+CICD_GIT_COMMIT | Git commit ID being executed.
\ No newline at end of file
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
new file mode 100644
index 00000000000..d0608667914
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/pipelines/quick-start-guide/_index.md
@@ -0,0 +1,29 @@
+---
+title: Quick Start Guide
+weight: 1000
+---
+
+## Configure Repositories
+
+1. Go to the project you want to run a pipeline.
+
+2. Select workloads from the top level Nav bar.
+
+3. Select pipelines from the secondary Nav bar.
+
+4. Click Configure Repositories button. If you haven't done authorization with your git account, you will see a list of example repositories. Otherwise, you will see a list of your repositories.
+
+5. Click the `Enable` button of an example repo, e.g., `https://github.com/rancher/pipeline-example-go.git`.
+
+6. Click Done, you can see the repo under pipelines Nav bar.
+
+## Run Example Pipelines
+
+1. Assuming you've enabled an example repository, go to pipelines Nav bar of the project.
+
+2. Expand the action button of the enabled repository.
+
+3. Click Run.
+
+ >**Note:** When you are running a pipeline the first time, it will take a few minutes to pull relevant images and provision necessary pipeline components.
+ To understand what the example pipeline is doing, you can check the `.rancher-pipeline.yml` file in the example repositories, or click `Edit Config` action of the enabled repository to see it via UI wizard.
diff --git a/content/rancher/v2.x/en/tools/pipelines/reference/_index.md b/content/rancher/v2.x/en/tools/pipelines/reference/_index.md
new file mode 100644
index 00000000000..6f5e59e7a37
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/pipelines/reference/_index.md
@@ -0,0 +1,74 @@
+---
+title: Reference
+weight: 8000
+---
+
+## Variable Substitution
+
+For your convenience, the following variables are available in your pipeline configurations, and they will be substituted by metadata of a pipeline execution. You can reference them in the form of `${VAR_NAME}`:
+
+Variable Name | Description
+------------------------|------------------------------------------------------------
+CICD_GIT_REPO_NAME | Repository Name (Stripped of Github Organization)
+CICD_GIT_URL | URL of the Git repository
+CICD_GIT_COMMIT | Git commit ID being executed.
+CICD_GIT_BRANCH | Git branch of this event
+CICD_GIT_REF | Git reference specification of this event
+CICD_GIT_TAG | Git tag name, set on tag event
+CICD_EVENT | Event that triggered the build, can be "push", "pull_request" or "tag"
+CICD_PIPELINE_ID | Rancher ID for the pipeline
+CICD_EXECUTION_SEQUENCE | Build number of the pipeline
+CICD_EXECUTION_ID | Combination of {CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}
+CICD_REGISTRY | Address for the docker registry of previous publish image step, available in the kubernetes manifest file of a `Deploy YAML` step.
+CICD_IMAGE | Name of the built image of previous publish image step, available in the kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.
+
+## Full `.rancher-pipeline.yml` Example
+
+```yaml
+# example
+stages:
+ - name: Build something
+ # Conditions for stages
+ when:
+ branch: master
+ event: [ push, pull_request ]
+ # Multiple steps run concurrently
+ steps:
+ - runScriptConfig:
+ image: busybox
+ shellScript: echo ${FIRST_KEY} && echo ${ALIAS_ENV}
+ # Set environment variables in container for the step
+ env:
+ FIRST_KEY: VALUE
+ SECOND_KEY: VALUE2
+ # Set environment variables from project secrets
+ envFrom:
+ - sourceName: my-secret
+ sourceKey: secret-key
+ targetKey: ALIAS_ENV
+ - runScriptConfig:
+ image: busybox
+ shellScript: date -R
+ # Conditions for steps
+ when:
+ branch: [ master, dev ]
+ event: push
+ - name: Publish my image
+ steps:
+ - publishImageConfig:
+ dockerfilePath: ./Dockerfile
+ buildContext: .
+ tag: rancher/rancher:v2.0.0
+ # Optionally push to remote registry
+ pushRemote: true
+ registry: reg.example.com
+ - name: Deploy some workloads
+ steps:
+ - applyYamlConfig:
+ path: ./deployment.yaml
+# branch conditions for the pipeline
+branch:
+ include: [ master, feature/*]
+ exlclude: [ dev ]
+
+```