Release v0.56.0

RELEASE

@@ -1,6 +1,6 @@
 # Generated by `make release` command.
 # DO NOT EDIT.
-tag: v0.55.0
+tag: v0.56.0
 
 releaseNoteGenerator:
   showCommitter: false

docs/config.toml

@@ -169,6 +169,10 @@ no = 'Sorry to hear that. Please <a href="https://github.com/pipe-cd/pipecd/issu
   version = "v1.0.x"
   url = "/docs-v1.0.x/"
 
+[[params.versions]]
+  version = "v0.56.x"
+  url = "/docs-v0.56.x/"
+
 [[params.versions]]
   version = "v0.55.x"
   url = "/docs-v0.55.x/"

docs/content/en/docs-v0.56.x/_index.md

@@ -0,0 +1,5 @@
+---
+title: "Welcome to PipeCD"
+linkTitle: "Documentation [v0.56.x]"
+type: docs
+---

docs/content/en/docs-v0.56.x/concepts/_index.md

@@ -0,0 +1,75 @@
+---
+title: "Concepts"
+linkTitle: "Concepts"
+weight: 2
+description: >
+  This page describes several core concepts in PipeCD.
+---
+
+![](/images/architecture-overview.png)
+<p style="text-align: center;">
+Component Architecture
+</p>
+
+### Piped
+
+`piped` is a single binary component you run as an agent in your cluster, your local network to handle the deployment tasks.
+It can be run inside a Kubernetes cluster by simply starting a Pod or a Deployment.
+This component is designed to be stateless, so it can also be run in a single VM or even your local machine.
+
+### Control Plane
+
+A centralized component managing deployment data and provides gRPC API for connecting `piped`s as well as all web-functionalities of PipeCD such as
+authentication, showing deployment list/details, application list/details, delivery insights...
+
+### Project
+
+A project is a logical group of applications to be managed by a group of users.
+Each project can have multiple `piped` instances from different clouds or environments.
+
+There are three types of project roles:
+
+- **Viewer** has only permissions of viewing to deployment and application in the project.
+- **Editor** has all viewer permissions, plus permissions for actions that modify state such as manually trigger/cancel the deployment.
+- **Admin** has all editor permissions, plus permissions for managing project data, managing project `piped`.
+
+### Application
+
+A collection of resources (containers, services, infrastructure components...) and configurations that are managed together.
+PipeCD supports multiple kinds of applications such as `KUBERNETES`, `TERRAFORM`, `ECS`, `CLOUDRUN`, `LAMBDA`...
+
+### Application Configuration
+
+A YAML file that contains information to define and configure application.
+Each application requires one file at application directory stored in the Git repository.
+The default file name is `app.pipecd.yaml`.
+
+### Application Directory
+
+A directory in Git repository containing application configuration file and application manifests.
+Each application must have one application directory.
+
+### Deployment
+
+A deployment is a process that does transition from the current state (running state) to the desired state (specified state in Git) of a specific application.
+When the deployment is success, it means the running state is being synced with the desired state specified in the target commit.
+
+### Sync Strategy
+
+There are 3 strategies that PipeCD supports while syncing your application state with its configuration stored in Git. Which are:
+- Quick Sync: a fast way to make the running application state as same as its Git stored configuration. The generated pipeline contains only one predefined `SYNC` stage.
+- Pipeline Sync: sync the running application state with its Git stored configuration through a pipeline defined in its application configuration.
+- Sync: depends on your defined application configuration, `piped` will decide the best way to sync your application state with its Git stored configuration.
+
+### Platform Provider
+
+Note: The previous name of this concept was Cloud Provider.
+
+PipeCD supports multiple platforms and multiple kinds of applications.
+Platform Provider defines which platform, cloud and where application should be deployed to.
+
+Currently, PipeCD is supporting these five platform providers: `KUBERNETES`, `ECS`, `TERRAFORM`, `CLOUDRUN`, `LAMBDA`.
+
+### Analysis Provider
+An external product that provides metrics/logs to evaluate deployments, such as `Prometheus`, `Datadog`, `Stackdriver`, `CloudWatch` and so on.
+It is mainly used in the [Automated deployment analysis](../user-guide/managing-application/customizing-deployment/automated-deployment-analysis/) context.

docs/content/en/docs-v0.56.x/contribution-guidelines/_index.md

@@ -0,0 +1,7 @@
+---
+title: "Contribute"
+linkTitle: "Contribute"
+weight: 6
+description: >
+  This guide is for anyone who wants to contribute to the PipeCD project. We are so excited to have you!
+---

docs/content/en/docs-v0.56.x/contribution-guidelines/architectural-overview.md

@@ -0,0 +1,36 @@
+---
+title: "Architectural overview"
+linkTitle: "Architectural overview"
+weight: 3
+description: >
+  This page describes the architecture of PipeCD.
+---
+
+![](/images/architecture-overview.png)
+<p style="text-align: center;">
+Component Architecture
+</p>
+
+### Piped
+
+A single binary component runs in your cluster, your local network to handle the deployment tasks.
+It can be run inside a Kubernetes cluster by simply starting a Pod or a Deployment.
+This component is designed to be stateless, so it can also be run in a single VM or even your local machine.
+
+### Control Plane
+
+A centralized component manages deployment data and provides gRPC API for connecting `piped`s as well as all web-functionalities of PipeCD such as
+authentication, showing deployment list/details, application list/details, delivery insights...
+
+Control Plane contains the following components:
+- `server`: a service to provide api for piped, web and serve static assets for web.
+- `ops`: a service to provide administrative features for Control Plane owner like adding/managing projects.
+- `cache`: a redis cache service for caching internal data.
+- `datastore`: data storage for storing deployment, application data
+  - this can be a fully-managed service such as `Firestore`, `Cloud SQL`...
+  - or a self-managed such as `MySQL`
+- `filestore`: file storage for storing logs, application states
+  - this can a fully-managed service such as `GCS`, `S3`...
+  - or a self-managed service such as `Minio`
+
+For more information, see [Architecture overview of Control Plane](../../user-guide/managing-controlplane/architecture-overview/).

docs/content/en/docs-v0.56.x/contribution-guidelines/contributing-blogs.md

@@ -0,0 +1,107 @@
+---
+title: "Contribute to PipeCD Blogs"
+linkTitle: "Contribute to PipeCD Blogs"
+weight: 3
+description: >
+  This page describes how to contribute blog posts to PipeCD.
+---
+
+We welcome blog contributions from the community! Blog posts are a great way to share your experiences, tutorials, and insights about PipeCD with other users.
+
+## What makes a good blog post?
+
+Blog posts can cover a variety of topics, including:
+
+- **Announcements**: New features, releases, or project updates
+- **Tutorials**: Step-by-step guides on using PipeCD features
+- **Use cases**: How you or your organization uses PipeCD
+- **Best practices**: Tips and tricks for getting the most out of PipeCD
+- **Integrations**: How to integrate PipeCD with other tools
+
+## Where blog posts live
+
+Blog posts are located in the `/docs/content/en/blog/` directory within the [pipe-cd/pipecd repository](https://github.com/pipe-cd/pipecd).
+
+## Blog post format
+
+Each blog post is a Markdown file with YAML front matter. Here's the structure:
+
+```yaml
+---
+date: 2025-01-03
+title: "Your Blog Post Title"
+linkTitle: "Short Title for Navigation"
+weight: 980
+description: "A brief description of your post"
+author: Your Name ([@your-github-handle](https://github.com/your-github-handle))
+categories: ["Announcement"]
+tags: ["Tag1", "Tag2"]
+---
+
+Your content here...
+```
+
+### Front matter fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `date` | Yes | Publication date in `YYYY-MM-DD` format |
+| `title` | Yes | Full title of your blog post |
+| `linkTitle` | Yes | Shorter title used in navigation menus |
+| `weight` | Yes | Controls ordering (lower = newer, typically use ~980-990) |
+| `description` | No | Brief summary for SEO and previews |
+| `author` | Yes | Your name with GitHub profile link |
+| `categories` | Yes | One of: `Announcement`, `Tutorial`, `Release` |
+| `tags` | No | Relevant keywords for your post |
+
+### Content guidelines
+
+- Use clear, concise language
+- Include code examples where appropriate (use fenced code blocks with language identifiers)
+- Add images to `/docs/static/images/` and reference them as `![alt text](/images/your-image.png)`
+- Structure your post with headings (`##`, `###`) for readability
+- Include a conclusion or summary section
+
+## How to submit your blog post
+
+1. **Fork and clone** the [pipecd repository](https://github.com/pipe-cd/pipecd)
+
+2. **Create a branch** for your blog post:
+   ```bash
+   git checkout -b blog/your-post-title
+   ```
+
+3. **Create your blog post** file in `/docs/content/en/blog/`:
+   ```bash
+   touch docs/content/en/blog/your-post-title.md
+   ```
+
+4. **Add any images** to `/docs/static/images/`
+
+5. **Preview locally** by running:
+   ```bash
+   make run/site
+   ```
+   Then visit `http://localhost:1313/blog/` to see your post.
+
+6. **Commit and push** your changes:
+   ```bash
+   git add .
+   git commit -s -m "blog: add post about your-topic"
+   git push origin blog/your-post-title
+   ```
+
+7. **Open a Pull Request** against the `master` branch
+
+## Review process
+
+A maintainer will review your blog post for:
+
+- Technical accuracy
+- Clarity and readability
+- Adherence to the format guidelines
+- Appropriate use of images and code examples
+
+Feel free to reach out on the [#pipecd Slack channel](https://cloud-native.slack.com/) if you have questions or want feedback on your draft before submitting.
+
+Thank you for contributing to the PipeCD blog!

docs/content/en/docs-v0.56.x/contribution-guidelines/contributing-documentation.md

@@ -0,0 +1,40 @@
+---
+title: "Contribute to PipeCD Documentation"
+linkTitle: "Contribute to PipeCD Documentation"
+description: >
+  This page describes how to contribute to the PipeCD Documentation.
+---
+
+Welcome! We are so happy you're interested in helping improve our documentation. Your contributions make the project better for everyone.
+
+This guide explains how you can contribute to the PipeCD Documentation, which resides on our official website, https://pipecd.dev.
+
+## Where to find the docs
+
+Our documentation is located in the `/docs` folder within the [pipe-cd/pipecd repository](https://github.com/pipe-cd/pipecd).
+
+The content files are written in Markdown and live inside `/docs/content/en/`. You'll notice two types of documentation folders:
+
+* `/docs-dev/`: This is for documentation related to unreleased, in-development features.
+* `/docs-v0.x.x/` (and `/docs-v1.0.x/`): These folders contain the documentation for specific released versions of PipeCD.
+
+## How to build the docs locally
+
+To preview your changes as you work, you must run the documentation website on your local machine.
+
+1.  **Install Prerequisite:** You must have the **extended** version of [Hugo (v0.92.1 or higher)](https://gohugo.io/getting-started/installing/) installed.
+2.  **Run the Server:** From the root of the `pipecd` repository, run the following command:
+    ```bash
+    make run/site
+    ```
+3.  **Preview:** Open your browser and go to `http://localhost:1313` to see the live-reloading site.
+
+## How to submit your changes (The PR Process)
+
+1.  **Create a Branch:** Create a new branch for your changes (e.g., `git checkout -b my-docs-fix`).
+2.  **Make Your Changes:** Edit the necessary documentation files. If you are fixing an issue in the current documentation, remember to edit the file in both the `/docs-dev/` and the latest `/docs-vx.y.z/` folders.
+3.  **Commit and Push:** Commit your changes with a clear message and push your branch to your fork.
+4.  **Open a Pull Request:** Go to the PipeCD repository and open a Pull Request. In the description, please link to the issue you are fixing (e.g., `Addresses #6124`).
+5.  **Review:** A maintainer will review your PR, provide feedback, and merge it.
+
+Thank you for contributing!