ci: format markdown files with prettier (envoyproxy#1290)

**Description**

Formats markdown files with go-prettier in `make format`

---------

Signed-off-by: Anuraag Agrawal <[email protected]>
Signed-off-by: Hrushikesh Patil <[email protected]>

Author: anuraaga

.editorconfig

@@ -5,3 +5,9 @@ charset = utf-8
 end_of_line = lf
 insert_final_newline = true
 trim_trailing_whitespace = true
+
+# Automatically formatted by prettier, which sometimes has trailing whitespace
+# in codeblocks. We don't need to check here since it's the formatting is checked
+# instead.
+[*.md]
+trim_trailing_whitespace = false

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,15 +1,16 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
+title: ""
 labels: enhancement,triage
-assignees: ''
-
+assignees: ""
 ---
 
-*Description*:
->Describe the desired behavior, what scenario it enables and how it
-would be used.
+_Description_:
+
+> Describe the desired behavior, what scenario it enables and how it
+> would be used.
 
 [optional *Relevant Links*:]
->Any extra documentation required to understand the issue.
+
+> Any extra documentation required to understand the issue.

.github/ISSUE_TEMPLATE/non--crash-security--bug.md

@@ -1,26 +1,29 @@
 ---
 name: Bug
 about: Bugs
-title: ''
+title: ""
 labels: bug,triage
-assignees: ''
-
+assignees: ""
 ---
 
-*Description*:
->What issue is being seen? Describe what should be happening instead of
-the bug, for example: Envoy should not crash, the expected value isn't
-returned, etc.
+_Description_:
+
+> What issue is being seen? Describe what should be happening instead of
+> the bug, for example: Envoy should not crash, the expected value isn't
+> returned, etc.
+
+_Repro steps_:
 
-*Repro steps*:
 > Include sample requests, environment, etc. All data and inputs
-required to reproduce the bug.
+> required to reproduce the bug.
+
+> **Note**: If there are privacy concerns, sanitize the data prior to
+> sharing.
+
+_Environment_:
 
->**Note**: If there are privacy concerns, sanitize the data prior to
-sharing.
+> Include the environment like gateway version, envoy version and so on.
 
-*Environment*:
->Include the environment like gateway version, envoy version and so on.
+_Logs_:
 
-*Logs*:
->Include the access logs and the Envoy logs.
+> Include the access logs and the Envoy logs.

.github/ISSUE_TEMPLATE/other.md

@@ -1,14 +1,15 @@
 ---
 name: Other
 about: Questions, design proposals, tech debt, etc.
-title: ''
+title: ""
 labels: triage
-assignees: ''
-
+assignees: ""
 ---
 
-*Description*:
->Describe the issue.
+_Description_:
+
+> Describe the issue.
 
 [optional *Relevant Links*:]
->Any extra documentation required to understand the issue.
+
+> Any extra documentation required to understand the issue.

CONTRIBUTING.md

@@ -5,9 +5,10 @@ We welcome contributions from the community. Please read the following guideline
 ## Local development of Envoy AI Gateway project
 
 First of all, there are only three minimal prerequisites to contribute to the project:
-* The latest Go toolchain
-* `make`
-* `docker`
+
+- The latest Go toolchain
+- `make`
+- `docker`
 
 which we assume you already have installed on your machine. Also, on macOS, you would need to install
 `brew install ca-certificates` to run some integration tests.
@@ -40,13 +41,13 @@ All test targets are prefixed with `test-*` and can be run via `make test-<targe
 Some test commands might require additional dependencies to be installed on your machine.
 For example,
 
-* The latest `kubectl` binary for running `make test-e2e`.
-  * See: https://kubernetes.io/docs/tasks/tools/
-* The latest `envoy` binary for running `make test-extproc`. The current required version is v1.35 or later.
-  * On Linux, you can download the latest Envoy binary as described in https://www.envoyproxy.io/docs/envoy/latest/start/install.
+- The latest `kubectl` binary for running `make test-e2e`.
+  - See: https://kubernetes.io/docs/tasks/tools/
+- The latest `envoy` binary for running `make test-extproc`. The current required version is v1.35 or later.
+  - On Linux, you can download the latest Envoy binary as described in https://www.envoyproxy.io/docs/envoy/latest/start/install.
     Alternatively, you can use `func-e` on Linux as well like on macOS below.
-  * On macOS, since `brew envoy` tends to behind the latest version, it is recommended use `func-e` to run the latest Envoy. See https://func-e.io/.
-  * `alias envoy='func-e run'` is a convenient way to run the latest Envoy binary via `func-e` on both macOS and Linux.
+  - On macOS, since `brew envoy` tends to behind the latest version, it is recommended use `func-e` to run the latest Envoy. See https://func-e.io/.
+  - `alias envoy='func-e run'` is a convenient way to run the latest Envoy binary via `func-e` on both macOS and Linux.
     For example, `func-e use 1.34` can be used to switch to a specific version of Envoy to be run with `func-e run`.
 
 Other than that, everything will be automatically managed and installed via `make` targets,
@@ -94,14 +95,14 @@ make sure that these automated checks pass after you open a PR by following the
 
 ### Code Reviews
 
-* During the review, address the comments and commit the changes
-**without squashing the commits, force pushing, or rebasing the branch**.
-This facilitates incremental reviews since the reviewer does not go through all the code again to find out
-what has changed since the last review. When a change goes out of sych with master, please use `git merge`
-to avoid force pushing.
-  * The only exception to this rule is when you mistakenly pushed a non-signoff commit.
+- During the review, address the comments and commit the changes
+  **without squashing the commits, force pushing, or rebasing the branch**.
+  This facilitates incremental reviews since the reviewer does not go through all the code again to find out
+  what has changed since the last review. When a change goes out of sych with master, please use `git merge`
+  to avoid force pushing.
+  - The only exception to this rule is when you mistakenly pushed a non-signoff commit.
     In this case, you can amend the commit with the signoff line and force push.
-* Commits are squashed prior to merging a pull request, using the title and PR description
-as commit message by default. Maintainers may request contributors to
-edit the pull request title and description to ensure that it remains descriptive as a
-commit message. Alternatively, maintainers may change the commit message directly at the time of merge.
+- Commits are squashed prior to merging a pull request, using the title and PR description
+  as commit message by default. Maintainers may request contributors to
+  edit the pull request title and description to ensure that it remains descriptive as a
+  commit message. Alternatively, maintainers may change the commit message directly at the time of merge.

GOALS.md

@@ -1,4 +1,3 @@
-
 # Envoy AI Gateway GOALS.md
 
 ## Envoy AI Gateway Goals
@@ -21,12 +20,12 @@ Envoy AI Gateway will simplify the process of setting up an AI Gateway to manage
 
 Envoy AI Gateway enables Platform Engineers to provide a Gateway solution that enables application developers to focus on leveraging GenAI for feature development.
 
-* **Preset Envoy Gateway Configurations:** Default configurations that simplify setup of routing to GenAI Services, making it accessible to application developers.
-* **Leveraging  Envoy:** The project aims to leverage the functionality of the Envoy Gateway control plane and the Envoy Proxy data plane.
+- **Preset Envoy Gateway Configurations:** Default configurations that simplify setup of routing to GenAI Services, making it accessible to application developers.
+- **Leveraging Envoy:** The project aims to leverage the functionality of the Envoy Gateway control plane and the Envoy Proxy data plane.
 
 ## Non-Objectives
 
-* **Disruption of Existing Envoy Patterns:** This project is an additive layer designed to expand use cases for Envoy Proxy and Envoy Gateway without changing existing deployment or control patterns.
+- **Disruption of Existing Envoy Patterns:** This project is an additive layer designed to expand use cases for Envoy Proxy and Envoy Gateway without changing existing deployment or control patterns.
 
 ## Personas
 

Makefile

@@ -74,6 +74,8 @@ format: ## Format the codebase.
 	@$(GO_TOOL) license-eye header fix
 	@echo "prettier => **.{yaml,yml}"
 	@$(GO_TOOL) prettier --write '**/*.{yaml,yml}'
+	@echo "prettier => **.md"
+	@$(GO_TOOL) prettier --write '**/*.md'
 
 # This runs go mod tidy on every module.
 .PHONY: tidy

README.md

@@ -1,12 +1,13 @@
 # Envoy AI Gateway
+
 Envoy AI Gateway is an open source project for using [Envoy Gateway](https://github.com/envoyproxy/gateway) to handle request traffic from application clients to Generative AI services.
 
 ## Usage
 
 When using Envoy AI Gateway, we refer to a two-tier gateway pattern. **The Tier One Gateway** functions as a centralized entry point, and the **Tier Two Gateway** handles ingress traffic to a self-hosted model serving cluster.
 
-+ The **Tier One Gateway** handles authentication, top-level routing, and global rate limiting
-+ The **Tier Two Gateway** provides fine-grained control over self-hosted model access, with endpoint picker support for LLM inference optimization.
+- The **Tier One Gateway** handles authentication, top-level routing, and global rate limiting
+- The **Tier Two Gateway** provides fine-grained control over self-hosted model access, with endpoint picker support for LLM inference optimization.
 
 ![](site/blog/images/aigw-ref.drawio.png)
 
@@ -85,17 +86,16 @@ Envoy AI Gateway supports a wide range of AI providers, making it easy to integr
   </table>
 </div>
 
-
 ## Documentation
 
-* [Blog](https://aigateway.envoyproxy.io/blog) introducing Envoy AI Gateway.
-* [Documentation](https://aigateway.envoyproxy.io/docs) for Envoy AI Gateway.
-* [Quickstart](https://aigateway.envoyproxy.io/docs/getting-started/) to use Envoy AI Gateway in a few simple steps.
-* [Concepts](https://aigateway.envoyproxy.io/docs/concepts/) to understand the architecture and resources of Envoy AI Gateway.
+- [Blog](https://aigateway.envoyproxy.io/blog) introducing Envoy AI Gateway.
+- [Documentation](https://aigateway.envoyproxy.io/docs) for Envoy AI Gateway.
+- [Quickstart](https://aigateway.envoyproxy.io/docs/getting-started/) to use Envoy AI Gateway in a few simple steps.
+- [Concepts](https://aigateway.envoyproxy.io/docs/concepts/) to understand the architecture and resources of Envoy AI Gateway.
 
 ## Contact
 
-* Slack: Join the [Envoy Slack workspace][] if you're not already a member. Otherwise, use the
+- Slack: Join the [Envoy Slack workspace][] if you're not already a member. Otherwise, use the
   [Envoy AI Gateway channel][] to start collaborating with the community.
 
 ## Get Involved
@@ -113,7 +113,6 @@ which includes information on how to build and test the project.
 
 The proposal of using Envoy Gateway as a [Cloud Native LLM Gateway][Cloud Native LLM Gateway] inspired the initiation of this project.
 
-
 [meeting]: https://docs.google.com/document/d/10e1sfsF-3G3Du5nBHGmLjXw5GVMqqCvFDqp_O65B0_w/edit?tab=t.0
 [Envoy Slack workspace]: https://communityinviter.com/apps/envoyproxy/envoy
 [Envoy AI Gateway channel]: https://envoyproxy.slack.com/archives/C07Q4N24VAA

RELEASES.md

@@ -20,18 +20,19 @@ This document focuses on compatibility concerns of those using Envoy AI Gateway.
 It is important to note that the support policy is subject to change at any time. The support policy is as follows:
 
 First of all, there are four areas of compatibility that we are concerned with:
-* [Using envoyproxy/ai-gateway as a Go package](#public-go-package).
-* [Deploying the Envoy AI Gateway controller through the Kubernetes Custom Resource Definition (CRD)](#Custom-Resource-Definitions).
-* [Upgrading the Envoy AI Gateway controller](#Upgrading-the-Envoy-AI-Gateway-controller).
-* [Envoy Gateway vs Envoy AI Gateway compatibility](#Envoy-Gateway-vs-Envoy-AI-Gateway-compatibility).
+
+- [Using envoyproxy/ai-gateway as a Go package](#public-go-package).
+- [Deploying the Envoy AI Gateway controller through the Kubernetes Custom Resource Definition (CRD)](#Custom-Resource-Definitions).
+- [Upgrading the Envoy AI Gateway controller](#Upgrading-the-Envoy-AI-Gateway-controller).
+- [Envoy Gateway vs Envoy AI Gateway compatibility](#Envoy-Gateway-vs-Envoy-AI-Gateway-compatibility).
 
 ### Public Go package
 
 Since we do not envision this repository ends up as a transitive dependency, i.e. only used as a direct dependency such as in a custom control plane, etc., we assume that any consumer of the project should have the full control over the source code depending on the project. This allows us to declare deprecation and introduce the breaking changes in the version after the next one since they can migrate the code at their discretion. For example, any public API that is marked as deprecated in the version N will be removed in the version N+2. We document how users should migrate to the new API will be documented in the release notes if applicable, but we do not guarantee that the migration path will be provided.
 
 ### Custom Resource Definitions
 
-The Custom Resource Definitions (CRDs) are defined in api/${version}/*.go files. The CRDs are versioned as v1alpha1, v1alpha2, etc.
+The Custom Resource Definitions (CRDs) are defined in api/${version}/\*.go files. The CRDs are versioned as v1alpha1, v1alpha2, etc.
 
 **For alpha versions**, we simply employ the same deprecation policy as the Go package. In other words, the APIs will be marked as deprecated in the version N and will be removed in the version N+2 but without any guarantee of migration path.
 
@@ -62,32 +63,34 @@ This section is for maintainers of the project. Let's say we are going to releas
 Each non-patch release should start with Release Candidate (RC) phase as follows:
 
 1. First, notify the community that we are going to cut the release candidate and therefore the main branch is frozen.
-  The main branch should only accept the bug fixes, the security fixes, and documentation changes.
-  The release candidate should always be cut from the main branch.
+   The main branch should only accept the bug fixes, the security fixes, and documentation changes.
+   The release candidate should always be cut from the main branch.
 
 2. Cut the request candidate tag from the main branch. The tag should be v0.50.0-rc1. Assuming the remote `origin` is the main envoyproxy/ai-gateway repository,
-  the command to cut the tag is:
-    ```
-    git fetch origin # make sure you have the latest main branch locally.
-    git tag v0.50.0-rc1 origin/main
-    git push origin v0.50.0-rc1
-    ```
+   the command to cut the tag is:
+
+   ```
+   git fetch origin # make sure you have the latest main branch locally.
+   git tag v0.50.0-rc1 origin/main
+   git push origin v0.50.0-rc1
+   ```
+
    Pushing a tag will trigger the pipeline to build the release candidate image and the helm chart tagged with the release candidate tag.
    The release candidate image will be available in the Docker Hub.
 
 3. The release candidate should be tested by the maintainers and the community. If there is any issue, the issue should be fixed in the main branch
-  and the new rc tag should be created. For example, if there is an issue in the release candidate v0.50.0-rc1, replace `v0.50.0-rc1` with `v0.50.0-rc2`
-  in the above command and repeat the process.
+   and the new rc tag should be created. For example, if there is an issue in the release candidate v0.50.0-rc1, replace `v0.50.0-rc1` with `v0.50.0-rc2`
+   in the above command and repeat the process.
 
 ### Release Phase
 
 1. Once the release candidate is stable, we will cut the release from the main branch, assuming that's exactly the same as the last release candidate.
-  The command to cut the release is exactly the same as the release candidate:
-    ```
-    git fetch origin # make sure you have the latest main branch locally.
-    git tag v0.50.0 origin/main
-    git push origin v0.50.0
-    ```
+   The command to cut the release is exactly the same as the release candidate:
+   ```
+   git fetch origin # make sure you have the latest main branch locally.
+   git tag v0.50.0 origin/main
+   git push origin v0.50.0
+   ```
    Pushing a tag will trigger the pipeline to build the release image and the helm chart tagged with the release tag.
    The release image will be available in the Docker Hub.
 2. The draft release note will be created in the GitHub repository after the pipeline is completed.
@@ -102,15 +105,15 @@ Each non-patch release should start with Release Candidate (RC) phase as follows
 2. Once the PR is merged, the maintainers will decide when to cut the patch release. There's no need to wait for multiple backports to cut the patch release, etc.
    Do not cut the tag until all CI passes on the release/v0.50 branch.
 3. The patch release should be cut from the `release/v0.50` branch. The command to cut the patch release is exactly the same as normal release:
-    ```
-    git fetch origin # make sure you have the latest release/v0.50 branch locally.
-    git tag v0.50.1 origin/release/v0.50
-    git push origin v0.50.1
-    ```
+   ```
+   git fetch origin # make sure you have the latest release/v0.50 branch locally.
+   git tag v0.50.1 origin/release/v0.50
+   git push origin v0.50.1
+   ```
    Pushing a tag will trigger the pipeline to build the patch release image and the helm chart tagged with the patch release tag.
    The patch release image will be available in the Docker Hub.
 4. The draft release note will be created in the GitHub repository after the pipeline is completed.
    Edit the release note nicely by hand to reflect the changes in the release.
 5. Update the documentation on the main branch to reflect the new version. This has the following items:
-   * Change `v0.50.0` to `v0.50.1` in site/versioned_docs/version-0.50 directory.
-   * Update the site/src/pages/release-notes.md to add the new release note.
+   - Change `v0.50.0` to `v0.50.1` in site/versioned_docs/version-0.50 directory.
+   - Update the site/src/pages/release-notes.md to add the new release note.