Add 3.7 docs (#5248)

docs/versioned_docs/version-3.4/20-usage/40-secrets.md

@@ -1,156 +0,0 @@
-# Secrets
-
-Woodpecker provides the ability to store named variables in a central secret store.
-These secrets can be passed securely to individual pipeline steps using the `from_secret` keyword.
-
-Three different levels of secrets are available.
-The following list shows the priority of these.
-If a secret is defined in multiple levels, the following precedence applies: Repository secrets > Organization secrets > Global secrets.
-
-1. **Repository secrets**: Available to all pipelines of a repository.
-1. **Organization secrets**: Available to all pipelines of an organization.
-1. **Global secrets**: Can only be set by instance admins.
-   Global secret are available to all pipelines of the **entire** Woodpecker instance and should therefore be used with caution.
-
-:::tip
-In addition to the native secret integration, external secret providers can be utilized by interacting with them directly within pipeline steps.
-Access to these providers can be configured using Woodpecker secrets, enabling the retrieval of secrets from the respective external sources.
-:::
-
-:::warning
-Woodpecker can mask secrets from its native secret store, but it cannot apply the same protection to external secrets. As a result, these external secrets may be exposed in the pipeline logs.
-:::
-
-## Usage
-
-You can set a setting or environment value from Woodpecker secrets using the `from_secret` syntax.
-
-The example below passes a secret called `secret_token` which will be stored in an environment variable named `TOKEN_ENV`:
-
-```diff
- steps:
-   - name: 'step name'
-     image: registry/repo/image:tag
-     commands:
-+      - echo "The secret is $TOKEN_ENV"
-+    environment:
-+      TOKEN_ENV:
-+        from_secret: secret_token
-```
-
-The same syntax can be used to pass secrets to (plugin) settings.
-A secret named `secret_token` is assigned to the setting `TOKEN`, which will then be available in the plugin as environment variable `PLUGIN_TOKEN` (see [plugins](./51-plugins/20-creating-plugins.md#settings) for details).
-`PLUGIN_TOKEN` is then internally consumed by the plugin itself and will be honored during execution.
-
-```diff
- steps:
-   - name: 'step name'
-     image: registry/repo/image:tag
-+    settings:
-+      TOKEN:
-+        from_secret: secret_token
-```
-
-### Note about parameter pre-processing
-
-Please note that parameter expressions undergo pre-processing, meaning they are evaluated before the pipeline starts.
-If secrets are to be used in expressions, they must be properly escaped (using `$$`) to ensure correct handling.
-
-```diff
- steps:
-   - name: docker
-     image: docker
-     commands:
--      - echo ${TOKEN_ENV}
-+      - echo $${TOKEN_ENV}
-     environment:
-       TOKEN_ENV:
-         from_secret: secret_token
-```
-
-### Use in Pull Requests events
-
-By default, secrets are not exposed to pull requests.
-However, you can change this behavior by creating the secret and enabling the `pull_request` event type.
-This can be configured either through the UI or via the CLI, as demonstrated below.
-
-:::warning
-Be cautious when exposing secrets to pull requests.
-If your repository is public and initiates pull request runs without requiring approval, your secrets may be at risk.
-Malicious actors could potentially exploit this to expose or transmit your secrets to an external location.
-:::
-
-## Plugins filter
-
-To prevent abusing your secrets from malicious usage, you can limit a secret to a list of plugins.
-If enabled they are not available to any other plugin (steps without user-defined commands).
-Plugins have the advantage that they cannot run arbitrary commands, hence they cannot be used to expose secrets (in contrast to arbitrary steps).
-
-:::note
-If you specify a tag, the filter will honor it.
-However, if the same image appears multiple times in the list, the least privileged entry takes precedence.
-For example, an image without a tag will permit all tags, even if another entry with a pinned tag is included.
-:::
-
-![plugins filter](./secrets-plugins-filter.png)
-
-## Adding Secrets
-
-Secrets can be added through the UI or via the CLI.
-
-### CLI Examples
-
-Create the secret using default settings.
-The secret will be available to all images in your pipeline, and will be available to all `push`, `tag`, and `deployment` events (not `pull_request` events).
-
-```bash
-woodpecker-cli repo secret add \
-  --repository octocat/hello-world \
-  --name aws_access_key_id \
-  --value <value>
-```
-
-Create the secret and limit it to a single image:
-
-```diff
- woodpecker-cli secret add \
-   --repository octocat/hello-world \
-+  --image woodpeckerci/plugin-s3 \
-   --name aws_access_key_id \
-   --value <value>
-```
-
-Create the secrets and limit it to a set of images:
-
-```diff
- woodpecker-cli repo secret add \
-   --repository octocat/hello-world \
-+  --image woodpeckerci/plugin-s3 \
-+  --image woodpeckerci/plugin-docker-buildx \
-   --name aws_access_key_id \
-   --value <value>
-```
-
-Create the secret and enable it for multiple hook events:
-
-```diff
- woodpecker-cli repo secret add \
-   --repository octocat/hello-world \
-   --image woodpeckerci/plugin-s3 \
-+  --event pull_request \
-+  --event push \
-+  --event tag \
-   --name aws_access_key_id \
-   --value <value>
-```
-
-Secrets can be loaded from a file using the `@` syntax.
-This method is recommended for loading secrets from a file, as it ensures that newlines are preserved (this is for example important for SSH keys).
-Here’s an example:
-
-```diff
- woodpecker-cli repo secret add \
-   -repository octocat/hello-world \
-   -name ssh_key \
-+  -value @/root/ssh/id_rsa
-```

docs/versioned_docs/version-3.7/20-usage/15-terminology/index.md

@@ -24,6 +24,7 @@
 - **Dependency**: [Workflows][Workflow] can depend on each other, and if possible, they are executed in parallel.
 - **Status**: Status refers to the outcome of a step or [workflow][Workflow] after it has been executed, determined by the internal command exit code. At the end of a [workflow][Workflow], its status is sent to the [forge][Forge].
 - **Service extension**: Some parts of Woodpecker internal services like secrets storage or config fetcher can be replaced through service extensions.
+- **Task**: A task is a [workflow][Workflow] that's currently waiting for its execution in the task queue.
 
 ## Woodpecker architecture
 

docs/versioned_docs/version-3.7/20-usage/20-workflow-syntax.md

@@ -122,7 +122,13 @@ image: index.docker.io/library/golang
 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:
+Learn more how you can use images from [different registries](./41-registries.md).
+
+### `pull`
+
+By default, Woodpecker does not automatically upgrade container images and only pulls them when they are not already present.
+
+To always pull the latest image when updates are available, use the `pull` option:
 
 ```diff
  steps:
@@ -131,8 +137,6 @@ Woodpecker does not automatically upgrade container images. Example configuratio
 +    pull: true
 ```
 
-Learn more how you can use images from [different registries](./41-registries.md).
-
 ### `commands`
 
 Commands of every step are executed serially as if you would enter them into your local shell.
@@ -510,6 +514,15 @@ For more details check the [service docs](./60-services.md#detachment).
 
 Using `directory`, you can set a subdirectory of your repository or an absolute path inside the Docker container in which your commands will run.
 
+### `backend_options`
+
+With `backend_options` you can define options that are specific to the respective backend that is used to execute the steps. For example, you can specify the user and/or group used in a Docker container or you can specify the service account for Kubernetes.
+
+Further details can be found in the documentation of the used backend:
+
+- [Docker](../30-administration/10-configuration/11-backends/10-docker.md#step-specific-configuration)
+- [Kubernetes](../30-administration/10-configuration/11-backends/20-kubernetes.md#step-specific-configuration)
+
 ## `services`
 
 Woodpecker can provide service containers. They can for example be used to run databases or cache containers during the execution of workflow.
@@ -594,12 +607,16 @@ For more details check the [matrix build docs](./30-matrix-workflows.md).
 
 ## `labels`
 
-You can set labels for your workflow to select an agent to execute the workflow on. An agent will pick up and run a workflow when **every** label assigned to it matches the agents labels.
+You can define labels for your workflow in order to select an agent to execute the workflow. An agent takes up a workflow and executes it if **every** label assigned to it matches the label of the agent.
 
-To set additional agent labels, check the [agent configuration options](../30-administration/10-configuration/30-agent.md#agent_labels). Agents will have at least four default labels: `platform=agent-os/agent-arch`, `hostname=my-agent`, `backend=docker` (type of the agent backend) and `repo=*`. Agents can use a `*` as a wildcard for a label. For example `repo=*` will match every repo.
+To specify additional agent labels, check the [Agent configuration options](../30-administration/10-configuration/30-agent.md#agent_labels). The agents have at least four default labels: `platform=agent-os/agent-arch`, `hostname=my-agent`, `backend=docker` (type of agent backend) and `repo=*`. Agents can use an `*` as a placeholder for a label. For example, `repo=*` matches any repo.
 
-Workflow labels with an empty value will be ignored.
-By default, each workflow has at least the `repo=your-user/your-repo-name` label. If you have set the [platform attribute](#platform) for your workflow it will have a label like `platform=your-os/your-arch` as well.
+Workflow labels with an empty value are ignored.
+By default, each workflow has at least the label `repo=your-user/your-repo-name`. If you have set the [platform attribute](#platform) for your workflow, it will also have a label such as `platform=your-os/your-arch`.
+
+:::warning
+Labels with the `woodpecker-ci.org` prefix are managed by Woodpecker and can not be set as part of the pipeline definition.
+:::
 
 You can add additional labels as a key value map:
 
@@ -642,9 +659,9 @@ For more details and examples check the [Advanced usage docs](./90-advanced-usag
 
 ## `clone`
 
-Woodpecker automatically configures a default clone step if not explicitly defined. When using the `local` backend, the [plugin-git](https://github.com/woodpecker-ci/plugin-git) binary must be on your `$PATH` for the default clone step to work. If not, you can still write a manual clone step.
+Woodpecker automatically configures a default clone step if it is not explicitly defined. If you are using the `local` backend, the [plugin-git](https://github.com/woodpecker-ci/plugin-git) binary must be in your `$PATH` for the default clone step to work. If this is not the case, you can still write a manual clone step.
 
-You can manually configure the clone step in your workflow for customization:
+You can manually configure the clone step in your workflow to customize it:
 
 ```diff
 +clone:
@@ -659,7 +676,7 @@ You can manually configure the clone step in your workflow for customization:
        - go test
 ```
 
-Example configuration to override depth:
+Example configuration to override the depth:
 
 ```diff
  clone:
@@ -680,7 +697,7 @@ Example configuration to use a custom clone plugin:
 
 ### Git Submodules
 
-To use the credentials that cloned the repository to clone it's submodules, update `.gitmodules` to use `https` instead of `git`:
+To use the credentials used to clone the repository to clone its submodules, update `.gitmodules` to use `https` instead of `git`:
 
 ```diff
  [submodule "my-module"]
@@ -706,6 +723,10 @@ steps:
 
 ## `skip_clone`
 
+:::warning
+The default clone step is executed as `root` to ensure that the workspace directory can be accessed by any user (`0777`). This is necessary to allow rootless step containers to write to the workspace directory. If a rootless step container is used with `skip_clone`, the user must ensure a suitable workspace directory that can be accessed by the unprivileged container use, e.g. `/tmp`.
+:::
+
 By default Woodpecker is automatically adding a clone step. This clone step can be configured by the [clone](#clone) property. If you do not need a `clone` step at all you can skip it using:
 
 ```yaml

docs/versioned_docs/version-3.7/20-usage/40-secrets.md

@@ -0,0 +1,148 @@
+# Secrets
+
+Woodpecker provides the ability to store named variables in a central secret store.
+These secrets can be securely passed on to individual pipeline steps using the keyword `from_secret`.
+
+There are three different levels of secrets available. If a secret is defined in multiple levels, the following order of priority applies (last wins):
+
+1. **Repository secrets**: Available for all pipelines of a repository.
+1. **Organization secrets**: Available for all pipelines of an organization.
+1. **Global secrets**: Can only be set by instance administrators.
+   Global secrets are available for all pipelines of the **entire** Woodpecker instance and should therefore be used with caution.
+
+In addition to the native integration of secrets, external providers of secrets can also be used by interacting with them directly within pipeline steps. Access to these providers can be configured with Woodpecker secrets, which enables the retrieval of secrets from the respective external sources.
+
+:::warning
+Woodpecker can mask secrets from its own secrets store, but it cannot apply the same protection to external secrets. As a result, these external secrets can be exposed in the pipeline logs.
+:::
+
+## Usage
+
+You can set a setting or environment value from Woodpecker secrets by using the `from_secret` syntax.
+
+The following example passes a secret called `secret_token` which is stored in an environment variable called `TOKEN_ENV`:
+
+```diff
+ steps:
+   - name: 'step name'
+     image: registry/repo/image:tag
+     commands:
++      - echo "The secret is $TOKEN_ENV"
++    environment:
++      TOKEN_ENV:
++        from_secret: secret_token
+```
+
+The same syntax can be used to pass secrets to (plugin) settings.
+A secret called `secret_token` is assigned to the setting `TOKEN`, which is then available in the plugin as the environment variable `PLUGIN_TOKEN` (see [plugins](./51-plugins/20-creating-plugins.md#settings) for details).
+`PLUGIN_TOKEN` is then used internally by the plugin itself and taken into account during execution.
+
+```diff
+ steps:
+   - name: 'step name'
+     image: registry/repo/image:tag
++    settings:
++      TOKEN:
++        from_secret: secret_token
+```
+
+### Escape secrets
+
+Please note that parameter expressions are preprocessed, i.e. they are evaluated before the pipeline starts.
+If secrets are to be used in expressions, they must be properly escaped (with `$$`) to ensure correct processing.
+
+```diff
+ steps:
+   - name: docker
+     image: docker
+     commands:
+-      - echo ${TOKEN_ENV}
++      - echo $${TOKEN_ENV}
+     environment:
+       TOKEN_ENV:
+         from_secret: secret_token
+```
+
+### Events filter
+
+By default, secrets are not exposed to pull requests.
+However, you can change this behavior by creating the secret and enabling the `pull_request` event type.
+This can be configured either via the UI or via the CLI.
+
+:::warning
+Be careful when exposing secrets for pull requests.
+If your repository is public and accepts pull requests from everyone, your secrets may be at risk.
+Malicious actors could take advantage of this to expose your secrets or transfer them to an external location.
+:::
+
+### Plugins filter
+
+To prevent your secrets from being misused by malicious users, you can restrict a secret to a list of plugins.
+If enabled, they are not available to any other plugins.
+Plugins have the advantage that they cannot execute arbitrary commands and therefore cannot reveal secrets.
+
+:::tip
+If you specify a tag, the filter will take it into account.
+However, if the same image appears several times in the list, the least privileged entry will take precedence.
+For example, an image without a tag will allow all tags, even if it contains another entry with a tag attached.
+:::
+
+![plugins filter](./secrets-plugins-filter.png)
+
+## CLI
+
+In addition to the UI, secrets can also be managed using the CLI.
+
+Create the secret with the default settings.
+The secret is available for all images in your pipeline and for all `push`, `tag` and `deployment` events (not for `pull_request` events).
+
+```bash
+woodpecker-cli repo secret add \
+  --repository octocat/hello-world \
+  --name aws_access_key_id \
+  --value <value>
+```
+
+Create the secret and limit it to a single image:
+
+```diff
+ woodpecker-cli secret add \
+   --repository octocat/hello-world \
++  --image woodpeckerci/plugin-s3 \
+   --name aws_access_key_id \
+   --value <value>
+```
+
+Create the secrets and limit it to a set of images:
+
+```diff
+ woodpecker-cli repo secret add \
+   --repository octocat/hello-world \
++  --image woodpeckerci/plugin-s3 \
++  --image woodpeckerci/plugin-docker-buildx \
+   --name aws_access_key_id \
+   --value <value>
+```
+
+Create the secret and enable it for multiple hook events:
+
+```diff
+ woodpecker-cli repo secret add \
+   --repository octocat/hello-world \
+   --image woodpeckerci/plugin-s3 \
++  --event pull_request \
++  --event push \
++  --event tag \
+   --name aws_access_key_id \
+   --value <value>
+```
+
+Secrets can be loaded from a file using the syntax `@`.
+This method is recommended for loading secrets from a file, as it ensures that line breaks are preserved (this is important for SSH keys, for example):
+
+```diff
+ woodpecker-cli repo secret add \
+   -repository octocat/hello-world \
+   -name ssh_key \
++  -value @/root/ssh/id_rsa
+```

docs/versioned_docs/version-3.7/20-usage/51-plugins/51-overview.md

@@ -64,5 +64,6 @@ There are also other plugin lists with additional plugins. Keep in mind that [Dr
 
 - [Drone Plugins](http://plugins.drone.io)
 - [Geeklab Woodpecker Plugins](https://woodpecker-plugins.geekdocs.de/)
+- [Woodpecker Community Plugins](https://codeberg.org/woodpecker-community)
 
 :::

docs/versioned_docs/version-3.7/20-usage/70-volumes.md

@@ -19,6 +19,8 @@ Volumes are only available to trusted repositories and for security reasons shou
 +      - /var/run/docker.sock:/var/run/docker.sock
 ```
 
+If you use the Docker backend, you can also use named volumes like `some_volume_name:/var/run/volume`.
+
 Please note that Woodpecker mounts volumes on the host machine. This means you must use absolute paths when you configure volumes. Attempting to use relative paths will result in an error.
 
 ```diff

docs/versioned_docs/version-3.7/30-administration/05-installation/30-packages.md

@@ -8,12 +8,14 @@
 The pre-built packages are available on the [GitHub releases](https://github.com/woodpecker-ci/woodpecker/releases/latest) page. The packages can be installed using the package manager of your distribution.
 
 ```Shell
-# Debian/Ubuntu
-curl -L https://github.com/woodpecker-ci/woodpecker/releases/download/${RELEASE_VERSION}/woodpecker_${RELEASE_VERSION}_amd64.deb -o woodpecker-server.deb
-sudo apt --fix-broken install ./woodpecker-server.deb
+RELEASE_VERSION=$(curl -s https://api.github.com/repos/woodpecker-ci/woodpecker/releases/latest | grep -Po '"tag_name":\s"v\K[^"]+')
 
-# CentOS/RHEL
-sudo dnf install https://github.com/woodpecker-ci/woodpecker/releases/download/${RELEASE_VERSION}/woodpecker_${RELEASE_VERSION}_amd64.rpm
+# Debian/Ubuntu (x86_64)
+curl -fLOOO "https://github.com/woodpecker-ci/woodpecker/releases/download/v${RELEASE_VERSION}/woodpecker-{server,agent,cli}_${RELEASE_VERSION}_amd64.deb"
+sudo apt --fix-broken install ./woodpecker-{server,agent,cli}_${RELEASE_VERSION}_amd64.deb
+
+# CentOS/RHEL (x86_64)
+sudo dnf install https://github.com/woodpecker-ci/woodpecker/releases/download/v${RELEASE_VERSION}/woodpecker-{server,agent,cli}-${RELEASE_VERSION}.x86_64.rpm
 ```
 
 The package installation will create a systemd service file for the Woodpecker server and agent along with an example environment file. To configure the server, copy the example environment file `/etc/woodpecker/woodpecker-server.env.example` to `/etc/woodpecker/woodpecker-server.env` and adjust the values.
@@ -113,21 +115,18 @@ in
   # This automatically sets up certificates via let's encrypt
   security.acme.defaults.email = "acme@example.com";
   security.acme.acceptTerms = true;
-  security.acme.certs."${domain}" = { };
 
   # Setting up a nginx proxy that handles tls for us
-  networking.firewall.allowedTCPPorts = [ 80 443 ];
   services.nginx = {
     enable = true;
+    openFirewall = true;
     recommendedTlsSettings = true;
     recommendedOptimisation = true;
     recommendedProxySettings = true;
     virtualHosts."${domain}" = {
       enableACME = true;
       forceSSL = true;
-      locations."/" = {
-        proxyPass = "http://localhost:3007";
-      };
+      locations."/".proxyPass = "http://localhost:3007";
     };
   };
 

docs/versioned_docs/version-3.7/30-administration/10-configuration/10-server.md

@@ -1053,8 +1053,6 @@ Supported variables:
 
 ---
 
----
-
 ### CONFIG_SERVICE_ENDPOINT
 
 - Name: `WOODPECKER_CONFIG_SERVICE_ENDPOINT`
@@ -1118,6 +1116,32 @@ Directory to store logs in if [`WOODPECKER_LOG_STORE`](#log_store) is `file`.
 
 ---
 
+### EXPERT_WEBHOOK_HOST
+
+- Name: `WOODPECKER_EXPERT_WEBHOOK_HOST`
+- Default: none
+
+:::warning
+This option is not required in most cases and should only be used if you know what you're doing.
+:::
+
+Fully qualified Woodpecker server URL, called by the webhooks of the forge. Format: `<scheme>://<host>[/<prefix path>]`.
+
+---
+
+### EXPERT_FORGE_OAUTH_HOST
+
+- Name: `WOODPECKER_EXPERT_FORGE_OAUTH_HOST`
+- Default: none
+
+:::warning
+This option is not required in most cases and should only be used if you know what you're doing.
+:::
+
+Fully qualified public forge URL, used if forge url is not a public URL. Format: `<scheme>://<host>[/<prefix path>]`.
+
+---
+
 ### GITHUB\_\*
 
 See [GitHub configuration](./12-forges/20-github.md#configuration)

docs/versioned_docs/version-3.7/30-administration/10-configuration/11-backends/20-kubernetes.md

@@ -6,6 +6,20 @@ toc_max_heading_level: 2
 
 The Kubernetes backend executes steps inside standalone Pods. A temporary PVC is created for the lifetime of the pipeline to transfer files between steps.
 
+## Metadata labels
+
+Woodpecker adds some labels to the pods to provide additional context to the workflow. These labels can be used for various purposes, e.g. for simple debugging or as selectors for network policies.
+
+The following metadata labels are supported:
+
+- `woodpecker-ci.org/forge-id`
+- `woodpecker-ci.org/repo-forge-id`
+- `woodpecker-ci.org/repo-id`
+- `woodpecker-ci.org/repo-name`
+- `woodpecker-ci.org/repo-full-name`
+- `woodpecker-ci.org/branch`
+- `woodpecker-ci.org/org-id`
+
 ## Private registries
 
 In addition to [registries specified in the UI](../../../20-usage/41-registries.md), you may provide [registry credentials in Kubernetes Secrets](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) to pull private container images defined in your pipeline YAML.

docs/versioned_docs/version-3.7/30-administration/10-configuration/40-autoscaler.md

@@ -27,7 +27,7 @@ services:
       - WOODPECKER_MIN_AGENTS=0
       - WOODPECKER_MAX_AGENTS=3
       - WOODPECKER_WORKFLOWS_PER_AGENT=2 # the number of workflows each agent can run at the same time
-      - WOODPECKER_GRPC_ADDR=https://grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents
+      - WOODPECKER_GRPC_ADDR=grpc.your-woodpecker-server.tld # the grpc address of your woodpecker server, publicly accessible from the agents. See https://woodpecker-ci.org/docs/administration/configuration/server#caddy for an example of how to expose it. Do not include "https://" in the value.
       - WOODPECKER_GRPC_SECURE=true
       - WOODPECKER_AGENT_ENV= # optional environment variables to pass to the agents
       - WOODPECKER_PROVIDER=hetznercloud # set the provider, you can find all the available ones down below

docs/versioned_docs/version-3.7/40-cli.md

@@ -56,7 +56,6 @@ woodpecker-cli [GLOBAL OPTIONS] [command [COMMAND OPTIONS]] [ARGUMENTS...]
 
 **--token, -t**="": server auth token
 
-
 # COMMANDS
 
 ## admin
@@ -131,6 +130,8 @@ add a secret
 
 **--image**="": secret limited to these images (default: [])
 
+**--name**="": secret name
+
 **--value**="": secret value
 
 #### rm
@@ -268,8 +269,6 @@ execute a local pipeline
 
 **--backend-no-proxy**="": if set, pass the environment variable down as "NO_PROXY" to steps
 
-**--commit-author-avatar**="": Set the metadata environment variable "CI_COMMIT_AUTHOR_AVATAR".
-
 **--commit-author-email**="": Set the metadata environment variable "CI_COMMIT_AUTHOR_EMAIL".
 
 **--commit-author-name**="": Set the metadata environment variable "CI_COMMIT_AUTHOR".
@@ -326,8 +325,6 @@ execute a local pipeline
 
 **--plugins-privileged**="": Allow plugins to run in privileged mode, if environment variable is defined but empty there will be none (default: [])
 
-**--prev-commit-author-avatar**="": Set the metadata environment variable "CI_PREV_COMMIT_AUTHOR_AVATAR".
-
 **--prev-commit-author-email**="": Set the metadata environment variable "CI_PREV_COMMIT_AUTHOR_EMAIL".
 
 **--prev-commit-author-name**="": Set the metadata environment variable "CI_PREV_COMMIT_AUTHOR".
@@ -398,9 +395,9 @@ execute a local pipeline
 
 **--workflow-number**="": Set the metadata environment variable "CI_WORKFLOW_NUMBER". (default: 0)
 
-**--workspace-base**="":  (default: /woodpecker)
+**--workspace-base**="": (default: /woodpecker)
 
-**--workspace-path**="":  (default: src)
+**--workspace-path**="": (default: src)
 
 ## info
 
@@ -415,7 +412,7 @@ lint a pipeline configuration file
 
 **--plugins-privileged**="": allow plugins to run in privileged mode, if set empty, there is no (default: [])
 
-**--plugins-trusted-clone**="": plugins that are trusted to handle Git credentials in cloning steps (default: [docker.io/woodpeckerci/plugin-git:2.6.2 docker.io/woodpeckerci/plugin-git quay.io/woodpeckerci/plugin-git])
+**--plugins-trusted-clone**="": plugins that are trusted to handle Git credentials in cloning steps (default: [docker.io/woodpeckerci/plugin-git:2.6.3 docker.io/woodpeckerci/plugin-git quay.io/woodpeckerci/plugin-git])
 
 **--strict**: treat warnings as errors
 

docs/versioned_sidebars/version-3.4-sidebars.json

@@ -1,8 +0,0 @@
-{
-  "tutorialSidebar": [
-    {
-      "type": "autogenerated",
-      "dirName": "."
-    }
-  ]
-}

docs/versions.json

@@ -1,6 +1,6 @@
 [
+  "3.7",
   "3.6",
   "3.5",
-  "3.4",
   "2.8"
 ]