From 145185b169b13eeb53f4b9c7d7ee8d959339e21d Mon Sep 17 00:00:00 2001 From: lonix1 <40320097+lonix1@users.noreply.github.com> Date: Thu, 20 Jul 2023 06:09:11 +0200 Subject: [PATCH 01/10] docs: continuous deployment continuous deployment page for newbies like me --- .../docs/20-usage/33-continuous-deployment.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 docs/docs/20-usage/33-continuous-deployment.md diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/docs/20-usage/33-continuous-deployment.md new file mode 100644 index 0000000000..4de22f43cd --- /dev/null +++ b/docs/docs/20-usage/33-continuous-deployment.md @@ -0,0 +1,33 @@ +# Continuous Deployment + +A typical CI pipeline contains steps such as: *clone*, *build*, *test*, *package* and *push*. The final build product may be binaries 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. + +## Invoking deploy script via SSH + +The final step in your pipeline could SSH into the app server, and run a deployment script. + +One of the benefits would be that the deployment script's output could be included in the pipeline's log. However in general, this is a complicated option as it tightly couples the CI and app servers. + +An SSH step could be written as a Woodpecker plugin; although there is no official ssh plugin, one does exist for [Drone](https://plugins.drone.io/plugins/ssh) and could be adapted accordingly. + +## Polling for asset changes + +This option completely decouples the CI and app servers, and there is no explicit deploy step in the pipeline. + +On the app server, one should create a script or cron job which polls for asset changes (every minute, say). When a new version is detected, the script redeploys the app. + +This option is easy to maintain, but the downside is a short delay (one minute) before new assets are detected. + +## Using webhooks + +If your forge (Github, Gitlab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available, and redeploys your app. + +The listening "app" can be something as simple as a PHP script. + +Alternatively, there are a number of popular webhook servers which simplify this process, so you only need to write your actual deployment script. For example, [webhook](https://github.com/adnanh/webhook) and [webhookd](https://github.com/ncarlier/webhookd). + +This is arguably the simplest and most maintainable solution. From 9d422a79050d9110972711c3cd6eee830b279dc3 Mon Sep 17 00:00:00 2001 From: lonix1 <40320097+lonix1@users.noreply.github.com> Date: Thu, 20 Jul 2023 06:22:14 +0200 Subject: [PATCH 02/10] docs: added ansible option --- docs/docs/20-usage/33-continuous-deployment.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/docs/20-usage/33-continuous-deployment.md index 4de22f43cd..f1f3083e4e 100644 --- a/docs/docs/20-usage/33-continuous-deployment.md +++ b/docs/docs/20-usage/33-continuous-deployment.md @@ -22,7 +22,15 @@ On the app server, one should create a script or cron job which polls for asset This option is easy to maintain, but the downside is a short delay (one minute) before new assets are detected. -## Using webhooks +## Using a configuration management tool + +If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool so as to perform the redeployment. + +A [Drone](https://plugins.drone.io/plugins/ansible) plugin for Ansible exists and could be adapted accordingly. + +This option is complex and only suitable in an environment in which you're already using configuration management. + +## Using webhooks (recommended) If your forge (Github, Gitlab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available, and redeploys your app. From d4b71512f18c17e1640d895e525fab88e2581ba2 Mon Sep 17 00:00:00 2001 From: 6543 <6543@obermui.de> Date: Fri, 21 Jul 2023 21:47:01 +0200 Subject: [PATCH 03/10] Apply suggestions from code review --- docs/docs/20-usage/33-continuous-deployment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/docs/20-usage/33-continuous-deployment.md index f1f3083e4e..2ff1a32e3d 100644 --- a/docs/docs/20-usage/33-continuous-deployment.md +++ b/docs/docs/20-usage/33-continuous-deployment.md @@ -12,7 +12,7 @@ The final step in your pipeline could SSH into the app server, and run a deploym One of the benefits would be that the deployment script's output could be included in the pipeline's log. However in general, this is a complicated option as it tightly couples the CI and app servers. -An SSH step could be written as a Woodpecker plugin; although there is no official ssh plugin, one does exist for [Drone](https://plugins.drone.io/plugins/ssh) and could be adapted accordingly. +An SSH step could be written by using an plugin, like [ssh](https://plugins.drone.io/plugins/ssh) or [git push](https://woodpecker-ci.org/plugins/Git%20Push). ## Polling for asset changes @@ -26,7 +26,7 @@ This option is easy to maintain, but the downside is a short delay (one minute) If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool so as to perform the redeployment. -A [Drone](https://plugins.drone.io/plugins/ansible) plugin for Ansible exists and could be adapted accordingly. +A plugin for [Ansible](https://plugins.drone.io/plugins/ansible) exists and could be adapted accordingly. This option is complex and only suitable in an environment in which you're already using configuration management. From 50da8178e21428628e1db5deb9b422c22fe142c6 Mon Sep 17 00:00:00 2001 From: 6543 <6543@obermui.de> Date: Fri, 21 Jul 2023 21:53:34 +0200 Subject: [PATCH 04/10] Apply suggestions from code review --- docs/docs/20-usage/33-continuous-deployment.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/docs/20-usage/33-continuous-deployment.md index 2ff1a32e3d..75cd60c984 100644 --- a/docs/docs/20-usage/33-continuous-deployment.md +++ b/docs/docs/20-usage/33-continuous-deployment.md @@ -8,7 +8,7 @@ There are various ways to accomplish CD with Woodpecker, depending on your proje ## Invoking deploy script via SSH -The final step in your pipeline could SSH into the app server, and run a deployment script. +The final step in your pipeline could SSH into the app server and run a deployment script. One of the benefits would be that the deployment script's output could be included in the pipeline's log. However in general, this is a complicated option as it tightly couples the CI and app servers. @@ -18,13 +18,13 @@ An SSH step could be written by using an plugin, like [ssh](https://plugins.dron This option completely decouples the CI and app servers, and there is no explicit deploy step in the pipeline. -On the app server, one should create a script or cron job which polls for asset changes (every minute, say). When a new version is detected, the script redeploys the app. +On the app server, one should create a script or cron job that polls for asset changes (every minute, say). When a new version is detected, the script redeploys the app. This option is easy to maintain, but the downside is a short delay (one minute) before new assets are detected. ## Using a configuration management tool -If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool so as to perform the redeployment. +If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool to perform the redeployment. A plugin for [Ansible](https://plugins.drone.io/plugins/ansible) exists and could be adapted accordingly. @@ -32,10 +32,10 @@ This option is complex and only suitable in an environment in which you're alrea ## Using webhooks (recommended) -If your forge (Github, Gitlab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available, and redeploys your app. +If your forge (Github, Gitlab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available and redeploys your app. The listening "app" can be something as simple as a PHP script. -Alternatively, there are a number of popular webhook servers which simplify this process, so you only need to write your actual deployment script. For example, [webhook](https://github.com/adnanh/webhook) and [webhookd](https://github.com/ncarlier/webhookd). +Alternatively, there are a number of popular webhook servers that simplify this process, so you only need to write your actual deployment script. For example, [webhook](https://github.com/adnanh/webhook) and [webhookd](https://github.com/ncarlier/webhookd). This is arguably the simplest and most maintainable solution. From 77d6c21bfa2929c4009e997fc7a12168e9632c27 Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Sat, 23 Dec 2023 11:42:10 +0000 Subject: [PATCH 05/10] [pre-commit.ci] auto fixes from pre-commit.com hooks [CI SKIP] for more information, see https://pre-commit.ci --- docs/docs/20-usage/33-continuous-deployment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/docs/20-usage/33-continuous-deployment.md index 75cd60c984..6d6fa6d0d0 100644 --- a/docs/docs/20-usage/33-continuous-deployment.md +++ b/docs/docs/20-usage/33-continuous-deployment.md @@ -1,8 +1,8 @@ # Continuous Deployment -A typical CI pipeline contains steps such as: *clone*, *build*, *test*, *package* and *push*. The final build product may be binaries pushed to a git repository or a docker container pushed to a container registry. +A typical CI pipeline contains steps such as: _clone_, _build_, _test_, _package_ and _push_. The final build product may be binaries 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. +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. From 5c766ad097aac28e1f1051a8cb840a7763d0c4f4 Mon Sep 17 00:00:00 2001 From: qwerty287 Date: Mon, 1 Jan 2024 11:15:07 +0100 Subject: [PATCH 06/10] Add continous deployment cookbook --- .../2023-1-1-continous-deployment/index.md} | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) rename docs/{docs/20-usage/33-continuous-deployment.md => cookbook/2023-1-1-continous-deployment/index.md} (82%) diff --git a/docs/docs/20-usage/33-continuous-deployment.md b/docs/cookbook/2023-1-1-continous-deployment/index.md similarity index 82% rename from docs/docs/20-usage/33-continuous-deployment.md rename to docs/cookbook/2023-1-1-continous-deployment/index.md index 6d6fa6d0d0..6134e45944 100644 --- a/docs/docs/20-usage/33-continuous-deployment.md +++ b/docs/cookbook/2023-1-1-continous-deployment/index.md @@ -1,6 +1,15 @@ -# Continuous Deployment - -A typical CI pipeline contains steps such as: _clone_, _build_, _test_, _package_ and _push_. The final build product may be binaries pushed to a git repository or a docker container pushed to a container registry. +--- +title: Continuous Deployment +description: Deploy your artifacts to an app server +slug: continuous-deployment +authors: + - name: lonix1 + url: https://github.com/lonix1 + image_url: https://github.com/lonix1.png +hide_table_of_contents: false +--- + +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. @@ -32,7 +41,7 @@ This option is complex and only suitable in an environment in which you're alrea ## Using webhooks (recommended) -If your forge (Github, Gitlab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available and redeploys your app. +If your forge (GitHub, GitLab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available and redeploys your app. The listening "app" can be something as simple as a PHP script. From 653a3eaab5e35e0eb6934ec4b5717a5165f98fde Mon Sep 17 00:00:00 2001 From: qwerty287 Date: Mon, 1 Jan 2024 11:17:28 +0100 Subject: [PATCH 07/10] fix typo --- docs/cookbook/2023-1-1-continous-deployment/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cookbook/2023-1-1-continous-deployment/index.md b/docs/cookbook/2023-1-1-continous-deployment/index.md index 6134e45944..cb6072ed2c 100644 --- a/docs/cookbook/2023-1-1-continous-deployment/index.md +++ b/docs/cookbook/2023-1-1-continous-deployment/index.md @@ -21,7 +21,7 @@ The final step in your pipeline could SSH into the app server and run a deployme One of the benefits would be that the deployment script's output could be included in the pipeline's log. However in general, this is a complicated option as it tightly couples the CI and app servers. -An SSH step could be written by using an plugin, like [ssh](https://plugins.drone.io/plugins/ssh) or [git push](https://woodpecker-ci.org/plugins/Git%20Push). +An SSH step could be written by using a plugin, like [ssh](https://plugins.drone.io/plugins/ssh) or [git push](https://woodpecker-ci.org/plugins/Git%20Push). ## Polling for asset changes From 2017e9ed7fbed97cf6c1538d2f901c91692338f4 Mon Sep 17 00:00:00 2001 From: qwerty287 Date: Mon, 1 Jan 2024 11:18:25 +0100 Subject: [PATCH 08/10] fix year --- .../index.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/cookbook/{2023-1-1-continous-deployment => 2024-1-1-continous-deployment}/index.md (100%) diff --git a/docs/cookbook/2023-1-1-continous-deployment/index.md b/docs/cookbook/2024-1-1-continous-deployment/index.md similarity index 100% rename from docs/cookbook/2023-1-1-continous-deployment/index.md rename to docs/cookbook/2024-1-1-continous-deployment/index.md From 4a81623cf0cb8b19c68cd184c84d29d7765d2b66 Mon Sep 17 00:00:00 2001 From: qwerty287 Date: Mon, 1 Jan 2024 11:26:38 +0100 Subject: [PATCH 09/10] fix missing truncate --- docs/cookbook/2024-1-1-continous-deployment/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/cookbook/2024-1-1-continous-deployment/index.md b/docs/cookbook/2024-1-1-continous-deployment/index.md index cb6072ed2c..159c3e9420 100644 --- a/docs/cookbook/2024-1-1-continous-deployment/index.md +++ b/docs/cookbook/2024-1-1-continous-deployment/index.md @@ -9,6 +9,8 @@ authors: hide_table_of_contents: false --- + + 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. From fa69de14399362b1ed5d01bb1c6191201e9460e6 Mon Sep 17 00:00:00 2001 From: qwerty287 <80460567+qwerty287@users.noreply.github.com> Date: Fri, 5 Jan 2024 09:52:20 +0100 Subject: [PATCH 10/10] use wp plugin --- docs/cookbook/2024-1-1-continous-deployment/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cookbook/2024-1-1-continous-deployment/index.md b/docs/cookbook/2024-1-1-continous-deployment/index.md index 159c3e9420..c1bedcc372 100644 --- a/docs/cookbook/2024-1-1-continous-deployment/index.md +++ b/docs/cookbook/2024-1-1-continous-deployment/index.md @@ -37,7 +37,7 @@ This option is easy to maintain, but the downside is a short delay (one minute) If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool to perform the redeployment. -A plugin for [Ansible](https://plugins.drone.io/plugins/ansible) exists and could be adapted accordingly. +A plugin for [Ansible](https://woodpecker-ci.org/plugins/Ansible) exists and could be adapted accordingly. This option is complex and only suitable in an environment in which you're already using configuration management.