Merge branch 'master' into feat/add-dependabot-govulncheck

Signed-off-by: Mohammed Firdous <124298708+mohammedfirdouss@users.noreply.github.com>

Author: mohammedfirdouss

.github/workflows/first-time-contributor.yaml

@@ -36,18 +36,49 @@ jobs:
               return;
             }
 
-            const body = [
-              `👋 Hi @${prAuthor}, thanks for opening your first pull request to **PipeCD**!`,
-              '',
-              'Here are a few helpful resources to get started:',
-              '-  Contributing guide: `CONTRIBUTING.md`',
-              '-  Common commands:',
-              '  - `make test`',
-              '  - `make lint`',
-              '',
-              'If you have any questions, feel free to ask in this PR.',
-              'Thanks for contributing!'
-            ].join('\n');
+            const body = `👋 Hi @${prAuthor}, welcome to **PipeCD** and thanks for opening your first pull request!
+
+We’re really happy to have you here 🚀  
+Before your PR gets merged, please check a few important things below.
+
+---
+
+### Helpful resources
+- Contributing guide: https://github.com/pipe-cd/pipecd/blob/master/CONTRIBUTING.md
+- Development setup: https://github.com/pipe-cd/pipecd/blob/master/CONTRIBUTING.md#development
+
+---
+
+### DCO Sign-off
+All commits must include a \`Signed-off-by\` line to comply with the Developer Certificate of Origin (DCO).
+
+For the last commit:
+\`\`\`bash
+git commit --amend --signoff
+git push --force-with-lease
+\`\`\`
+
+For multiple commits:
+\`\`\`bash
+git rebase --signoff origin/master
+git push --force-with-lease
+\`\`\`
+
+---
+
+### Run checks locally
+\`\`\`bash
+make check
+\`\`\`
+
+---
+
+### 💬 Need help?
+Feel free to ask in this PR or join **#pipecd** on CNCF Slack:  
+https://communityinviter.com/apps/cloud-native/cncf
+
+Thanks for contributing to PipeCD! ❤️
+`;
 
             await github.rest.issues.createComment({
               owner,

CODEOWNERS

@@ -3,3 +3,6 @@
 
 # Web dir
 /web/ @pipe-cd/pipecd-approvers-web @pipe-cd/pipecd-approvers
+
+# Docs dir
+/docs/ @pipe-cd/pipecd-approvers-docs @pipe-cd/pipecd-approvers

MAINTAINERS.md

@@ -7,6 +7,7 @@
 | Yoshiki Fujikane        | [@ffjlabo](https://github.com/ffjlabo)           | ffjlabo@gmail.com                            |
 | Shinnosuke Sawada-Dazai | [@Warashi](https://github.com/Warashi)           | shin@warashi.dev                             |
 | Tetsuya Kikuchi         | [@t-kikuc](https://github.com/t-kikuc)           | tkikuchi07f@gmail.com                        |
+| Eeshaan Sawant          | [eeshaanSA](https://github.com/eeshaanSA)        | eeshaans1@gmail.com                          |
 
 
 E-mail addresses are expected to be used for reporting security issues. ref [SECURITY.md](./SECURITY.md) \

docs/config.toml

@@ -16,8 +16,6 @@ defaultContentLanguageInSubdir = false
 # Useful when translating.
 enableMissingTranslationPlaceholders = true
 
-disableKinds = ["taxonomy", "taxonomyTerm"]
-
 # Highlighting config
 pygmentsCodeFences = true
 pygmentsUseClasses = false

docs/content/en/blog/local-setup-contributor-guide.md

@@ -0,0 +1,137 @@
+---
+date: 2026-01-15
+title: "How to set up a local development environment"
+linkTitle: "How to set up a local development environment"
+weight: 990 
+author: Shivansh Sahu ([@shivansh-gohem](https://github.com/shivansh-gohem))
+categories: ["Tutorial", "Contributing"]
+tags: ["Local Development", "Go", "Kubernetes", "Dev Setup"]
+---
+
+
+## Why do you need a Local Development Environment?
+
+If you plan to contribute code, fix bugs, or add new plugins to PipeCD, you should run the control plane and Piped agent directly from the source code. This local development setup lets you test your Go changes live before submitting a pull request.
+
+This guide walks through building and running the components from source so you can iterate quickly and confidently.
+
+**Estimated setup time: 20–30 minutes**
+
+## Prerequisites
+
+Make sure you have the following installed and configured:
+
+- **Go** (v1.21 or higher)
+- **Docker**
+- **kubectl**
+- **Kind** (required to create the local cluster)
+- **Node.js and Yarn** (required to build the web UI)
+- **A fork of the PipeCD repository**
+
+To contribute to PipeCD, we recommend setting up a fork:
+
+1. Fork `pipe-cd/pipecd` on GitHub.  
+2. Clone your fork locally:
+```bash
+git clone https://github.com/<YOUR_USERNAME>/pipecd.git
+cd pipecd
+```
+## 1. Prepare and Start the Local Cluster
+
+This step prepares a local Kubernetes cluster and container registry required for running the PipeCD control plane locally.
+
+### Update dependencies
+
+Run these commands to ensure your local Go modules and web dependencies are up to date. Starting the environment may fail if these are outdated.
+```bash
+make update/go-deps
+make update/web-deps
+```
+
+### Start local registry and cluster
+
+A helper command starts a local kind cluster and a container registry. This command also automatically creates the `pipecd` namespace where the components will run.
+```bash
+make up/local-cluster
+```
+After the cluster starts, export the kubeconfig to ensure kubectl can communicate with it:
+
+```bash
+kind export kubeconfig --name pipecd
+```
+## 2. Run the PipeCD Control Plane (from source)
+
+The control plane provides the web UI, API, and metadata storage. Running it from source ensures you are testing your latest changes.
+
+### Start the control plane
+
+This command compiles the Go code, builds the web assets, and starts the control plane server locally.
+```bash
+make run/pipecd
+```
+### Access the UI
+
+Once the control plane is running, forward the port to access the UI from your browser. Open a new terminal and run:
+```bash
+kubectl port-forward -n pipecd svc/pipecd 8080
+```
+Then open your browser:
+
+- URL: <http://localhost:8080?project=quickstart>  
+- Username: `hello-pipecd`  
+- Password: `hello-pipecd`
+
+## 3. Configure and Run the Piped Agent (from source)
+
+The Piped agent connects the control plane to your local Kubernetes cluster. You will run this agent from source as well.
+
+### Register Piped in the UI
+
+1. Go to **Settings → Piped** (or open <http://localhost:8080/settings/piped?project=quickstart>).  
+2. Click **+ ADD**, give it a name (for example, `dev`), and save.  
+3. **Crucial step:** Copy the generated **Piped ID** and **Base64 encoded key** immediately.
+
+### Create the Piped configuration
+
+Create a file named `piped-config.yaml` in your repo root:
+```yaml
+apiVersion: pipecd.dev/v1beta1
+kind: Piped
+spec:
+  projectID: quickstart
+  # Replace here with your piped ID.
+  pipedID: <COPIED_PIPED_ID>
+  # Base64 encoded string of the piped private key.
+  # Replace here with your piped base64 key.
+  pipedKeyData: <COPIED_ENCODED_PIPED_KEY>
+  apiAddress: localhost:8080
+  repositories:
+  - repoId: example
+    remote: git@github.com:pipe-cd/examples.git
+    branch: master
+  syncInterval: 1m
+  platformProviders:
+  - name: example-kubernetes
+    type: KUBERNETES
+    config:
+      # Replace here with your kubeconfig absolute file path.
+      kubeConfigPath: /path/to/.kube/config
+```
+
+### Run Piped from source
+
+Use your local code and the config file you just created:
+```bash
+make run/piped CONFIG_FILE=piped-config.yaml INSECURE=true
+```
+
+## Cleaning Up
+
+To stop and remove the local cluster and registry when you are done, run:
+
+```bash
+make down/local-cluster
+```
+## Next Steps
+
+Once Piped starts and shows as connected in the UI, your local development environment is ready. You can now build and test your local changes.

docs/content/en/docs-v1.0.x/concepts/_index.md

@@ -14,13 +14,15 @@ Component Architecture
 
 ### Control Plane
 
-The Control Plane is the centralized management service of PipeCD. It coordinates all activities between users, projects, and piped instances.
+The Control Plane is the centralized management service of PipeCD. It coordinates all activities between users, projects, and `piped` instances.
 
 The Control Plane remains the backbone of the system but is now fully plugin-aware. Instead of directly handling deployment logic for specific platforms, it interacts with `piped` agents that run plugin binaries, allowing the Control Plane to manage deployments across any platform supported by plugins.
 
-### Piped
+For more detailed information about Control Plane architecture and components, see [Architecture overview of Control Plane](../user-guide/managing-controlplane/architecture-overview/).
 
-'`piped`' is a binary, agent component responsible for executing deployments in PipeCD. `Piped` now adopts **plugin-based** **architecture**, transforming from a single-purpose executor into a lightweight runtime capable of runnning any deployment logic defined by plugins. The `piped` component is designed to be stateless.
+### piped
+
+`piped` is a binary, agent component responsible for executing deployments in PipeCD. `piped` now adopts **plugin-based** **architecture**, transforming from a single-purpose executor into a lightweight runtime capable of running any deployment logic defined by plugins. The `piped` component is designed to be stateless.
 
 ### Plugins
 
@@ -48,7 +50,7 @@ Projects use role-based access control (RBAC) to manage permissions:
 
 - Viewer – can view applications and deployments within the project.
 - Editor – includes Viewer permissions and can perform actions that modify state, such as triggering or cancelling deployments.
-- Admin – includes Editor permissions and can manage project settings, members, and associated piped instances.
+- Admin – includes Editor permissions and can manage project settings, members, and associated `piped` instances.
 
 ### Application
 
@@ -82,6 +84,4 @@ Depending on your deployment workflow, you can choose from one of the following
 
 - Pipeline Sync: A customizable, step-by-step sync process that follows the pipeline you define in your application configuration file. Use Pipeline Sync when you need more control over how updates are rolled out.
 
-- Auto Sync: When you trigger a sync without specifying a strategy, piped automatically selects the most appropriate method based on your application configuration.
-
-Git stored configuration.
+- Auto Sync: When you trigger a sync without specifying a strategy, `piped` automatically selects the most appropriate method based on your application configuration.

docs/content/en/docs-v1.0.x/contribution-guidelines/architectural-overview.md

@@ -1,20 +1,20 @@
 ---
-title: "Migrate to PipeCD V1"
-linkTitle: "Migrate to PipeCD V1"
+title: "Migrate to PipeCD v1"
+linkTitle: "Migrate to PipeCD v1"
 weight: 90
 description: >
-  Documentation on migrating your application from PipeCD V0 to V1
+  Documentation on migrating your application from PipeCD v0 to v1
 ---
 
-This page explains how to safely migrate your existing PipeCD System to the RC version of **PipeCD V1**, the new plugin-based architecture that brings modularity and extensibility to PipeCD.
+This page explains how to safely migrate your existing PipeCD System to the RC version of **PipeCD v1**, the new plugin-based architecture that brings modularity and extensibility to PipeCD.
 
-Incase you are using PipeCD V0, follow the setps on this page to migrate to **PipeCD V1**.
+In case you are using PipeCD v0, follow the steps on this page to migrate to **PipeCD v1**.
 
 ## Overview
 
-PipeCD V1 introduces a **pluggable architecture** that allows developers to add and maintain custom deployment and operational plugins without modifying the core system of PipeCD.
+PipeCD v1 introduces a **pluggable architecture** that allows developers to add and maintain custom deployment and operational plugins without modifying the core system of PipeCD.
 
-Migration from v0 is designed to be **safe** and **incremental**, allowing you to switch to PipeCD V1 with minimal disruption.
+Migration from v0 is designed to be **safe** and **incremental**, allowing you to switch to PipeCD v1 with minimal disruption.
 
 ## Components
 
@@ -82,7 +82,7 @@ pipectl version
 >
 >You can check all releases on the [Pipecd Releases](https://github.com/pipe-cd/pipecd/releases) page.
 
-For more options of installing pipectl, checkout installing pipectl(link)
+For more options of installing pipectl, check out the [installing pipectl](https://pipecd.dev/docs-v1.0.x/user-guide/command-line-tool/) guide.
 
 ## 2. Convert Application Configurations to v1 Format
 
@@ -99,7 +99,7 @@ Or specify an entire directory:
 pipectl migrate application-config --dirs=path/to/apps/
 ```
 
-Here is an example for a simple app.pipecd.yaml file which demonstrates a kubernetes deployment and simulates a 30s wait:
+Here is an example for a simple app.pipecd.yaml file which demonstrates a Kubernetes deployment and simulates a 1m wait:
 
 ```yaml
 apiVersion: pipecd.dev/v1beta1
@@ -137,7 +137,7 @@ You’ll need an API key with write permission. Check:
 
 - [Generating an API key](https://pipecd.dev/docs/user-guide/command-line-tool/#authentication)
 
-After obtaining your API key, Run:
+After obtaining your API key, run:
 
 ```bash
 pipectl migrate database \
@@ -156,7 +156,7 @@ In pipedv1, **platform providers** have been replaced by **plugins**. Each plugi
 
 ### Example (Old piped config)
 
-Your exisiting `piped` config may look similar to the following:
+Your existing `piped` config may look similar to the following:
 
 ```yaml
 apiVersion: pipecd.dev/v1beta1
@@ -274,7 +274,7 @@ If your Control Plane is running locally, append the `--insecure=true` flag to s
 
 ### Option 3 - Run `pipedv1` as a Container
 
-In addtion to running piped using Helm or as a standalone binary, you can also run it as a container. This is useful for environments such as CloudRun, ECS Fargate or more.
+In addition to running piped using Helm or as a standalone binary, you can also run it as a container. This is useful for environments such as CloudRun, ECS Fargate or more.
 
 A prebuilt container image of `pipedv1` is available on GitHub Container Registry:
 
@@ -290,7 +290,7 @@ docker pull ghcr.io/pipe-cd/pipedv1-exp:<version>
 
 ## Want to switch back?
 
-If you need to roll back to using PipeCD V0, you can do so safely at any time.
+If you need to roll back to using PipeCD v0, you can do so safely at any time.
 
 Simply **stop** the running `pipedv1` instance, then **start** the `pipedv0` service as you normally would.