Rename multi pipelines to workflows (#1285)

Co-authored-by: 6543 <6543@obermui.de>

docs/docs/20-usage/20-pipeline-syntax.md

@@ -873,7 +873,7 @@ when:
 
 ## `depends_on`
 
-Woodpecker supports to define multiple pipelines for a repository. Those pipelines will run independent from each other. To depend them on each other you can use the [`depends_on`](https://woodpecker-ci.org/docs/usage/multi-pipeline#flow-control) keyword.
+Woodpecker supports to define multiple workflows for a repository. Those workflows will run independent from each other. To depend them on each other you can use the [`depends_on`](https://woodpecker-ci.org/docs/usage/workflows#flow-control) keyword.
 
 ## Privileged mode
 

docs/docs/20-usage/25-workflows.md

@@ -1,24 +1,28 @@
-# Multi pipelines
+# Workflows
 
 :::info
 This Feature is only available for GitHub, Gitea & GitLab repositories. Follow [this](https://github.com/woodpecker-ci/woodpecker/issues/131) issue to support further development.
 :::
 
-By default, Woodpecker looks for the pipeline definition in `.woodpecker.yml` in the project root.
+A pipeline has at least one workflow. A workflow is a set of steps that are executed in sequence using the same workspace which is a shared folder containing the repository and all the generated data from previous steps.
 
-The Multi-Pipeline feature allows the pipeline to be split into several files and placed in the `.woodpecker/` folder. Only `.yml` and `.yaml` files will be used and files in any subfolders like `.woodpecker/sub-folder/test.yml` will be ignored. You can set some custom path like `.my-ci/pipelines/` instead of `.woodpecker/` in the [project settings](./71-project-settings.md).
+Incase there is a single configuration in `.woodpecker.yml` Woodpecker will create a pipeline with a single workflow.
 
-## Rational
+By placing the configurations in a folder which is by default named `.woodpecker/` Woodpecker will create a pipeline with multiple workflows each named by the file they are defined in. Only `.yml` and `.yaml` files will be used and files in any subfolders like `.woodpecker/sub-folder/test.yml` will be ignored.
 
-- faster lint/test feedback, the pipeline doesn't have to run fully to have a lint status pushed to the forge
-- better organization of the pipeline along various concerns: testing, linting, feature apps
-- utilizing more agents to speed up build
+You can also set some custom path like `.my-ci/pipelines/` instead of `.woodpecker/` in the [project settings](./71-project-settings.md).
 
-## Example multi-pipeline definition
+## Benefits of using workflows
+
+- faster lint/test feedback, the workflow doesn't have to run fully to have a lint status pushed to the remote
+- better organization of a pipeline along various concerns using one workflow for: testing, linting, building and deploying
+- utilizing more agents to speed up the execution of the whole pipeline
+
+## Example workflow definition
 
 :::warning
-Please note that files are only shared between steps of the same pipeline (see [File changes are incremental](./20-pipeline-syntax.md#file-changes-are-incremental)). That means you cannot access artifacts e.g. from the `build` pipeline below in the `deploy` pipeline.
-If you still need to pass artifacts between the pipelines you need use storage [plugins](./51-plugins/10-plugins.md) (e.g. one which stores files in an Amazon S3 bucket).
+Please note that files are only shared between steps of the same workflow (see [File changes are incremental](./20-pipeline-syntax.md#file-changes-are-incremental)). That means you cannot access artifacts e.g. from the `build` workflow in the `deploy` workflow.
+If you still need to pass artifacts between the workflows you need use some storage [plugin](./51-plugins/10-plugins.md) (e.g. one which stores files in an Amazon S3 bucket).
 :::
 
 ```bash
@@ -82,13 +86,13 @@ pipeline:
 
 ## Status lines
 
-Each pipeline will report its own status back to your forge.
+Each workflow will report its own status back to your forge.
 
 ## Flow control
 
-The pipelines run in parallel on separate agents and share nothing.
+The workflows run in parallel on separate agents and share nothing.
 
-Dependencies between pipelines can be set with the `depends_on` element. A pipeline doesn't execute until all of its dependencies finished successfully.
+Dependencies between workflows can be set with the `depends_on` element. A workflow doesn't execute until all of its dependencies finished successfully.
 
 The name for a `depends_on` entry is the filename without the path, leading dots and without the file extension `.yml` or `.yaml`. If the project config for example uses `.woodpecker/` as path for CI files with a file named `.woodpecker/.lint.yml` the corresponding `depends_on` entry would be `lint`.
 
@@ -105,7 +109,7 @@ pipeline:
 +  - test
 ```
 
-Pipelines that need to run even on failures should set the `runs_on` tag.
+Workflows that need to run even on failures should set the `runs_on` tag.
 
 ```diff
 pipeline:
@@ -120,7 +124,7 @@ depends_on:
 +runs_on: [ success, failure ]
 ```
 
-Some pipelines don't need the source code, set the `skip_clone` tag to skip cloning:
+Some workflows don't need the source code, set the `skip_clone` tag to skip cloning:
 
 ```diff
 

docs/docs/20-usage/30-matrix-pipelines.md

@@ -1,6 +1,6 @@
 # Matrix pipelines
 
-Woodpecker has integrated support for matrix pipeline. Woodpecker executes a separate pipeline for each combination in the matrix, allowing you to build and test a single commit against multiple configurations.
+Woodpecker has integrated support for matrix workflows. Woodpecker executes a separate workflow for each combination in the matrix, allowing you to build and test a single commit against multiple configurations.
 
 Example matrix definition:
 

docs/docs/20-usage/71-project-settings.md

@@ -6,7 +6,7 @@ As the owner of a project in Woodpecker you can change project related settings
 
 ## Pipeline path
 
-The path to the pipeline config file or folder. By default it is left empty which will use the following configuration resolution `.woodpecker/*.yml` and `.woodpecker/*.yaml` (without any preference in handling them) -> `.woodpecker.yml` -> `.woodpecker.yaml` -> `.drone.yml`. If you set a custom path Woodpecker tries to load your configuration or fails if no configuration could be found at the specified location. To use a [multi pipeline](./25-multi-pipeline.md) you have to change it to a folder path ending with a `/` like `.woodpecker/`.
+The path to the pipeline config file or folder. By default it is left empty which will use the following configuration resolution `.woodpecker/*.yml` -> `.woodpecker/*.yaml` -> `.woodpecker.yml` -> `.woodpecker.yaml` -> `.drone.yml`. If you set a custom path Woodpecker tries to load your configuration or fails if no configuration could be found at the specified location. To use a [multiple workflows](./25-workflows.md) with a custom path you have to change it to a folder path ending with a `/` like `.woodpecker/`.
 
 ## Repository hooks
 

docs/docs/30-administration/11-forges/10-overview.md

@@ -9,7 +9,7 @@
 | Event: Pull-Request | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :white_check_mark: | :white_check_mark: |
 | Event: Deploy | :white_check_mark: | :x: | :x: | :x: | :x: | :x: | :x: |
 | OAuth | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :white_check_mark: |
-| [Multi pipeline](../../20-usage/25-multi-pipeline.md) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: | :x: | :x: |
+| [Multiple workflows](../../20-usage/25-workflows.md) | :white_check_mark: | :white_check_mark: | :white_check_mark: | :x: | :x: | :x: | :x: |
 | [when.path filter](../../20-usage/20-pipeline-syntax.md#path) | :white_check_mark: | :white_check_mark:¹ | :white_check_mark: | :x: | :x: | :x: | :x: |
 
 ¹) for Gitea versions 1.17 or lower not for pull requests

docs/src/pages/faq.md

@@ -3,8 +3,9 @@
 ## What are the differences to Drone?
 
 Apart from Woodpecker staying free and OpenSource forever, the growing community already introduced some nifty features like:
-- [Multi pipelines](/docs/usage/multi-pipeline)
-- [Conditional step execution on file changes](/docs/usage/conditional-execution#path)
+
+- [Multiple workflows](/docs/next/usage/workflows)
+- [Conditional step execution on file changes](/docs/usage/pipeline-syntax#path)
 - [More features are already in the pipeline :wink:](https://github.com/woodpecker-ci/woodpecker/pulls) ...
 
 ## Why is Woodpecker a fork of Drone version 0.8?