Add workflow version

docs/docs/20-usage/10-intro.md

@@ -32,6 +32,8 @@ Read more at: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml/
 Example pipeline configuration:
 
 ```yaml
+version: 1
+
 steps:
   build:
     image: golang
@@ -50,6 +52,8 @@ services:
 Example pipeline configuration with multiple, serial steps:
 
 ```yaml
+version: 1
+
 steps:
   backend:
     image: golang

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

@@ -2,9 +2,14 @@
 
 The pipeline section defines a list of steps to build, test and deploy your code. Pipeline steps are executed serially, in the order in which they are defined. If a step returns a non-zero exit code, the pipeline immediately aborts and returns a failure status.
 
+:::info
+All workflows must set the `version`. Currently, only version 1 is supported, so you'll need to add `version: 1` to every YAML file.
+:::
+
 Example steps:
 
 ```yaml
+version: 1
 steps:
   backend:
     image: golang
@@ -24,6 +29,7 @@ In the above example we define two pipeline steps, `frontend` and `backend`. The
 Another way to name a step is by using the name keyword:
 
 ```yaml
+version: 1
 steps:
   - name: backend
     image: golang
@@ -48,12 +54,17 @@ Woodpecker gives the ability to skip individual commits by adding `[SKIP CI]` or
 git commit -m "updated README [CI SKIP]"
 ```
 
+## Version
+
+Every workflow YAML must define the YAML version it is using. Currently, only version 1 is available, so you need to add `version: 1` to all of your workflows YAMLs.
+
 ## Steps
 
 Every step of your pipeline executes arbitrary commands inside a specified container. The defined commands are executed serially.
 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
+ version: 1
  steps:
    backend:
      image: golang
@@ -69,6 +80,7 @@ The associated commit of a current pipeline run is checked out with git to a wor
 
 ```yaml
 # .woodpecker.yml
+version: 1
 steps:
   build:
     image: debian
@@ -87,6 +99,7 @@ Woodpecker pulls the defined image and uses it as environment to execute the pip
 When using the `local` backend, the `image` entry is used to specify the shell, such as Bash or Fish, that is used to run the commands.
 
 ```diff
+ version: 1
  steps:
    build:
 +    image: golang:1.6
@@ -116,6 +129,7 @@ image: index.docker.io/library/golang:1.7
 Woodpecker does not automatically upgrade container images. Example configuration to always pull the latest image when updates are available:
 
 ```diff
+ version: 1
  steps:
    build:
      image: golang:latest
@@ -131,6 +145,7 @@ These credentials are never exposed to your pipeline, which means they cannot be
 Example configuration using a private image:
 
 ```diff
+ version: 1
  steps:
    build:
 +    image: gcr.io/custom/golang
@@ -168,6 +183,7 @@ 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
+ version: 1
  steps:
    backend:
      image: golang
@@ -211,6 +227,7 @@ For more details check the [secrets docs](./40-secrets.md).
 Some of the pipeline steps may be allowed to fail without causing the whole pipeline to report a failure (e.g., a step executing a linting check). To enable this, add `failure: ignore` to your pipeline step. If Woodpecker encounters an error while executing the step, it will report it as failed but still execute the next steps of the pipeline, if any, without affecting the status of the pipeline.
 
 ```diff
+ version: 1
  steps:
    backend:
      image: golang
@@ -225,6 +242,7 @@ Some of the pipeline steps may be allowed to fail without causing the whole pipe
 Woodpecker supports defining a list of conditions for a pipeline step by using a `when` block. If at least one of the conditions in the `when` block evaluate to true the step is executed, otherwise it is skipped. A condition can be a check like:
 
 ```diff
+ version: 1
  steps:
    slack:
      image: plugins/slack
@@ -242,6 +260,7 @@ Woodpecker supports defining a list of conditions for a pipeline step by using a
 Example conditional execution by repository:
 
 ```diff
+ version: 1
  steps:
    slack:
      image: plugins/slack
@@ -260,6 +279,7 @@ Branch conditions are not applied to tags.
 Example conditional execution by branch:
 
 ```diff
+version: 1
 steps:
   slack:
     image: plugins/slack
@@ -357,6 +377,7 @@ when:
 There are use cases for executing pipeline steps on failure, such as sending notifications for failed pipelines. Use the status constraint to execute steps even when the pipeline fails:
 
 ```diff
+version: 1
 steps:
   slack:
     image: plugins/slack
@@ -490,6 +511,7 @@ Woodpecker supports parallel step execution for same-machine fan-in and fan-out.
 Example parallel configuration:
 
 ```diff
+ version: 1
  steps:
    backend:
 +    group: build
@@ -544,6 +566,7 @@ The workspace defines the shared volume and working directory shared by all pipe
 The workspace can be customized using the workspace block in the YAML file:
 
 ```diff
+ version: 1
 +workspace:
 +  base: /go
 +  path: src/github.com/octocat/hello-world
@@ -559,6 +582,7 @@ The workspace can be customized using the workspace block in the YAML file:
 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
+ version: 1
  workspace:
 +  base: /go
    path: src/github.com/octocat/hello-world
@@ -587,6 +611,7 @@ 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
+ version: 1
  workspace:
    base: /go
 +  path: src/github.com/octocat/hello-world
@@ -615,6 +640,7 @@ By default each pipeline has at least the `repo=your-user/your-repo-name` label.
 You can add additional labels as a key value map:
 
 ```diff
+ version: 1
 +labels:
 +  location: europe # only agents with `location=europe` or `location=*` will be used
 +  weather: sun
@@ -638,6 +664,7 @@ Example:
 Assuming we have two agents, one `linux/arm` and one `linux/amd64`. Previously this pipeline would have executed on **either agent**, as Woodpecker is not fussy about where it runs the pipelines. By setting the following option it will only be executed on an agent with the platform `linux/arm64`.
 
 ```diff
+version: 1
 +labels:
 +  platform: linux/arm64
 
@@ -658,6 +685,7 @@ Woodpecker automatically configures a default clone step if not explicitly defin
 You can manually configure the clone step in your pipeline for customization:
 
 ```diff
+ version: 1
 +clone:
 +  git:
 +    image: woodpeckerci/plugin-git
@@ -673,6 +701,7 @@ You can manually configure the clone step in your pipeline for customization:
 Example configuration to override depth:
 
 ```diff
+ version: 1
  clone:
    git:
      image: woodpeckerci/plugin-git
@@ -684,6 +713,7 @@ Example configuration to override depth:
 Example configuration to use a custom clone plugin:
 
 ```diff
+version: 1
 clone:
   git:
 +   image: octocat/custom-git-plugin
@@ -692,6 +722,7 @@ clone:
 Example configuration to clone Mercurial repository:
 
 ```diff
+ version: 1
  clone:
    hg:
 +    image: plugins/hg
@@ -713,6 +744,7 @@ To use the credentials that cloned the repository to clone it's submodules, upda
 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
+ version: 1
  clone:
    git:
      image: woodpeckerci/plugin-git
@@ -742,6 +774,7 @@ Woodpecker gives the ability to skip whole pipelines (not just steps #when---con
 Example conditional execution by repository:
 
 ```diff
+ version: 1
 +when:
 +  repo: test/test
 +
@@ -761,6 +794,7 @@ Branch conditions are not applied to tags.
 Example conditional execution by branch:
 
 ```diff
+ version: 1
 +when:
 +  branch: main
 +
@@ -898,6 +932,7 @@ 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](./71-project-settings.md#trusted) to enable trusted mode.
 
 ```diff
+ version: 1
  steps:
    build:
      image: docker

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

@@ -36,6 +36,7 @@ If you still need to pass artifacts between the workflows you need use some stor
 .woodpecker/.build.yml
 
 ```yaml
+version: 1
 steps:
   build:
     image: debian:stable-slim
@@ -47,6 +48,7 @@ steps:
 .woodpecker/.deploy.yml
 
 ```yaml
+version: 1
 steps:
   deploy:
     image: debian:stable-slim
@@ -62,6 +64,7 @@ depends_on:
 .woodpecker/.test.yml
 
 ```yaml
+version: 1
 steps:
   test:
     image: debian:stable-slim
@@ -76,6 +79,7 @@ depends_on:
 .woodpecker/.lint.yml
 
 ```yaml
+version: 1
 steps:
   lint:
     image: debian:stable-slim
@@ -97,6 +101,7 @@ Dependencies between workflows can be set with the `depends_on` element. A workf
 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`.
 
 ```diff
+version: 1
 steps:
   deploy:
     image: debian:stable-slim
@@ -112,6 +117,7 @@ steps:
 Workflows that need to run even on failures should set the `runs_on` tag.
 
 ```diff
+version: 1
 steps:
   notify:
     image: debian:stable-slim

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

@@ -33,6 +33,7 @@ matrix:
 Matrix variables are interpolated in the YAML using the `${VARIABLE}` syntax, before the YAML is parsed. This is an example YAML file before interpolating matrix parameters:
 
 ```yaml
+version: 1
 matrix:
   GO_VERSION:
     - 1.4
@@ -58,6 +59,7 @@ services:
 Example YAML file after injecting the matrix parameters:
 
 ```diff
+version: 1
 steps:
   build:
 -   image: golang:${GO_VERSION}
@@ -81,6 +83,7 @@ services:
 ### Example matrix pipeline based on Docker image tag
 
 ```yaml
+version: 1
 matrix:
   TAG:
     - 1.7
@@ -98,6 +101,7 @@ steps:
 ### Example matrix pipeline based on container image
 
 ```yaml
+version: 1
 matrix:
   IMAGE:
     - golang:1.7
@@ -115,6 +119,7 @@ steps:
 ### Example matrix pipeline using multiple platforms
 
 ```yaml
+version: 1
 matrix:
   platform:
     - linux/amd64

docs/docs/20-usage/35-advanced-yaml-syntax.md

@@ -6,6 +6,7 @@ You can use [YAML anchors & aliases](https://yaml.org/spec/1.2.2/#3222-anchors-a
 
 To convert this:
 ```yml
+version: 1
 steps:
   test:
     image: golang:1.18
@@ -18,6 +19,7 @@ steps:
 Just add a new section called **variables** like this:
 
 ```diff
+ version: 1
 +variables:
 +  - &golang_image 'golang:1.18'
 
@@ -35,6 +37,7 @@ Just add a new section called **variables** like this:
 ## Map merges and overwrites
 
 ```yaml
+version: 1
 variables:
   - &base-plugin-settings
     target: dist
@@ -65,6 +68,7 @@ steps:
 ## Sequence merges
 
 ```yaml
+version: 1
 variables:
   pre_cmds: &pre_cmds
    - echo start