triggermesh · daceynolan · Nov 12, 2020 · Nov 11, 2020 · Nov 12, 2020
diff --git a/docs/apis/index.md b/docs/apis/index.md
@@ -11,5 +11,5 @@ Knative API is [documented at the project](https://knative.dev/docs/reference/ap
 ## TriggerMesh Targets API
 
 * [Triggermesh Targets](./private-targets.md).
-* [Triggermesh AWS Eventbridge target](./awseventbridge-target.md).
+* [Triggermesh AWS EventBridge target](./awseventbridge-target.md).
 
diff --git a/docs/apis/private-targets.md b/docs/apis/private-targets.md
@@ -1768,7 +1768,7 @@ OracleTargetStatus
 <h3 id="targets.triggermesh.io/v1alpha1.SendGridTarget">SendGridTarget
 </h3>
 <p>
-<p>SendGridTarget is the Schema for an Sendgrid Target.</p>
+<p>SendGridTarget is the Schema for an SendGrid Target.</p>
 </p>
 <table>
 <thead>

diff --git a/docs/guides/actions.md b/docs/guides/actions.md
@@ -45,7 +45,7 @@ Once executed, the _TaskRun_ view will show a green TaskRun object as below:
 
 ![](../images/taskrunshow.png)
 
-Clicking on the object name will lead you to the _Task Run Details_ here we can view our YAML as well as the Logs. Navigate to the logs to find the a magnificient `hello world`:
+Clicking on the object name will lead you to the _Task Run Details_ here we can view our YAML as well as the Logs. Navigate to the logs to find the a magnificent `hello world`:
 
 ![](../images/taskrunlogs.png)
 

diff --git a/docs/guides/bridge.md b/docs/guides/bridge.md
@@ -11,7 +11,7 @@ Each _bridge_ created within the TM console operates via the following `flow`:
 
   1. An event _*[source](https://knative.dev/docs/eventing/sources/)*_ **_retrieves_** data. <!-- Should link to OUR source docs upon their completion -->
   2. A _*[broker](https://knative.dev/docs/eventing/broker-trigger/)*_ to act as an **_event bucket_**
-  3. A _*[trigger](https://knative.dev/docs/eventing/broker-trigger/)*_ that **_subscribes_** the Target to recieve events from the broker.
+  3. A _*[trigger](https://knative.dev/docs/eventing/broker-trigger/)*_ that **_subscribes_** the Target to receive events from the broker.
   4. A _*target*_ that **_receives_** events. <!-- Should be linked to the ../targets/index.md  upon completion -->
 
 ![](../images/tmBridgeFlow.png)
@@ -42,7 +42,7 @@ For this example a small service called [Event Display](https://github.com/knati
 
 ![](../images/tmPingSource.png)
 
- Before configuring a _Bridge_, normally, a _Target_ would be created or pre-existing, because this example asumes a fresh TM console, There are no services currently deployed so a detour to the `Target` section is required.
+ Before configuring a _Bridge_, normally, a _Target_ would be created or pre-existing, because this example assumes a fresh TM console, There are no services currently deployed so a detour to the `Target` section is required.
  * Select `Service` here.
 
 ![](../images/tmAddTargets.png)
@@ -64,7 +64,7 @@ This will complete the flow from _Source_ to _Trigger_ automatically for us by c
 ![](../images/tmSubmitBridge.png)
 
 
-* To verify the functionality of the bridge, navigate to the [Servcies](https://cloud.triggermesh.io/services) section.
+* To verify the functionality of the bridge, navigate to the [Services](https://cloud.triggermesh.io/services) section.
 
 ![](../images/tmServicesViewBridges.png)
 

diff --git a/docs/guides/bridges/slack-to-confluent.md b/docs/guides/bridges/slack-to-confluent.md
@@ -48,7 +48,7 @@ Now click on the `Target` block at the bottom of the page, a list of targets to
 - Name of component at the bridge (your choice).
 - Bootstrap servers for your Confluent instance, at least one entry.
 - A topic to write to. If it doesn't exists the target will create it.
-- Username for the integraion.
+- Username for the integration.
 - The secret containing the password created at a previous step.
 
 ![Confluent target](../../images/slack-confluent-bridge/confluent-target.png)

diff --git a/docs/guides/cd.md b/docs/guides/cd.md
@@ -2,7 +2,7 @@
 
 
 
-The Triggermesh console provides an interface called [Repositories.](https://cloud.triggermesh.io/function-triggers) Here the user is able to select a codebase, from a linked repository provider, to be continuously deployed. This codebase **must** contain a deployment manifest[^1] .
+The TriggerMesh console provides an interface called [Repositories.](https://cloud.triggermesh.io/function-triggers) Here the user is able to select a codebase, from a linked repository provider, to be continuously deployed. This codebase **must** contain a deployment manifest[^1] .
 
 
 ## Register the Repository
@@ -56,7 +56,7 @@ The Triggermesh console provides an interface called [Repositories.](https://clo
 
 ## Service Creation
 
-* On successfull execution of the _Task_ the service will be available and you will be able to see and use the function by navigating to the [_Services_](https://cloud.triggermesh.io/services) tab.
+* On successful execution of the _Task_ the service will be available and you will be able to see and use the function by navigating to the [_Services_](https://cloud.triggermesh.io/services) tab.
 
 ![](../images/serviceview.png)
 

diff --git a/docs/sources/azureactivitylogs.md b/docs/sources/azureactivitylogs.md
@@ -55,7 +55,7 @@ The corresponding role JSON is given as a reference which you can replicate to c
 }
 ```
 
-After the Service Principal is created and assigned suitable roles, take note of the following three informations:
+After the Service Principal is created and assigned suitable roles, take note of the following information:
 
 * **Tenant ID** and **Client ID** (see _Get values for signing in_)
 * **Client secret** (see _Certificates and secrets > Create a new application secret_)

diff --git a/docs/sources/slack.md b/docs/sources/slack.md
@@ -10,7 +10,7 @@ A Slack user that can manage applications is required to configure the source.
 
 Deploy the Slack source in 3 steps:
 
-1. Deploy the Slack source, retieve exposed endpoint at Triggermesh.
+1. Deploy the Slack source, retrieve exposed endpoint at Triggermesh.
 2. Configure Slack App to send events to the Slack Source endpoint.
 3. (optional) Modify the Slack Source to add Signing Secret and AppID from the configured App.
 
@@ -21,7 +21,7 @@ Create an instance of the Slack Source at Triggermesh as part of a Bridge.
 - `name` is an internal identifier inside the bridge.
 - `broker` where messages should be sent to.
 
-Save the source, fill the rest of the bridge fileds and press `Submit Bridge`. The Slack source creates a service, navigate to Functions/Services and copy the URL for the exposed service.
+Save the source, fill the rest of the bridge fields and press `Submit Bridge`. The Slack source creates a service, navigate to Functions/Services and copy the URL for the exposed service.
 
 ### Configure Slack Events API App
 

diff --git a/docs/sources/solace.md b/docs/sources/solace.md
@@ -31,8 +31,8 @@ sudo docker create \
 - run  `go run main.go` to put a message to a queue
 
 4. Consume messages from a queue
-- From project root run `go run main.go` with all env vars set. It has default values othervise
-- Put messages to a queue as in step 3 in separate terminal. View recieved messages. 
+- From project root run `go run main.go` with all env vars set. It has default values otherwise
+- Put messages to a queue as in step 3 in separate terminal. View received messages. 
 - If no go environment installed, use instructions from `local Docker build` below
 
 For more information about Solace and documentation, visit Solace [website](https://solace.com/) and [documentation](https://docs.solace.com/) sections

diff --git a/docs/sources/solacemqtt.md b/docs/sources/solacemqtt.md
@@ -33,7 +33,7 @@ sudo docker create \
 
 4. Consume messages from a queue
 - run  `go run main.go -url tcp://127.0.0.1:1883 --user admin --password admin --topic [name of your topic]`
-- Put messages to a queue as in step 3 in separate terminal. View recieved messages. 
+- Put messages to a queue as in step 3 in separate terminal. View received messages. 
 - If no go environment installed, use instructions from `local Docker build` below
 
 For more information about Solace and documentation, visit Solace [website](https://solace.com/) and [documentation](https://docs.solace.com/) sections

diff --git a/docs/targets/googlesheets.md b/docs/targets/googlesheets.md
@@ -65,7 +65,6 @@ This type expects a [JSON][ce-jsonformat] payload with the following properties:
 | **sheet_name_prefix** | string | The prefix to be used for creating new sheets |
 | **message** | string | A string to append to the sheet row |
 
-
 [ce]: https://cloudevents.io/
 [ce-jsonformat]: https://github.com/cloudevents/spec/blob/v1.0/json-format.md
 [tm-secret]:https://docs.triggermesh.io/guides/secrets/

diff --git a/docs/targets/index.md b/docs/targets/index.md
@@ -12,7 +12,7 @@ The following is a list of Triggermesh event destinations known as `Targets`. So
     * [AWS EventBridge](./awseventbridge.md): Forward arbitrary events to AWS EventBridge.
 * [Confluent](./confluent.md): Forward events to Confluent Kafka.
 * [Datadog](./datadog.md): Forward event payload to Datadog.
-* [Elasticsearch](./elasticsearch.md): Send events to Elasticsarch to be indexed.
+* [Elasticsearch](./elasticsearch.md): Send events to Elasticsearch to be indexed.
 * [Google Sheets](./googlesheets.md): Appends events to a Google Sheet row.
 * [Hasura](./hasura.md): Send GraphQL queries to Hasura.
 * [Oracle](./oracle.md): Forward events to the Oracle Cloud.

diff --git a/docs/targets/sendgrid.md b/docs/targets/sendgrid.md
@@ -24,11 +24,11 @@ In the Target creation form, provide a name for the event Target, and add the fo
 
 **Note:** If there is not a default value specified for all of the optional fields, the event received by that deployment *MUST* contain all of the information noted in the [Event Types](#event-types), save **Message**, or the Target **will** **fail**
 
-![SendgridTarget form](../images/sendgrid-target/create-bridge-2.png)
+![SendGridTarget form](../images/sendgrid-target/create-bridge-2.png)
 
 After clicking the `Save` button, the console will self-navigate to the Bridge editor. Proceed by adding the remaining components to the Bridge.
 
-After submitting the bridge, and allowing some configuration time, a green checkmark on the main _Bridges_ page indicates that the bridge with a SendGrid event Target was successfully created.
+After submitting the bridge, and allowing some configuration time, a green check mark on the main _Bridges_ page indicates that the bridge with a SendGrid event Target was successfully created.
 
 ![Bridge status](../images/bridge-status-green.png)
 
@@ -55,7 +55,7 @@ When a **Message** property is **not** present, the entire cloud event is passed
 
 ### Example
 
-An example email sent from the Sendgrid Target with the **Message** parameter omitted will look as follows:
+An example email sent from the SendGrid Target with the **Message** parameter omitted will look as follows:
 
 ```email
 from: richard <richard@triggermesh.com>

diff --git a/docs/tm/registry.md b/docs/tm/registry.md
@@ -1,6 +1,6 @@
 ## Docker Registry
 
-Docker images are used to run functions code in Knative services. This means that image registry is important part of service deployment scheme. Depending on type of service, Knative controller may either only pull or also push service image from and to registry. Triggermesh CLI provides simple configuration interface to setup registry address and user access credentials.
+Docker images are used to run functions code in Knative services. This means that image registry is important part of service deployment scheme. Depending on type of service, Knative controller may either only pull or also push service image from and to registry. TriggerMesh CLI provides simple configuration interface to setup registry address and user access credentials.
 
 ### Service from Pre-Built Image
 
@@ -33,9 +33,13 @@ tm deploy service foo-private -f https://github.com/serverless/examples \
 
 If user whose credentials are specified in `foo-registry` have "write" permissions, resulting service image will be pushed to URL composed as `registry/username/service_name`
 
+<<<<<<< HEAD
 ### GitLab CI Registry
+=======
+### GitLab CI registry
+>>>>>>> chore: fix spelling mistakes
 
-Triggermesh CLI can be used as deployment step in Gitlab CI pipeline, but considering [tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/) security policy, user must manually create CI deployment token as described [here](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token).
+TriggerMesh CLI can be used as deployment step in GitLab CI pipeline, but considering [tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/) security policy, user must manually create CI deployment token as described [here](https://docs.gitlab.com/ee/user/project/deploy_tokens/#gitlab-deploy-token).
 Deployment token must have registry read permission and should be valid for as long as the service expected to be active. If token is created, `tm` deployment step must include following commands:
 
 ```
@@ -45,11 +49,11 @@ script:
   - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull
 ...
 ```
-After this, you may pass `--registry-secret gitlab-registry` parameter to `tm deploy` command (or in [serverless.yml](https://gitlab.com/knative-examples/functions/blob/master/serverless.yaml#L6)) so that Knative could authenticate against Gitlab registry. 
-Gitlab registry doesn't provide permanent read-write token that can be used in CI, but it has job-specific `CI_JOB_TOKEN` with "write" permission which is valid only while CI job running and `CI_DEPLOY_PASSWORD` with read permission which we created before. Considering this, we can see that CLI `set registry-auth` command supports `--push` and `--pull` flags that indicates which secret must be used to push image and which for "pull" operations only. Resulting images will be stored under `registry.gitlab.com/username/project/function_name` path
+After this, you may pass `--registry-secret gitlab-registry` parameter to `tm deploy` command (or in [serverless.yml](https://gitlab.com/knative-examples/functions/blob/master/serverless.yaml#L6)) so that Knative could authenticate against GitLab registry. 
+GitLab registry doesn't provide permanent read-write token that can be used in CI, but it has job-specific `CI_JOB_TOKEN` with "write" permission which is valid only while CI job running and `CI_DEPLOY_PASSWORD` with read permission which we created before. Considering this, we can see that CLI `set registry-auth` command supports `--push` and `--pull` flags that indicates which secret must be used to push image and which for "pull" operations only. Resulting images will be stored under `registry.gitlab.com/username/project/function_name` path
 
 ### Unauthenticated Registry
 
-Besides hosted registries, triggermesh CLI may work with unauthenticated registries which does not require setting access credentials. For such cases, you may simply add `--registry-host` argument to deployment command with registry domain name parameter and resulting image will be pushed to `registry-host/namespace/service_name` URL
+Besides hosted registries, TriggerMesh CLI may work with unauthenticated registries which does not require setting access credentials. For such cases, you may simply add `--registry-host` argument to deployment command with registry domain name parameter and resulting image will be pushed to `registry-host/namespace/service_name` URL
 
 
diff --git a/docs/tm/serverless.md b/docs/tm/serverless.md
@@ -1,6 +1,6 @@
 ## Generate the Scaffolding
 
-To ease user on-boarding `tm` has a currently experimental feature to generate a scaffolfing. To generate the scaffolding for a simple Python function do:
+To ease user on-boarding `tm` has a currently experimental feature to generate a scaffolding. To generate the scaffolding for a simple Python function do:
 
 ```
 tm generate python

diff --git a/docs/tm/usage.md b/docs/tm/usage.md
@@ -5,7 +5,7 @@ Deploy service from Docker image
 tm deploy service foo -f gcr.io/google-samples/hello-app:1.0 --wait
 ```
 
-If you have Dockerfile for your service, you can use kaniko buildtemplate to deploy it
+If you have Dockerfile for your service, you can use Kaniko buildtemplate to deploy it
 ```
 tm deploy service foobar \
     -f https://github.com/knative/docs \
@@ -14,7 +14,7 @@ tm deploy service foobar \
     --wait
 ```
 
-or deploy service straight from Go source using Openfaas runtime
+or deploy service straight from Go source using OpenFaaS runtime
 ```
 tm deploy service bar \
     -f https://github.com/golang/example \
@@ -31,7 +31,7 @@ tm deploy -f https://github.com/tzununbekov/serverless
 
 ## AWS Lambda Compatible Functions
 
-With the triggermesh CLI you can easily deploy AWS Lambda functions on Kuberentes:
+With the TriggerMesh CLI you can easily deploy AWS Lambda functions on Kubernetes:
 
 Prepare local source for Golang function
 

diff --git a/scripts/release-notes.sh b/scripts/release-notes.sh
@@ -28,7 +28,7 @@ ${NOTABLE_CHANGES}
 
 ## Installation
 
-Download Triggermesh Docs ${RELEASE}
+Download TriggerMesh Docs ${RELEASE}
 
 - [container](https://gcr.io/triggermesh/docs:${RELEASE})
-Original file line number
+Diff line change
@@ Expand Up / @@ -1768,7 +1768,7 @@ OracleTargetStatus @@
     <h3 id="targets.triggermesh.io/v1alpha1.SendGridTarget">SendGridTarget
     </h3>
     <p>
-    <p>SendGridTarget is the Schema for an Sendgrid Target.</p>
+    <p>SendGridTarget is the Schema for an SendGrid Target.</p>
     </p>
     <table>
     <thead>
@@ Expand Down @@