Update Documentation (fix diffs and add settings) (#569)

* Add migration guide for plugin settings

* Update screenshot snippets

* Adjust plugin settings

* Fix diff insertion

Co-authored-by: John Olheiser <john.olheiser@gmail.com>

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

@@ -111,18 +111,15 @@ See [when](#step-when---step-conditional-execution) above to understand all the
 Example targeting a specific platform:
 
 ```diff
-pipeline:
-  build:
-    image: golang
-    commands:
-      - go build
-      - go test
-   -when:
-      -platform: [ linux/arm* ]
-
+ pipeline:
+   build:
+     image: golang
+     commands:
+       - go build
+       - go test
+ 
 +when:
 +  platform: [ linux/arm* ]
-
 ```
 
 Assuming we have two agents, one `arm` and one `amd64`. Previously this pipeline would have executed on **either agent**, as Woodpecker is not fussy about where it runs the pipelines.
@@ -134,38 +131,37 @@ This can be utilised in conjunction with other when blocks as well.
 
 Example `when` pipeline & step block:
 
-```yml
-pipeline:
-  build:
-    image: golang
-    commands:
-      - go build
-      - go test
-
-  publish:
-    image: plugins/docker
-    repo: foo/bar
-   +when:
-    +tag: release*
+```diff
+ pipeline:
+   build:
+     image: golang
+     commands:
+       - go build
+       - go test
+ 
+   publish:
+     image: plugins/docker
+     settings:
+       repo: foo/bar
++    when:
++     tag: release*
 
 +when:
 +  platform: [ linux/arm* ]
-
 ```
 
 ### `platform`
 
 To configure your pipeline to select an agent with a specific platform, you can use `platform` key.
 ```diff
-
 +platform: linux/arm64
-
-pipeline:
-  build:
-    image: golang
-    commands:
-      - go build
-      - go test
+ 
+ pipeline:
+   build:
+     image: golang
+     commands:
+       - go build
+       - go test
 ```
 
 ### Skip Commits
@@ -190,12 +186,12 @@ Every step of your pipeline executes arbitrary commands inside a specified docke
 The associated commit of a current pipeline run is checked out with git to a workspace which is mounted to every step of the pipeline as the working directory.
 
 ```diff
-pipeline:
-  backend:
-    image: golang
-    commands:
-+     - go build
-+     - go test
+ pipeline:
+   backend:
+     image: golang
+     commands:
++      - go build
++      - go test
 ```
 
 ### File changes are incremental
@@ -221,20 +217,20 @@ pipeline:
 Woodpecker uses Docker images for the build environment, for plugins and for service containers. The image field is exposed in the container blocks in the Yaml:
 
 ```diff
-pipeline:
-  build:
-+   image: golang:1.6
-    commands:
-      - go build
-      - go test
-
-  publish:
-+   image: plugins/docker
-    repo: foo/bar
-
-services:
-  database:
-+   image: mysql
+ pipeline:
+   build:
++    image: golang:1.6
+     commands:
+       - go build
+       - go test
+ 
+   publish:
++    image: plugins/docker
+     repo: foo/bar
+ 
+ services:
+   database:
++    image: mysql
 ```
 
 Woodpecker supports any valid Docker image from any Docker registry:
@@ -250,10 +246,10 @@ image: index.docker.io/library/golang:1.7
 Woodpecker does not automatically upgrade docker images. Example configuration to always pull the latest image when updates are available:
 
 ```diff
-pipeline:
-  build:
-    image: golang:latest
-+   pull: true
+ pipeline:
+   build:
+     image: golang:latest
++    pull: true
 ```
 
 #### Images from private registries
@@ -265,12 +261,12 @@ These credentials are never exposed to your pipeline, which means they cannot be
 Example configuration using a private image:
 
 ```diff
-pipeline:
-  build:
-+   image: gcr.io/custom/golang
-    commands:
-      - go build
-      - go test
+ pipeline:
+   build:
++    image: gcr.io/custom/golang
+     commands:
+       - go build
+       - go test
 ```
 
 Woodpecker matches the registry hostname to each image in your yaml. If the hostnames match, the registry credentials are used to authenticate to your registry and pull the image. Note that registry credentials are used by the Woodpecker agent and are never exposed to your build containers.
@@ -302,12 +298,12 @@ For specific details on configuring access to Google Container Registry, please
 Commands of every pipeline step are executed serially as if you would enter them into your local shell.
 
 ```diff
-pipeline:
-  backend:
-    image: golang
-    commands:
-+     - go build
-+     - go test
+ pipeline:
+   backend:
+     image: golang
+     commands:
++      - go build
++      - go test
 ```
 
 There is no magic here. The above commands are converted to a simple shell script. The commands in the above example are roughly converted to the below script:
@@ -353,23 +349,23 @@ Woodpecker supports parallel step execution for same-machine fan-in and fan-out.
 Example parallel configuration:
 
 ```diff
-pipeline:
-  backend:
-+   group: build
-    image: golang
-    commands:
-      - go build
-      - go test
-  frontend:
-+   group: build
-    image: node
-    commands:
-      - npm install
-      - npm run test
-      - npm run build
-  publish:
-    image: plugins/docker
-    repo: octocat/hello-world
+ pipeline:
+   backend:
++    group: build
+     image: golang
+     commands:
+       - go build
+       - go test
+   frontend:
++    group: build
+     image: node
+     commands:
+       - npm install
+       - npm run test
+       - npm run build
+   publish:
+     image: plugins/docker
+     repo: octocat/hello-world
 ```
 
 In the above example, the `frontend` and `backend` steps are executed in parallel. The pipeline runner will not execute the `publish` step until the group completes.
@@ -403,31 +399,31 @@ The workspace can be customized using the workspace block in the Yaml file:
 +  base: /go
 +  path: src/github.com/octocat/hello-world
 
-pipeline:
-  build:
-    image: golang:latest
-    commands:
-      - go get
-      - go test
+ pipeline:
+   build:
+     image: golang:latest
+     commands:
+       - go get
+       - go test
 ```
 
 The base attribute defines a shared base volume available to all pipeline steps. This ensures your source code, dependencies and compiled binaries are persisted and shared between steps.
 
 ```diff
-workspace:
-+ base: /go
-  path: src/github.com/octocat/hello-world
-
-pipeline:
-  deps:
-    image: golang:latest
-    commands:
-      - go get
-      - go test
-  build:
-    image: node:latest
-    commands:
-      - go build
+ workspace:
++  base: /go
+   path: src/github.com/octocat/hello-world
+ 
+ pipeline:
+   deps:
+     image: golang:latest
+     commands:
+       - go get
+       - go test
+   build:
+     image: node:latest
+     commands:
+       - go build
 ```
 
 This would be equivalent to the following docker commands:
@@ -442,9 +438,9 @@ docker run --volume=my-named-volume:/go node:latest
 The path attribute defines the working directory of your build. This is where your code is cloned and will be the default working directory of every step in your build process. The path must be relative and is combined with your base path.
 
 ```diff
-workspace:
-  base: /go
-+ path: src/github.com/octocat/hello-world
+ workspace:
+   base: /go
++  path: src/github.com/octocat/hello-world
 ```
 
 ```text
@@ -466,22 +462,23 @@ Woodpecker automatically configures a default clone step if not explicitly defin
 +clone:
 +  git:
 +    image: woodpeckerci/plugin-git
-
-pipeline:
-  build:
-    image: golang
-    commands:
-      - go build
-      - go test
+ 
+ pipeline:
+   build:
+     image: golang
+     commands:
+       - go build
+       - go test
 ```
 
 Example configuration to override depth:
 
 ```diff
-clone:
-  git:
-    image: woodpeckerci/plugin-git
-+   depth: 50
+ clone:
+   git:
+     image: woodpeckerci/plugin-git
++    settings:
++      depth: 50
 ```
 
 Example configuration to use a custom clone plugin:
@@ -495,10 +492,11 @@ clone:
 Example configuration to clone Mercurial repository:
 
 ```diff
-clone:
-  hg:
-+   image: plugins/hg
-+   path: bitbucket.org/foo/bar
+ clone:
+   hg:
++    image: plugins/hg
++    settings:
++      path: bitbucket.org/foo/bar
 ```
 
 #### Git Submodules
@@ -506,21 +504,22 @@ clone:
 To use the credentials that cloned the repository to clone it's submodules, update `.gitmodules` to use `https` instead of `git`:
 
 ```diff
-[submodule "my-module"]
-	path = my-module
--	url = git@github.com:octocat/my-module.git
-+	url = https://github.com/octocat/my-module.git
+ [submodule "my-module"]
+ path = my-module
+-url = git@github.com:octocat/my-module.git
++url = https://github.com/octocat/my-module.git
 ```
 
 To use the ssh git url in `.gitmodules` for users cloning with ssh, and also use the https url in Woodpecker, add `submodule_override`:
 
 ```diff
-clone:
-  git:
-    image: woodpeckerci/plugin-git
-    recursive: true
-+   submodule_override:
-+     my-module: https://github.com/octocat/my-module.git
+ clone:
+   git:
+     image: woodpeckerci/plugin-git
+     settings:
+       recursive: true
++      submodule_override:
++        my-module: https://github.com/octocat/my-module.git
 
 pipeline:
   ...
@@ -533,17 +532,17 @@ Woodpecker gives the ability to configure privileged mode in the Yaml. You can u
 > Privileged mode is only available to trusted repositories and for security reasons should only be used in private environments. See [project settings](/docs/usage/project-settings#trusted) to enable trusted mode.
 
 ```diff
-pipeline:
-  build:
-    image: docker
-    environment:
-      - DOCKER_HOST=tcp://docker:2375
-    commands:
-      - docker --tls=false ps
-
-services:
-  docker:
-    image: docker:dind
-    command: [ "--storage-driver=vfs", "--tls=false" ]
-+   privileged: true
+ pipeline:
+   build:
+     image: docker
+     environment:
+       - DOCKER_HOST=tcp://docker:2375
+     commands:
+       - docker --tls=false ps
+ 
+ services:
+   docker:
+     image: docker:dind
+     command: [ "--storage-driver=vfs", "--tls=false" ]
++    privileged: true
 ```

docs/docs/20-usage/22-conditional-execution.md

@@ -12,7 +12,8 @@ Example conditional execution by branch:
 pipeline:
   slack:
     image: plugins/slack
-    channel: dev
+    settings:
+      channel: dev
 +   when:
 +     branch: master
 ```
@@ -90,7 +91,8 @@ There are use cases for executing pipeline steps on failure, such as sending not
 pipeline:
   slack:
     image: plugins/slack
-    channel: dev
+    settings:
+      channel: dev
 +   when:
 +     status: [ success, failure ]
 ```

docs/docs/20-usage/50-environment.md

@@ -146,7 +146,8 @@ Example commit substitution:
 pipeline:
   docker:
     image: plugins/docker
-+   tags: ${CI_COMMIT_SHA}
+    settings:
++     tags: ${CI_COMMIT_SHA}
 ```
 
 Example tag substitution:
@@ -155,7 +156,8 @@ Example tag substitution:
 pipeline:
   docker:
     image: plugins/docker
-+   tags: ${CI_COMMIT_TAG}
+    settings:
++     tags: ${CI_COMMIT_TAG}
 ```
 
 ## String Operations
@@ -182,7 +184,8 @@ Example variable substitution with substring:
 pipeline:
   docker:
     image: plugins/docker
-+   tags: ${CI_COMMIT_SHA:0:8}
+    settings:
++     tags: ${CI_COMMIT_SHA:0:8}
 ```
 
 Example variable substitution strips `v` prefix from `v.1.0.0`:
@@ -191,5 +194,6 @@ Example variable substitution strips `v` prefix from `v.1.0.0`:
 pipeline:
   docker:
     image: plugins/docker
-+   tags: ${CI_COMMIT_TAG##v}
+    settings:
++     tags: ${CI_COMMIT_TAG##v}
 ```

docs/docs/20-usage/51-plugins/10-plugins.md

@@ -16,12 +16,14 @@ pipeline:
 
   publish:
     image: plugins/docker
-    repo: foo/bar
-    tags: latest
+    settings:
+      repo: foo/bar
+      tags: latest
 
   notify:
     image: plugins/slack
-    channel: dev
+    settings:
+      channel: dev
 ```
 
 ## Plugin Isolation

docs/docs/20-usage/51-plugins/20-sample-plugin.md

@@ -10,10 +10,11 @@ The below example demonstrates how we might configure a webhook plugin in the Ya
 pipeline:
   webhook:
     image: foo/webhook
-    url: http://foo.com
-    method: post
-    body: |
-      hello world
+    settings:
+      url: http://foo.com
+      method: post
+      body: |
+        hello world
 ```
 
 ## Write the logic

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

@@ -1,6 +1,6 @@
 # Project settings
 
-As the owner of a project in Woodpecker you can change some project related settings via the Webinterface.
+As the owner of a project in Woodpecker you can change project related settings via the web interface.
 
 ![project settings](./project-settings.png)
 
@@ -10,7 +10,7 @@ The path to the pipeline config file or folder. By default it is left empty whic
 
 ## Repository hooks
 
-Your Version-Control-System will notify Woodpecker about some events via webhooks. If you want your pipeline to only run on specific webhooks, you can check them by this setting.
+Your Version-Control-System will notify Woodpecker about events via webhooks. If you want your pipeline to only run on specific webhooks, you can check them with this setting.
 
 ## Project settings
 

docs/docs/91-migrations.md

@@ -51,7 +51,17 @@ Some versions need some changes to the server configuration or the pipeline conf
   - `/var/lib/drone/drone.sqlite` -> `/var/lib/woodpecker/woodpecker.sqlite`
   - `drone.sqlite` -> `woodpecker.sqlite`
 
-- ...
+- Plugin Settings moved into `settings` section:
+  ```diff
+   pipline:
+   something:
+     image: my/plugin
+  -  setting1: foo
+  -  setting2: bar
+  +  settings:
+  +    setting1: foo
+  +    setting2: bar
+  ```
 
 ## 0.14.0