Streamline docs for new users (#3803)

docs/blog/2024-01-01-continuous-deployment/index.md

@@ -1,5 +1,5 @@
 ---
-title: Continuous Deployment
+title: '[Community] Continuous Deployment'
 description: Deploy your artifacts to an app server
 slug: continuous-deployment
 authors:
@@ -7,16 +7,17 @@ authors:
     url: https://github.com/lonix1
     image_url: https://github.com/lonix1.png
 hide_table_of_contents: false
+tags: [community, cd, deployment]
 ---
 
-<!--truncate-->
-
 A typical CI pipeline contains steps such as: _clone_, _build_, _test_, _package_ and _push_. The final build product may be artifacts pushed to a git repository or a docker container pushed to a container registry.
 
 When these should be deployed on an app server, the pipeline should include a _deploy_ step, which represents the "CD" in CI/CD - the automatic deployment of a pipeline's final product.
 
 There are various ways to accomplish CD with Woodpecker, depending on your project's specific needs.
 
+<!--truncate-->
+
 ## Invoking deploy script via SSH
 
 The final step in your pipeline could SSH into the app server and run a deployment script.

docs/cookbook/2023-12-23-hello-cookbook/index.md

@@ -1,13 +0,0 @@
----
-title: Welcome to Woodpecker's cookbook blog
-description: Here, we'll publish various guides and tutorials.
-slug: hello-cookbook
-authors:
-  - name: qwerty287
-    title: Maintainer of Woodpecker
-    url: https://github.com/qwerty287
-    image_url: https://github.com/qwerty287.png
-hide_table_of_contents: false
----
-
-Welcome to this cookbook blog. Here, we and any other interested user can publish guides and tutorials. If you got something in mind, just add your guide!

docs/docs/10-intro.md

@@ -1,89 +0,0 @@
-# Welcome to Woodpecker
-
-Woodpecker is a simple yet powerful CI/CD engine with great extensibility. It focuses on executing pipelines inside [containers](https://opencontainers.org/).
-If you are already using containers in your daily workflow, you'll for sure love Woodpecker.
-
-![woodpecker](woodpecker.png)
-
-## `.woodpecker.yaml`
-
-- Place your pipeline in a file named `.woodpecker.yaml` in your repository
-- Pipeline steps can be named as you like
-- Run any command in the commands section
-
-```yaml title=".woodpecker.yaml"
-steps:
-  - name: build
-    image: debian
-    commands:
-      - echo "This is the build step"
-  - name: a-test-step
-    image: debian
-    commands:
-      - echo "Testing.."
-```
-
-### Steps are containers
-
-- Define any container image as context
-  - either use your own and install the needed tools in a custom image
-  - or search for available images that are already tailored for your needs in image registries like [Docker Hub](https://hub.docker.com/search?type=image)
-- List the commands that should be executed in the container
-
-```diff
- steps:
-   - name: build
--    image: debian
-+    image: mycompany/image-with-awscli
-     commands:
-       - aws help
-```
-
-### File changes are incremental
-
-- Woodpecker clones the source code in the beginning
-- File changes are persisted throughout individual steps as the same volume is being mounted in all steps
-
-```yaml title=".woodpecker.yaml"
-steps:
-  - name: build
-    image: debian
-    commands:
-      - touch myfile
-  - name: a-test-step
-    image: debian
-    commands:
-      - cat myfile
-```
-
-## Plugins are straightforward
-
-- If you copy the same shell script from project to project
-- Pack it into a plugin instead
-- And make the yaml declarative
-- Plugins are Docker images with your script as an entrypoint
-
-```dockerfile title="Dockerfile"
-FROM laszlocloud/kubectl
-COPY deploy /usr/local/deploy
-ENTRYPOINT ["/usr/local/deploy"]
-```
-
-```bash title="deploy"
-kubectl apply -f $PLUGIN_TEMPLATE
-```
-
-```yaml title=".woodpecker.yaml"
-steps:
-  - name: deploy-to-k8s
-    image: laszlocloud/my-k8s-plugin
-    settings:
-      template: config/k8s/service.yaml
-```
-
-See [plugin docs](./20-usage/51-plugins/51-overview.md).
-
-## Continue reading
-
-- [Create a Woodpecker pipeline for your repository](./20-usage/10-intro.md)
-- [Setup your own Woodpecker instance](./30-administration/00-deployment/00-overview.md)

docs/docs/10-intro/index.md

@@ -0,0 +1,26 @@
+# Welcome to Woodpecker
+
+Woodpecker is a CI/CD tool. It is designed to be lightweight, simple to use and fast. Before we dive into the details, let's have a look at some of the basics.
+
+## Have you ever heard of CI/CD or pipelines?
+
+Don't worry if you haven't. We'll guide you through the basics. CI/CD stands for Continuous Integration and Continuous Deployment. It's basically like a conveyor belt that moves your code from development to production doing all kinds of
+checks, tests and routines along the way. A typical pipeline might include the following steps:
+
+1. Running tests
+2. Building your application
+3. Deploying your application
+
+[Have a deeper look into the idea of CI/CD](https://www.redhat.com/en/topics/devops/what-is-ci-cd)
+
+## Do you know containers?
+
+If you are already using containers in your daily workflow, you'll for sure love Woodpecker. If not yet, you'll be amazed how easy it is to get started with [containers](https://opencontainers.org/).
+
+## Already have access to a Woodpecker instace?
+
+Then you might want to jump directly into it and [start creating your first pipelines](../20-usage/10-intro.md).
+
+## Want to start from scratch and deploy your own Woodpecker instance?
+
+Woodpecker is [pretty lightweight](../30-administration/00-getting-started.md#hardware-requirements) and will even run on your Raspberry Pi. You can follow the [deployment guide](../30-administration/00-getting-started.md) to set up your own Woodpecker instance.

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

@@ -1,73 +1,109 @@
-# Getting started
+# Your first pipeline
 
-## Repository Activation
+Let's get started and create your first pipeline.
 
-To activate your project navigate to your account settings. You will see a list of repositories which can be activated with a simple toggle. When you activate your repository, Woodpecker automatically adds webhooks to your forge (e.g. GitHub, Gitea, ...).
+## 1. Repository Activation
 
-Webhooks are used to trigger pipeline executions. When you push code to your repository, open a pull request, or create a tag, your forge will automatically send a webhook to Woodpecker which will in turn trigger the pipeline execution.
+To activate your repository in Woodpecker navigate to the repository list and `New repository`. You will see a list of repositories from your forge (GitHub, Gitlab, ...) which can be activated with a simple click.
 
-![repository list](repo-list.png)
+![new repository list](repo-new.png)
 
-## Required Permissions
+To enable a repository in Woodpecker you must have `Admin` rights on that repository, so that Woodpecker can add something
+that is called a webhook (Woodpecker needs it to know about actions like pushes, pull requests, tags, etc.).
 
-The user who enables a repo in Woodpecker must have `Admin` rights on that repo, so that Woodpecker can add the webhook.
+## 2. Define first workflow
 
-:::note
-Note that manually creating webhooks yourself is not possible.
-This is because webhooks are signed using a per-repository secret key which is not exposed to end users.
-:::
+After enabling a repository Woodpecker will listen for changes in your repository. When a change is detected, Woodpecker will check for a pipeline configuration. So let's create a file at `.woodpecker/my-first-workflow.yaml` inside your repository:
 
-## Configuration
+```yaml title=".woodpecker/my-first-workflow.yaml"
+when:
+  - event: push
+    branch: main
 
-To configure your pipeline you must create a `.woodpecker.yaml` file in the root of your repository. The `.woodpecker.yaml` file is used to define your pipeline steps.
-
-:::note
-We support most of YAML 1.2, but preserve some behavior from 1.1 for backward compatibility.
-Read more at: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml/tree/v3)
-:::
-
-Example pipeline configuration:
-
-```yaml
 steps:
   - name: build
-    image: golang
+    image: debian
     commands:
-      - go get
-      - go build
-      - go test
-
-services:
-  - name: postgres
-    image: postgres:9.4.5
-    environment:
-      - POSTGRES_USER=myapp
+      - echo "This is the build step"
+      - echo "binary-data-123" > executable
+  - name: a-test-step
+    image: golang:1.16
+    commands:
+      - echo "Testing ..."
+      - ./executable
 ```
 
-Example pipeline configuration with multiple, serial steps:
+**So what did we do here?**
+
+1. We defined your first workflow file `my-first-workflow.yaml`.
+2. This workflow will be executed when a push event happens on the `main` branch,
+   because we added a filter using the `when` section:
+
+   ```diff
+   + when:
+   +   - event: push
+   +     branch: main
+
+   ...
+   ```
+
+3. We defined two steps: `build` and `a-test-step`
+
+The steps are executed in the order they are defined, so `build` will be executed first and then `a-test-step`.
+
+In the `build` step we use the `debian` image and build a "binary file" called `executable`.
+
+In the `a-test-step` we use the `golang:1.16` image and run the `executable` file to test it.
+
+You can use any image from registries like the [Docker Hub](https://hub.docker.com/search?type=image) you have access to:
+
+```diff
+ steps:
+   - name: build
+-    image: debian
++    image: mycompany/image-with-awscli
+     commands:
+       - aws help
+```
+
+## 3. Push the file and trigger first pipeline
+
+If you push this file to your repository now, Woodpecker will already execute your first pipeline.
+
+You can check the pipeline execution in the Woodpecker UI by navigating to the `Pipelines` section of your repository.
+
+![pipeline view](./pipeline.png)
+
+As you probably noticed, there is another step in called `clone` which is executed before your steps. This step clones your repository into a folder called `workspace` which is available throughout all steps.
+
+This for example allows the first step to build your application using your source code and as the second step will receive
+the same workspace it can use the previously built binary and test it.
+
+## 4. Use a plugin for reusable tasks
+
+Sometimes you have some tasks that you need to do in every project. For example, deploying to Kubernetes or sending a Slack message. Therefore you can use one of the [official and community plugins](/plugins) or simply [create your own](./51-plugins/20-creating-plugins.md).
+
+If you want to get a Slack notification after your pipeline has finished, you can add a Slack plugin to your pipeline:
 
 ```yaml
-steps:
-  - name: backend
-    image: golang
-    commands:
-      - go get
-      - go build
-      - go test
-
-  - name: frontend
-    image: node:6
-    commands:
-      - npm install
-      - npm test
-
-  - name: notify
-    image: plugins/slack
-    settings:
-      channel: developers
-      username: woodpecker
+---
+- name: notify me on Slack
+  image: plugins/slack
+  settings:
+    channel: developers
+    username: woodpecker
+    password:
+      from_secret: slack_token
+  when:
+    status: [success, failure] # This will execute the step on success and failure
 ```
 
-## Execution
+To configure a plugin you can use the `settings` section.
 
-To trigger your first pipeline execution you can push code to your repository, open a pull request, or push a tag. Any of these events triggers a webhook from your forge and execute your pipeline.
+Sometime you need to provide secrets to the plugin. You can do this by using the `from_secret` key. The secret must be defined in the Woodpecker UI. You can find more information about secrets [here](./40-secrets.md).
+
+Similar to the `when` section at the top of the file which is for the complete workflow, you can use the `when` section for each step to define when a step should be executed.
+
+Learn more about [plugins](./51-plugins/51-overview.md).
+
+As you now have a basic understanding of how to create a pipeline, you can dive deeper into the [workflow syntax](./20-workflow-syntax.md) and [plugins](./51-plugins/51-overview.md).

docs/docs/20-usage/15-terminology/index.md

@@ -1,13 +1,5 @@
 # Terminology
 
-## Woodpecker architecture
-
-![Woodpecker architecture](architecture.svg)
-
-## Pipeline, workflow & step
-
-![Relation between pipelines, workflows and steps](pipeline-workflow-step.svg)
-
 ## Glossary
 
 - **Woodpecker CI**: The project name around Woodpecker.
@@ -33,6 +25,14 @@
 - **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.
 
+## Woodpecker architecture
+
+![Woodpecker architecture](architecture.svg)
+
+## Pipeline, workflow & step
+
+![Relation between pipelines, workflows and steps](pipeline-workflow-step.svg)
+
 ## Pipeline events
 
 - `push`: A push event is triggered when a commit is pushed to a branch.

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

@@ -6,6 +6,11 @@ The Workflow section defines a list of steps to build, test and deploy your code
 An exception to this rule are steps with a [`status: [failure]`](#status) condition, which ensures that they are executed in the case of a failed run.
 :::
 
+:::note
+We support most of YAML 1.2, but preserve some behavior from 1.1 for backward compatibility.
+Read more at: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml/tree/v3)
+:::
+
 Example steps:
 
 ```yaml

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

@@ -4,6 +4,24 @@ Plugins are pipeline steps that perform pre-defined tasks and are configured as
 
 They are automatically pulled from the default container registry the agent's have configured.
 
+```dockerfile title="Dockerfile"
+FROM laszlocloud/kubectl
+COPY deploy /usr/local/deploy
+ENTRYPOINT ["/usr/local/deploy"]
+```
+
+```bash title="deploy"
+kubectl apply -f $PLUGIN_TEMPLATE
+```
+
+```yaml title=".woodpecker.yaml"
+steps:
+  - name: deploy-to-k8s
+    image: laszlocloud/my-k8s-plugin
+    settings:
+      template: config/k8s/service.yaml
+```
+
 Example pipeline using the Docker and Slack plugins:
 
 ```yaml

docs/docs/30-administration/00-deployment/00-overview.md

@@ -1,77 +0,0 @@
-# Deployment
-
-A Woodpecker deployment consists of two parts:
-
-- A server which is the heart of Woodpecker and ships the web interface.
-- Next to one server, you can deploy any number of agents which will run the pipelines.
-
-Each agent is able to process one pipeline step by default.
-If you have four agents installed and connected to the Woodpecker server, your system will process four workflows in parallel.
-
-:::tip
-You can add more agents to increase the number of parallel workflows or set the agent's `WOODPECKER_MAX_WORKFLOWS=1` environment variable to increase the number of parallel workflows for that agent.
-:::
-
-## Which version of Woodpecker should I use?
-
-Woodpecker is having two different kinds of releases: **stable** and **next**.
-
-Find more information about the different versions [here](/versions).
-
-## Hardware Requirements
-
-Below are minimal resources requirements for Woodpecker components itself:
-
-| Component | Memory | CPU |
-| --------- | ------ | --- |
-| Server    | 200 MB | 1   |
-| Agent     | 32 MB  | 1   |
-
-Note, that those values do not include the operating system or workload (pipelines execution) resources consumption.
-
-In addition you need at least some kind of database which requires additional resources depending on the selected database system.
-
-## Installation
-
-You can install Woodpecker on multiple ways:
-
-- Using [docker-compose](./10-docker-compose.md) with the official [container images](./10-docker-compose.md#docker-images)
-- Using [Kubernetes](./20-kubernetes.md) via the Woodpecker Helm chart
-- Using binaries, DEBs or RPMs you can download from [latest release](https://github.com/woodpecker-ci/woodpecker/releases/latest)
-
-## Authentication
-
-Authentication is done using OAuth and is delegated to your forge which is configured using environment variables.
-
-See the complete reference for all supported forges [here](../11-forges/11-overview.md).
-
-## Database
-
-By default Woodpecker uses a SQLite database which requires zero installation or configuration. See the [database settings](../30-database.md) page to further configure it or use MySQL or Postgres.
-
-## SSL
-
-Woodpecker supports SSL configuration by using Let's encrypt or by using own certificates. See the [SSL guide](../60-ssl.md). You can also put it behind a [reverse proxy](#behind-a-proxy)
-
-## Metrics
-
-A [Prometheus endpoint](../90-prometheus.md) is exposed.
-
-## Behind a proxy
-
-See the [proxy guide](../70-proxy.md) if you want to see a setup behind Apache, Nginx, Caddy or ngrok.
-
-In the case you need to use Woodpecker with a URL path prefix (like: <https://example.org/woodpecker/>), add the root path to [`WOODPECKER_HOST`](../10-server-config.md#woodpecker_host).
-
-## Third-party installation methods
-
-:::info
-These installation methods are not officially supported. If you experience issues with them, please open issues in the specific repositories.
-:::
-
-- [Using NixOS](./30-nixos.md) via the [NixOS module](https://search.nixos.org/options?channel=unstable&size=200&sort=relevance&query=woodpecker)
-- [On Alpine Edge](https://pkgs.alpinelinux.org/packages?name=woodpecker&branch=edge&repo=&arch=&maintainer=)
-- [On Arch Linux](https://archlinux.org/packages/?q=woodpecker)
-- [On openSUSE](https://software.opensuse.org/package/woodpecker)
-- [Using YunoHost](https://apps.yunohost.org/app/woodpecker)
-- [On Cloudron](https://www.cloudron.io/store/org.woodpecker_ci.cloudronapp.html)

docs/docs/30-administration/00-getting-started.md

@@ -0,0 +1,59 @@
+# Gettings started
+
+A Woodpecker deployment consists of two parts:
+
+- A server which is the heart of Woodpecker and ships the web interface.
+- Next to one server, you can deploy any number of agents which will run the pipelines.
+
+Each agent is able to process one [workflow](../20-usage/15-terminology/index.md) by default. If you have 4 agents installed and connected to the Woodpecker server, your system will process four workflows (not pipelines) in parallel.
+
+:::tip
+You can add more agents to increase the number of parallel workflows or set the agent's `WOODPECKER_MAX_WORKFLOWS=1` environment variable to increase the number of parallel workflows per agent.
+:::
+
+## Which version of Woodpecker should I use?
+
+Woodpecker is having two different kinds of releases: **stable** and **next**.
+
+Find more information about the different versions [here](/versions).
+
+## Hardware Requirements
+
+Below are minimal resources requirements for Woodpecker components itself:
+
+| Component | Memory | CPU |
+| --------- | ------ | --- |
+| Server    | 200 MB | 1   |
+| Agent     | 32 MB  | 1   |
+
+Note, that those values do not include the operating system or workload (pipelines execution) resource consumption.
+
+In addition you need at least some kind of database which requires additional resources depending on the selected database system.
+
+## Installation
+
+You can install Woodpecker on multiple ways. If you are not sure which one to choose, we recommend using the [docker-compose](./05-deployment-methods/10-docker-compose.md) method for the beginning:
+
+- Using [docker-compose](./05-deployment-methods/10-docker-compose.md) with the official [container images](./05-deployment-methods/10-docker-compose.md#docker-images)
+- Using [Kubernetes](./05-deployment-methods/20-kubernetes.md) via the Woodpecker Helm chart
+- Using binaries, DEBs or RPMs you can download from [latest release](https://github.com/woodpecker-ci/woodpecker/releases/latest)
+- Or using a [third-party installation method](./05-deployment-methods/30-third-party.md)
+
+## Database
+
+By default Woodpecker uses a SQLite database which requires zero installation or configuration. See the [database settings](./10-database.md) page if you want to use a different database system like MySQL or PostgreSQL.
+
+## Forge
+
+What would be a CI/CD system without any code? By connecting Woodpecker to your [forge](../20-usage/15-terminology/index.md) like GitHub or Gitea you can start running pipelines on events like pushes or pull requests. Woodpecker will also use your forge for authentication and to report back the status of your pipelines. See the [forge settings](./11-forges/11-overview.md) to conntect it to Woodpecker.
+
+## Configuration
+
+Check the [server configuration](./10-server-config.md) and [agent configuration](./15-agent-config.md) pages to see if you need to adjust any additional parts and after that you should be ready to start with [your first pipeline](../20-usage/10-intro.md).
+
+## Agent
+
+The agent is the worker which executes the [workflows](../20-usage/15-terminology/index.md).
+Woodpecker agents can execute work using a [backend](../20-usage/15-terminology/index.md) like [docker](./22-backends/10-docker.md) or [kubernetes](./22-backends/40-kubernetes.md).
+By default if you choose to deploy an agent using [docker-compose](./05-deployment-methods/10-docker-compose.md) the agent simply use docker for the backend as well.
+So nothing to worry about here. If you still prefer to adjust the agent to your needs, check the [agent configuration](./15-agent-config.md) page.

docs/docs/30-administration/05-deployment-methods/10-docker-compose.md

@@ -67,7 +67,7 @@ They can be configured with `*_ADDR` variables:
 +      - WOODPECKER_SERVER_ADDR=${WOODPECKER_HTTP_ADDR}
 ```
 
-Reverse proxying can also be [configured for gRPC](../70-proxy.md#caddy). If the agents are connecting over the internet, it should also be SSL encrypted. The agent then needs to be configured to be secure:
+Reverse proxying can also be [configured for gRPC](../40-advanced/10-proxy.md#caddy). If the agents are connecting over the internet, it should also be SSL encrypted. The agent then needs to be configured to be secure:
 
 ```diff title="docker-compose.yaml"
  version: '3'

docs/docs/30-administration/05-deployment-methods/30-third-party.md

@@ -0,0 +1,12 @@
+# Third-party installation methods
+
+:::info
+These installation methods are not officially supported. If you experience issues with them, please open issues in the specific repositories.
+:::
+
+- [Using NixOS](./40-nixos.md) via the [NixOS module](https://search.nixos.org/options?channel=unstable&size=200&sort=relevance&query=woodpecker)
+- [On Alpine Edge](https://pkgs.alpinelinux.org/packages?name=woodpecker&branch=edge&repo=&arch=&maintainer=)
+- [On Arch Linux](https://archlinux.org/packages/?q=woodpecker)
+- [On openSUSE](https://software.opensuse.org/package/woodpecker)
+- [Using YunoHost](https://apps.yunohost.org/app/woodpecker)
+- [On Cloudron](https://www.cloudron.io/store/org.woodpecker_ci.cloudronapp.html)

docs/docs/30-administration/05-deployment-methods/_category_.yaml

@@ -0,0 +1,3 @@
+label: 'Deployment methods'
+collapsible: true
+collapsed: true

docs/docs/30-administration/10-server-config.md

@@ -517,7 +517,7 @@ Example: `WOODPECKER_LIMIT_CPU_SET=1,2`
 
 > Default: empty
 
-Specify a configuration service endpoint, see [Configuration Extension](./100-external-configuration-api.md)
+Specify a configuration service endpoint, see [Configuration Extension](./40-advanced/100-external-configuration-api.md)
 
 ### `WOODPECKER_FORGE_TIMEOUT`
 

docs/docs/30-administration/40-advanced/10-proxy.md

@@ -93,7 +93,7 @@ woodpeckeragent.example.com {
 ```
 
 :::note
-Above configuration shows how to create reverse-proxies for web and agent communication. If your agent uses SSL do not forget to enable [`WOODPECKER_GRPC_SECURE`](./15-agent-config.md#woodpecker_grpc_secure).
+Above configuration shows how to create reverse-proxies for web and agent communication. If your agent uses SSL do not forget to enable [`WOODPECKER_GRPC_SECURE`](../15-agent-config.md#woodpecker_grpc_secure).
 :::
 
 ## Tunnelmole

docs/docs/30-administration/40-advanced/40-advanced.md

@@ -0,0 +1,25 @@
+# Adavanced options
+
+Why should we be happy with a default setup? We should not! Woodpecker offers a lot of advanced options to configure it to your needs.
+
+## Behind a proxy
+
+See the [proxy guide](./10-proxy.md) if you want to see a setup behind Apache, Nginx, Caddy or ngrok.
+
+In the case you need to use Woodpecker with a URL path prefix (like: <https://example.org/woodpecker/>), add the root path to [`WOODPECKER_HOST`](../10-server-config.md#woodpecker_host).
+
+## SSL
+
+Woodpecker supports SSL configuration by using Let's encrypt or by using own certificates. See the [SSL guide](./20-ssl.md).
+
+## Metrics
+
+A [Prometheus endpoint](./90-prometheus.md) is exposed by Woodpecker to collect metrics.
+
+## Autoscaling
+
+The [autoscaler](./30-autoscaler.md) can be used to deploy new agents to a cloud provider based on the current workload your server is experiencing.
+
+## Configuration service
+
+Sometime the normal yaml configuration compiler isn't enough. You can use the [configuration service](./100-external-configuration-api.md) to process your configuration files by your own.

docs/docs/30-administration/40-advanced/_category_.yaml

@@ -1,6 +1,6 @@
-label: 'Deployment'
+label: 'Advanced'
 collapsible: true
 collapsed: true
 link:
   type: 'doc'
-  id: 'overview'
+  id: 'advanced'

docs/docs/91-migrations.md

@@ -37,7 +37,7 @@ Some versions need some changes to the server configuration or the pipeline conf
 
 ## 1.0.0
 
-- The signature used to verify extension calls (like those used for the [config-extension](./30-administration/100-external-configuration-api.md)) done by the Woodpecker server switched from using a shared-secret HMac to an ed25519 key-pair. Read more about it at the [config-extensions](./30-administration/100-external-configuration-api.md) documentation.
+- The signature used to verify extension calls (like those used for the [config-extension](./30-administration/40-advanced/100-external-configuration-api.md)) done by the Woodpecker server switched from using a shared-secret HMac to an ed25519 key-pair. Read more about it at the [config-extensions](./30-administration/40-advanced/100-external-configuration-api.md) documentation.
 - Refactored support for old agent filter labels and expressions. Learn how to use the new [filter](./20-usage/20-workflow-syntax.md#labels)
 - Renamed step environment variable `CI_SYSTEM_ARCH` to `CI_SYSTEM_PLATFORM`. Same applies for the cli exec variable.
 - Renamed environment variables `CI_BUILD_*` and `CI_PREV_BUILD_*` to `CI_PIPELINE_*` and `CI_PREV_PIPELINE_*`, old ones are still available but deprecated

docs/docs/92-development/02-core-ideas.md

@@ -8,7 +8,7 @@
 ## Addons and extensions
 
 If you are wondering whether your contribution will be accepted to be merged in the Woodpecker core, or whether it's better to write an
-[addon forge](../30-administration/11-forges/100-addon.md), [extension](../30-administration/100-external-configuration-api.md) or an
+[addon forge](../30-administration/11-forges/100-addon.md), [extension](../30-administration/40-advanced/100-external-configuration-api.md) or an
 [external custom backend](../30-administration/22-backends/50-custom-backends.md), please check these points:
 
 - Is your change very specific to your setup and unlikely to be used by anyone else?

docs/docusaurus.config.ts

@@ -63,7 +63,6 @@ const config: Config = {
               to: '/api',
               label: 'API',
             },
-            { to: 'cookbook', label: 'Cookbook' },
           ],
         },
         {
@@ -219,21 +218,6 @@ const config: Config = {
         } as any;
       },
     }),
-    [
-      '@docusaurus/plugin-content-blog',
-      {
-        id: 'cookbook-blog',
-        /**
-         * URL route for the blog section of your site.
-         * *DO NOT* include a trailing slash.
-         */
-        routeBasePath: 'cookbook',
-        /**
-         * Path to data on filesystem relative to site dir.
-         */
-        path: './cookbook',
-      },
-    ],
   ],
   themes: [
     path.resolve(__dirname, 'plugins', 'woodpecker-plugins', 'dist'),