diff --git a/docs/content/en/docs-dev/user-guide/managing-application/configuration-drift-detection.md b/docs/content/en/docs-dev/user-guide/managing-application/configuration-drift-detection.md index 6090abf7f5..0e18a1e13c 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/configuration-drift-detection.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/configuration-drift-detection.md @@ -46,7 +46,7 @@ The details shows why the application is in OUT_OF_SYNC state ###### DEPLOYING -This status means the application is deploying and the configuration drift detection is not running a white. Whenever a new deployment of the application was started, the detection process will temporarily be stopped until that deployment finishes and will be continued after that. +This status means the application is deploying and the configuration drift detection is not running for a while. Whenever a new deployment of the application is started, the detection process will temporarily be stopped until that deployment finishes and will be continued after that. ### How to enable diff --git a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-manual-approval.md b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-manual-approval.md index 3ee946b5fd..c0ad5f9460 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-manual-approval.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-manual-approval.md @@ -8,7 +8,7 @@ description: > While deploying an application to production environments, some teams require manual approvals before continuing. The manual approval stage enables you to control when the deployment is allowed to continue by requiring a specific person or team to approve. -This stage is named by `WAIT_APPROVAL` and you can add it to your pipeline before some stages should be approved before they can be executed. +This stage is named `WAIT_APPROVAL` and you can add it to your pipeline before some stages that should be approved before they can be executed. ``` yaml apiVersion: pipecd.dev/v1beta1 diff --git a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-wait-stage.md b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-wait-stage.md index f2d381d8f8..7808cf148c 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-wait-stage.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-wait-stage.md @@ -6,8 +6,8 @@ description: > This page describes how to add a WAIT stage. --- -In addition to waiting for approvals from someones, the deployment pipeline can be configured to wait an amount of time before continuing. -This can be done by adding the `WAIT` stage into the pipeline. This stage has one configurable field is `duration` to configure how long should be waited. +In addition to waiting for approvals from someone, the deployment pipeline can be configured to wait an amount of time before continuing. +This can be done by adding the `WAIT` stage into the pipeline. This stage has one configurable field, `duration`, to configure how long it should wait. ``` yaml apiVersion: pipecd.dev/v1beta1 diff --git a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/script-run.md b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/script-run.md index 69f0e20485..6811282691 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/script-run.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/script-run.md @@ -49,7 +49,7 @@ spec: ``` You can define the command as `run`. -Also, if you want to some values as variables, you can define them as `env`. +Also, if you want to use some values as variables, you can define them as `env`. The commands run in the directory where this application configuration file exists. diff --git a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/cloudrun.md b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/cloudrun.md index e2a2322c0e..cd07d50a1a 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/cloudrun.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/cloudrun.md @@ -8,7 +8,7 @@ description: > *Note: Cloud Run job has not been supported yet.* -Deploying a Cloud Run application requires a `service.yaml` file placing inside the application directory. That file contains the service specification used by Cloud Run as following: +Deploying a Cloud Run application requires a `service.yaml` file placed inside the application directory. That file contains the service specification used by Cloud Run as follows: ``` yaml apiVersion: serving.knative.dev/v1 @@ -42,7 +42,7 @@ Quick sync for a Cloud Run deployment will roll out the new version and switch a ## Sync with the specified pipeline The [pipeline](../../../configuration-reference/#cloud-run-application) field in the application configuration is used to customize the way to do the deployment. -You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic. +You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic. These are the provided stages for Cloud Run application you can use to build your pipeline: diff --git a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/ecs.md b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/ecs.md index bf6c6001a2..35a7b2b270 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/ecs.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/ecs.md @@ -79,7 +79,7 @@ spec: ## Sync with the specified pipeline The [pipeline](../../../configuration-reference/#ecs-application) field in the application configuration is used to customize the way to do the deployment. -You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic. +You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic. These are the provided stages for ECS application you can use to build your pipeline: diff --git a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/kubernetes.md b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/kubernetes.md index 8669874db1..59c6026ffe 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/kubernetes.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/kubernetes.md @@ -15,7 +15,7 @@ You can generate an application config file easily and interactively by [`pipect ## Quick sync -Quick sync is a fast way to sync application to the state specified in the target Git commit without any progressive strategy. It just applies all the defined manifiests to sync the application. +Quick sync is a fast way to sync application to the state specified in the target Git commit without any progressive strategy. It just applies all the defined manifests to sync the application. The quick sync will be planned in one of the following cases: - no pipeline was specified in the application configuration file - [pipeline](../../../configuration-reference/#pipeline) was specified but the PR did not make any changes on workload (e.g. Deployment's pod template) or config (e.g. ConfigMap, Secret) diff --git a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/lambda.md b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/lambda.md index d6bf0a15e8..d6b1fa1c76 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/lambda.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/lambda.md @@ -6,7 +6,7 @@ description: > Specific guide to configuring deployment for Lambda application. --- -Deploying a Lambda application requires a `function.yaml` file placing inside the application directory. That file contains values to be used to deploy Lambda function on your AWS cluster. +Deploying a Lambda application requires a `function.yaml` file placed inside the application directory. That file contains values to be used to deploy Lambda function on your AWS cluster. Currently, Piped supports deploying all types of Lambda deployment packages: - container images (called [container image as Lambda function](https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/)) - `.zip` file archives (which stored in AWS S3) @@ -119,7 +119,7 @@ Quick sync for a Lambda deployment will roll out the new version and switch all ## Sync with the specified pipeline The [pipeline](../../../configuration-reference/#lambda-application) field in the application configuration is used to customize the way to do the deployment. -You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic. +You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic. These are the provided stages for Lambda application you can use to build your pipeline: diff --git a/docs/content/en/docs-dev/user-guide/managing-application/deployment-chain.md b/docs/content/en/docs-dev/user-guide/managing-application/deployment-chain.md index 052a539234..c14584ad06 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/deployment-chain.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/deployment-chain.md @@ -48,10 +48,10 @@ See [Examples](../../examples/#deployment-chain) for more specific. ## Deployment chain characteristic -Something you need to care about while creating your deployment chain with PipeCD +Something you need to be aware of while creating your deployment chain with PipeCD: -1. The deployment chain blocks are run in sequence, one by one. But all nodes in the same block are run in parallel, you should ensure that all nodes(deployments) in the same block do not depend on each other. -2. Once a node in a block has finished with `FAILURE` or `CANCELLED` status, the containing block will be set to fail, and all other nodes which have not yet finished will be set to `CANCELLED` status (those nodes will be rolled back if they're in the middle of its deploying process). Consequently, all blocks after that failed block will be set to `CANCELLED` status and be stopped. +1. The deployment chain blocks are run in sequence, one by one. But all nodes in the same block are run in parallel, you should ensure that all nodes (deployments) in the same block do not depend on each other. +2. Once a node in a block has finished with `FAILURE` or `CANCELLED` status, the containing block will be set to fail, and all other nodes which have not yet finished will be set to `CANCELLED` status (those nodes will be rolled back if they're in the middle of their deploying process). Consequently, all blocks after that failed block will be set to `CANCELLED` status and be stopped. ## Console view diff --git a/docs/content/en/docs-dev/user-guide/managing-application/rolling-back-a-deployment.md b/docs/content/en/docs-dev/user-guide/managing-application/rolling-back-a-deployment.md index 4997f41bb5..4b1523abc8 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/rolling-back-a-deployment.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/rolling-back-a-deployment.md @@ -7,7 +7,7 @@ description: > --- Rolling back a deployment can be automated by enabling the `autoRollback` field in the application configuration of the application. When `autoRollback` is enabled, the deployment will be rolled back if any of the following conditions are met: -- a stage of the deployment pipeline was failed +- a stage of the deployment pipeline has failed - an analysis stage determined that the deployment had a negative impact - any error occurs while deploying diff --git a/docs/content/en/docs-dev/user-guide/managing-application/secret-management.md b/docs/content/en/docs-dev/user-guide/managing-application/secret-management.md index d29cde34aa..107ad51092 100755 --- a/docs/content/en/docs-dev/user-guide/managing-application/secret-management.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/secret-management.md @@ -6,7 +6,7 @@ description: > Storing secrets safely in the Git repository. --- -When doing GitOps, user wants to use Git as a single source of truth. But storing credentials like Kubernetes Secret or Terraform's credentials directly in Git is not safe. +When doing GitOps, users want to use Git as a single source of truth. But storing credentials like Kubernetes Secret or Terraform's credentials directly in Git is not safe. This feature helps you keep that sensitive information safely in Git, right next to your application manifests. Basically, the flow will look like this: @@ -88,7 +88,7 @@ Any file in the application directory can use `.encryptedSecrets` context to acc For example, -- Accessing by a Kubernets Secret manfiest +- Accessing by a Kubernetes Secret manifest ``` yaml apiVersion: v1 @@ -99,7 +99,7 @@ data: password: "{{ .encryptedSecrets.password }}" ``` -- Configuring ENV variable of a Lambda function to use a encrypted secret +- Configuring ENV variable of a Lambda function to use an encrypted secret ``` yaml apiVersion: pipecd.dev/v1beta1 @@ -110,7 +110,7 @@ spec: KEY: "{{ .encryptedSecrets.key }}" ``` -In all cases, `Piped` will decrypt the encrypted secrets and render the decryption target files before using to handle any deployment tasks. +In all cases, `Piped` will decrypt the encrypted secrets and render the decryption target files before using them to handle any deployment tasks. ## Examples diff --git a/docs/content/en/docs-dev/user-guide/managing-application/triggering-a-deployment.md b/docs/content/en/docs-dev/user-guide/managing-application/triggering-a-deployment.md index 3fcb5559ab..d667c984e7 100644 --- a/docs/content/en/docs-dev/user-guide/managing-application/triggering-a-deployment.md +++ b/docs/content/en/docs-dev/user-guide/managing-application/triggering-a-deployment.md @@ -22,9 +22,9 @@ Configuration for the trigger used to determine whether we trigger a new deploym See [Configuration Reference](../../configuration-reference/#deploymenttrigger) for the full configuration. -After a new deployment was triggered, it will be queued to handle by the appropriate `piped`. And at this time the deployment pipeline was not decided yet. +After a new deployment is triggered, it will be queued to be handled by the appropriate `piped`. At this time, the deployment pipeline has not been decided yet. `piped` schedules all deployments of applications to ensure that for each application only one deployment will be executed at the same time. -When no deployment of an application is running, `piped` picks queueing one to plan the deploying pipeline. +When no deployment of an application is running, `piped` picks a queued one to plan the deploying pipeline. `piped` plans the deploying pipeline based on the application configuration and the diff between the running state and the specified state in the newest commit. For example: @@ -33,7 +33,7 @@ For example: You can force `piped` planner to decide to use the [QuickSync](../../../concepts/#sync-strategy) or the specified pipeline based on the commit message by configuring [CommitMatcher](../../configuration-reference/#commitmatcher) in the application configuration. -After being planned, the deployment will be executed as the decided pipeline. The deployment execution including the state of each stage as well as their logs can be viewed in realtime at the deployment details page. +After being planned, the deployment will be executed as the decided pipeline. The deployment execution including the state of each stage as well as their logs can be viewed in real time on the deployment details page. 
diff --git a/docs/content/en/docs-dev/user-guide/managing-controlplane/adding-a-project.md b/docs/content/en/docs-dev/user-guide/managing-controlplane/adding-a-project.md
index e162c6adf5..962d2472f4 100644
--- a/docs/content/en/docs-dev/user-guide/managing-controlplane/adding-a-project.md
+++ b/docs/content/en/docs-dev/user-guide/managing-controlplane/adding-a-project.md
@@ -8,7 +8,7 @@ description: >
The control plane ops can add a new project for a team.
Project adding can be simply done from an internal web page prepared for the ops.
-Because that web service is running in an `ops` pod, so in order to access it, using `kubectl port-forward` command to forward a local port to a port on the `ops` pod as following:
+Because that web service is running in an `ops` pod, in order to access it, use the `kubectl port-forward` command to forward a local port to a port on the `ops` pod as follows:
``` console
kubectl port-forward service/pipecd-ops 9082 --namespace={NAMESPACE}
@@ -21,4 +21,4 @@ Registering a new project requires only a unique ID string and an optional descr
Once a new project has been registered, a static admin (username, password) will be automatically generated for the project admin. You can send that information to the project admin. The project admin first uses the provided static admin information to log in to PipeCD. After that, they can change the static admin information, configure the SSO, RBAC or disable static admin user.
-__Caution:__ The Role-Based Access Control (RBAC) setting is required to enable your team login using SSO, please make sure you have that setup before disable static admin user.
\ No newline at end of file
+__Caution:__ The Role-Based Access Control (RBAC) setting is required to enable your team to log in using SSO. Please make sure you have that set up before disabling the static admin user.
\ No newline at end of file
diff --git a/docs/content/en/docs-dev/user-guide/managing-controlplane/auth.md b/docs/content/en/docs-dev/user-guide/managing-controlplane/auth.md
index 2e2f5b4ae5..d8478619a6 100644
--- a/docs/content/en/docs-dev/user-guide/managing-controlplane/auth.md
+++ b/docs/content/en/docs-dev/user-guide/managing-controlplane/auth.md
@@ -44,8 +44,8 @@ PipeCD supports any OIDC provider, with tested providers including Keycloak, Aut
Requirements and Troubleshooting:
- The OIDC provider must provide claims for user's roles and username.
-- Roles claim value must use same values as pre-configured project RBAC Roles.
-- - Claims can be retreived from the IdToken or UserInfo endpoint. The UserInfo endpoint will be used if issuer supports it.
+- Roles claim value must use the same values as pre-configured project RBAC Roles.
+- Claims can be retrieved from the IdToken or UserInfo endpoint. The UserInfo endpoint will be used if the issuer supports it.
- You can use set a custom claim key name for roles and username in the OIDC provider. Using `usernameClaimKey` and `rolesClaimKey` in the configuration. If not set, the default value will be chosen in the following order:
- Supported Claims Key for Username (in order of priority): `username`, `preferred_username`,`name`, `cognito:username`
diff --git a/docs/content/en/docs-dev/user-guide/managing-controlplane/registering-a-piped.md b/docs/content/en/docs-dev/user-guide/managing-controlplane/registering-a-piped.md
index 9719f26f8d..585b0854f4 100644
--- a/docs/content/en/docs-dev/user-guide/managing-controlplane/registering-a-piped.md
+++ b/docs/content/en/docs-dev/user-guide/managing-controlplane/registering-a-piped.md
@@ -6,7 +6,7 @@ description: >
This page describes how to register a new piped to a project.
---
-The list of pipeds are shown in the Settings page. Anyone who has the project admin role can register a new piped by clicking on the `+ADD` button.
+The list of pipeds is shown on the Settings page. Anyone who has the project admin role can register a new piped by clicking on the `+ADD` button.
diff --git a/docs/content/en/docs-dev/user-guide/managing-piped/adding-a-git-repository.md b/docs/content/en/docs-dev/user-guide/managing-piped/adding-a-git-repository.md
index 97bf68b200..47625d7de0 100644
--- a/docs/content/en/docs-dev/user-guide/managing-piped/adding-a-git-repository.md
+++ b/docs/content/en/docs-dev/user-guide/managing-piped/adding-a-git-repository.md
@@ -6,10 +6,10 @@ description: >
This page describes how to add a new Git repository.
---
-In the `piped` configuration file, we specify the list of Git repositories should be handled by the `piped`.
-A Git repository contains one or more deployable applications where each application is put inside a directory called as [application directory](../../../concepts/#application-directory).
+In the `piped` configuration file, we specify the list of Git repositories that should be handled by the `piped`.
+A Git repository contains one or more deployable applications where each application is put inside a directory called the [application directory](../../../concepts/#application-directory).
That directory contains an application configuration file as well as application manifests.
-The `piped` periodically checks the new commits and fetches the needed manifests from those repositories for executing the deployment.
+The `piped` periodically checks for new commits and fetches the needed manifests from those repositories for executing the deployment.
A single `piped` can be configured to handle one or more Git repositories.
In order to enable a new Git repository, let's add a new [GitRepository](../configuration-reference/#gitrepository) block to the `repositories` field in the `piped` configuration file.
diff --git a/docs/content/en/docs-dev/user-guide/managing-piped/configuring-event-watcher.md b/docs/content/en/docs-dev/user-guide/managing-piped/configuring-event-watcher.md
index 1a7b0ae10c..513a988bad 100644
--- a/docs/content/en/docs-dev/user-guide/managing-piped/configuring-event-watcher.md
+++ b/docs/content/en/docs-dev/user-guide/managing-piped/configuring-event-watcher.md
@@ -13,7 +13,7 @@ The [SSH key used by Piped](../configuration-reference/#git) must be a key with
### Specify Git repositories to be observed
Piped watches events only for the Git repositories specified in the `gitRepos` list.
-You need to add all repositories you want to enable Eventwatcher.
+You need to add all repositories you want to enable EventWatcher.
```yaml
apiVersion: pipecd.dev/v1beta1
@@ -26,12 +26,12 @@ spec:
- repoId: repo-3
```
-### [optional] Specify Eventwatcher files Piped will use
+### [optional] Specify EventWatcher files Piped will use
>NOTE: This way is valid only for defining events using [.pipe/](../../event-watcher/#use-the-pipe-directory).
If multiple Pipeds handle a single repository, you can prevent conflicts by splitting into the multiple EventWatcher files and setting `includes/excludes` to specify the files that should be monitored by this Piped.
-Say for instance, if you only want the Piped to use the Eventwatcher files under `.pipe/dev/`:
+Say for instance, if you only want the Piped to use the EventWatcher files under `.pipe/dev/`:
```yaml
apiVersion: pipecd.dev/v1beta1
diff --git a/docs/content/en/docs-dev/user-guide/terraform-provider-pipecd.md b/docs/content/en/docs-dev/user-guide/terraform-provider-pipecd.md
index 5e62f0154b..adcf41e792 100644
--- a/docs/content/en/docs-dev/user-guide/terraform-provider-pipecd.md
+++ b/docs/content/en/docs-dev/user-guide/terraform-provider-pipecd.md
@@ -12,7 +12,7 @@ This provider enables us to add, update, and delete PipeCD resources as Infrast
## Usage
### Setup Terraform provider
-Add terraform block to declare that you use PipeCD Terraform provider. You need to input a controle plane's host name and API key via provider settings or environment variables. API key is available on the web UI.
+Add terraform block to declare that you use PipeCD Terraform provider. You need to input a control plane's host name and API key via provider settings or environment variables. API key is available on the web UI.
```hcl
terraform {