From faabac8b7b84faafe5f837ddc7b03d841225457f Mon Sep 17 00:00:00 2001 From: khanhtc1202 Date: Wed, 3 Sep 2025 01:18:24 +0900 Subject: [PATCH 1/2] Add what new in pipedv1 blog post Signed-off-by: khanhtc1202 --- docs/content/en/blog/what-new-in-pipedv1.md | 122 ++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 docs/content/en/blog/what-new-in-pipedv1.md diff --git a/docs/content/en/blog/what-new-in-pipedv1.md b/docs/content/en/blog/what-new-in-pipedv1.md new file mode 100644 index 0000000000..4af0c3089b --- /dev/null +++ b/docs/content/en/blog/what-new-in-pipedv1.md @@ -0,0 +1,122 @@ +--- +date: 2025-09-02 +title: "What is new in pipedv1 (plugin-arch piped)" +linkTitle: "what is new in pipedv1" +weight: 979 +description: "" +author: Khanh Tran ([@khanhtc1202](https://github.com/khanhtc1202)) +categories: ["Announcement"] +tags: ["Plugin", "New Feature"] +--- + +Since the alpha release from Jun 2025, plugin-arch piped (aka. pipedv1) is closer to first offical release, we are working on v1.0.0-rc0 and will be released in the coming days. + +In this article I would like to share some improvements that have been fixed in the new version pipedv1 compared to its predecessor piped. + +## Overview + +While developing pipedv1, we always considered ensuring backward compatibility, meaning that the features available in piped will be mostly preserved in pipedv1. This ensures seamlessness between using piped and pipedv1, reducing the risk of problems when switching to pipedv1. + +Changes in pipedv1 are of 2 types: + +- Performance improvements or addressing some features requested in pipedv0 but could not be met due to technical reasons. + +- Removal of some features that are obsolete or no longer prioritized + +Fundamental changes like pipedv1 being able to support different platforms and making build pipeline deployment more powerful by turning stage executors into plugins have been described in [this blog](https://pipecd.dev/blog/2024/11/28/overview-of-the-plan-for-pluginnable-pipecd/). This post will focus on smaller changes related to the actual usage of pipecd. + +## New in pipedv1 + +### Pipeline planning and configuration + +Creating pipelines based on different deployment strategies for various specific applications is a strong point that makes PipeCD stand out. With pipedv1, this feature is further enhanced by solving some old limitations in the current piped. + +Since pipedv1, you can create a pipeline consisting of only one SYNC stage. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + pipeline: + stages: + - name: K8S_SYNC + with: + ... +``` + +Or optionally, create a pipeline that includes the SYNC stage combined with other common stages, for example. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + pipeline: + stages: + - name: WAIT + with: + duration: 30s + - name: K8S_SYNC + - name: WAIT + with: + duration: 30s +``` + +### Stages configurations + +Regarding stages (units of the pipecd pipeline), a feature that has been requested by many users is `skipOn`, which allows skipping a stage in the application deployment pipeline under certain conditions. + +In the current version of piped, skipOn is only supported in limited ways for some stages (like Analysis Stage - ref: [docs](https://pipecd.dev/docs-v0.53.x/user-guide/configuration-reference/#analysisstageoptions)), in pipedv1, all stages support this feature. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + pipeline: + stages: + - name: WAIT + skipOn: + paths: + - '*/canary' + with: + duration: 30s +``` + +An unstable feature in piped is stage timeout, in pipedv1 version, all stages also support timeout settings. The default stage timeout will be 6 hours. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + pipeline: + stages: + - name: WAIT_APPROVAL + timeout: 1h # Default is 6h + with: + approvers: + - khanhtc1202 +``` + +## Deprecated / Dis-supported features + +### "Weird" flag in piped execution + +A long-time "weird" flag for piped binary execution if you don't use PipeCD for a Kubernetes application is `--enable-default-kubernetes-cloud-provider`, which is basically legacy due to the first implementation of PipeCD focusing on supporting only Kubernetes. The default value is `false`, but if you set that flag to `true`, piped execution requires connecting to the Kubernetes cluster even before any application deployment is actually triggered. In pipedv1, nothing like that flag exists in piped execution because pipedv1 supports whatever platform its plugins support equally. + +### Kubernetes templating feature + +Related to Kubernetes support features of PipeCD. Currently, piped supports the Helm Git Remote Chart feature (ref [piped config helm chart repository](https://pipecd.dev/docs-v0.53.x/user-guide/managing-piped/configuration-reference/#chartrepository)), which pulls the chart file stored directly on Git to the local and builds/templates as for a Local Chart. With the emergence and standardization of OCI, storing and sharing Helm Charts has become easier via the [Helm registry](https://helm.sh/docs/helm/helm_registry/). Therefore, in pipedv1, we decided to stop supporting this feature. + +### Analysis stage query templating feature + +Current piped support building queries used while evaluating metrics with deployment-specific data to be embedded in the analysis template (ref: [analysis templating docs](https://pipecd.dev/docs-v0.53.x/user-guide/managing-application/customizing-deployment/automated-deployment-analysis/#optional-analysis-template)). + +From pipedv1, along with built-in and custom args are supported with placeholders as `{{ .App }}` and `{{ .AppCustomArgs }}` respectively, Kubernetes-specific built-in args like `{{ .K8s.Namespace }}` will be marked as deprecated and unsupported after several releases. The corresponding usage for the Kubernetes Namespace use case is changed to `{{ .AppCustomArgs.k8sNamespace }}`. + +Here are some changes you might notice when switching to pipedv1. We ensure a certain level of backward compatibility between piped and pipedv1. The improvements are all aimed at making pipedv1 support more platforms and making it easier to build pipelines based on plugins. + +The official documentation for pipedv1 is still being prepared, and the experimental release of pipedv1 will be available on the [official pipecd repo release tab](https://github.com/pipe-cd/pipecd/releases), along with some built-in plugins in the next few days. Thanks for your attention, cheer 🍻 + From 5836ae1578b811a5c6b06f06ba0acb57568783dd Mon Sep 17 00:00:00 2001 From: khanhtc1202 Date: Wed, 3 Sep 2025 15:41:55 +0900 Subject: [PATCH 2/2] Add plugins config session and change piped execution flag session title Signed-off-by: khanhtc1202 --- docs/content/en/blog/what-new-in-pipedv1.md | 105 ++++++++++++++++++-- 1 file changed, 99 insertions(+), 6 deletions(-) diff --git a/docs/content/en/blog/what-new-in-pipedv1.md b/docs/content/en/blog/what-new-in-pipedv1.md index 4af0c3089b..167e7f360a 100644 --- a/docs/content/en/blog/what-new-in-pipedv1.md +++ b/docs/content/en/blog/what-new-in-pipedv1.md @@ -1,7 +1,7 @@ --- date: 2025-09-02 title: "What is new in pipedv1 (plugin-arch piped)" -linkTitle: "what is new in pipedv1" +linkTitle: "What is new in pipedv1" weight: 979 description: "" author: Khanh Tran ([@khanhtc1202](https://github.com/khanhtc1202)) @@ -27,6 +27,89 @@ Fundamental changes like pipedv1 being able to support different platforms and m ## New in pipedv1 +### `plugins` configurations + +From pipedv1, plugin binaries will be the real executor that perform pipeline's stages execution. +Plugin configuration is placed in 2 locations: __piped config__ and __application config__. + +The __piped config__ is where basic plugin configurations are stored, such as where to load the plugin binary or some configurations that can be shared between applications. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Piped +spec: + projectID: dev + pipedID: xxx + ... + plugins: + - name: kubernetes + port: 7001 + url: https://github.com/pipe-cd/pipecd/releases/download/link-to-plugin + deployTargets: + - name: local + config: + kubectlVersion: 1.32.4 + - name: remote + config: + kubectlVersion: 1.33.0 + - name: wait + port: 7002 + url: https://github.com/pipe-cd/pipecd/releases/download/link-to-plugin +``` + +NOTE: `platformProviders` and `cloudProviders` in piped config will not be available in pipedv1 config. Instead, the `deployTargets` configuration in plugin config will determine where to deploy your application resources. + +Meanwhile, the __application config__ is where plugin configurations are stored specifically for the deployment of that application. + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + labels: + env: local + planner: + alwaysUsePipeline: true + pipeline: + - name: K8S-SYNC + plugins: + kubernetes: + input: + kubectlVersion: 1.33.0 + quickSync: + prune: true +``` + +Pipedv1 automatically identifies plugins based on the stage defined in the pipeline configuration. Which means below application config is valid as well + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-app + labels: + env: local + pipeline: + - name: K8S-SYNC +``` + +For applications config without a pipeline definition, `plugins` config is required to help piped infer the plugin needed while performing deployment + +```yaml +apiVersion: pipecd.dev/v1beta1 +kind: Application +spec: + name: test-k8s-app + labels: + env: local + plugins: + kubernetes: +``` + +NOTE: `kind: XXXApp` is deprecated in pipedv1, `kind: Application` will be used for all applications in app configuration file for pipedv1 managed application. + +__Migrating application configs to the new format will be covered in detail in another blog__. You can learn more about the migration flow for now please check out [the migration issue](https://github.com/pipe-cd/pipecd/issues/5542#issuecomment-3223865130). + ### Pipeline planning and configuration Creating pipelines based on different deployment strategies for various specific applications is a strong point that makes PipeCD stand out. With pipedv1, this feature is further enhanced by solving some old limitations in the current piped. @@ -102,21 +185,31 @@ spec: ## Deprecated / Dis-supported features -### "Weird" flag in piped execution +### "Weird" flag `--enable-default-kubernetes-cloud-provider` in piped execution -A long-time "weird" flag for piped binary execution if you don't use PipeCD for a Kubernetes application is `--enable-default-kubernetes-cloud-provider`, which is basically legacy due to the first implementation of PipeCD focusing on supporting only Kubernetes. The default value is `false`, but if you set that flag to `true`, piped execution requires connecting to the Kubernetes cluster even before any application deployment is actually triggered. In pipedv1, nothing like that flag exists in piped execution because pipedv1 supports whatever platform its plugins support equally. +A long-time "weird" flag for piped binary execution if you don't use PipeCD for a Kubernetes application is `--enable-default-kubernetes-cloud-provider`, which is basically legacy due to the first implementation of PipeCD focusing on supporting only Kubernetes. The default value is `false`, but if you set that flag to `true`, piped execution requires connecting to the Kubernetes cluster even before any application deployment is actually triggered. + +In pipedv1, nothing like that flag exists in piped execution because pipedv1 supports whatever platform its plugins support equally. ### Kubernetes templating feature -Related to Kubernetes support features of PipeCD. Currently, piped supports the Helm Git Remote Chart feature (ref [piped config helm chart repository](https://pipecd.dev/docs-v0.53.x/user-guide/managing-piped/configuration-reference/#chartrepository)), which pulls the chart file stored directly on Git to the local and builds/templates as for a Local Chart. With the emergence and standardization of OCI, storing and sharing Helm Charts has become easier via the [Helm registry](https://helm.sh/docs/helm/helm_registry/). Therefore, in pipedv1, we decided to stop supporting this feature. +Related to Kubernetes support features of PipeCD. Currently, piped supports the Helm Git Remote Chart feature (ref [piped config helm chart repository](https://pipecd.dev/docs-v0.53.x/user-guide/managing-piped/configuration-reference/#chartrepository)), which pulls the chart file stored directly on Git to the local and builds/templates as for a Local Chart. + +With the emergence and standardization of OCI, storing and sharing Helm Charts has become easier via the [Helm registry](https://helm.sh/docs/helm/helm_registry/). Therefore, in pipedv1, we decided to stop supporting this feature. ### Analysis stage query templating feature Current piped support building queries used while evaluating metrics with deployment-specific data to be embedded in the analysis template (ref: [analysis templating docs](https://pipecd.dev/docs-v0.53.x/user-guide/managing-application/customizing-deployment/automated-deployment-analysis/#optional-analysis-template)). -From pipedv1, along with built-in and custom args are supported with placeholders as `{{ .App }}` and `{{ .AppCustomArgs }}` respectively, Kubernetes-specific built-in args like `{{ .K8s.Namespace }}` will be marked as deprecated and unsupported after several releases. The corresponding usage for the Kubernetes Namespace use case is changed to `{{ .AppCustomArgs.k8sNamespace }}`. +From pipedv1, along with built-in and custom args are supported with placeholders as `{{ .App }}` and `{{ .AppCustomArgs }}` respectively. + +Kubernetes-specific built-in args like `{{ .K8s.Namespace }}` will be marked as deprecated and unsupported after several releases. The corresponding usage for the Kubernetes Namespace use case is changed to `{{ .AppCustomArgs.k8sNamespace }}`. + +## Summary Here are some changes you might notice when switching to pipedv1. We ensure a certain level of backward compatibility between piped and pipedv1. The improvements are all aimed at making pipedv1 support more platforms and making it easier to build pipelines based on plugins. -The official documentation for pipedv1 is still being prepared, and the experimental release of pipedv1 will be available on the [official pipecd repo release tab](https://github.com/pipe-cd/pipecd/releases), along with some built-in plugins in the next few days. Thanks for your attention, cheer 🍻 +The official documentation for pipedv1 is still being prepared, and the experimental release of pipedv1 will be available on the [official pipecd repo release tab](https://github.com/pipe-cd/pipecd/releases), along with some built-in plugins in the next few days. + +Thanks for your attention, cheer 🍻