chore: fix spelling (#1127)

* chore: fix spelling

* Regen. i18n_resources.go

Co-authored-by: Matt Rutkowski <mrutkowski@apache.org>

Author: jbampton

deployers/deploymentreader_test.go

@@ -95,7 +95,7 @@ func testLoadAndBindDeploymentYAML(t *testing.T, path string, triggerName string
 	dReader := NewDeploymentReader(sDeployer)
 	err := dReader.HandleYaml()
 
-	// DEBUG() Uncomment to display initial DeploymentDescriptor (manifest, deployemnt befopre binding)
+	// DEBUG() Uncomment to display initial DeploymentDescriptor (manifest, deployment before binding)
 	//fmt.Println(utils.ConvertMapToJSONString("BEFORE: dReader.DeploymentDescriptor", dReader.DeploymentDescriptor))
 	//fmt.Println(utils.ConvertMapToJSONString("BEFORE: sDeployer.Deployment", sDeployer.Deployment))
 
@@ -131,7 +131,7 @@ func TestDeploymentReader_ProjectBindTrigger(t *testing.T) {
 	// Create an annotation (in manifest representation) with key we expect, with value that should be overwritten
 	TEST_ANNOTATION := whisk.KeyValue{TEST_ANNOTATION_KEY, "foo"}
 
-	// create ServicedEployer
+	// create ServiceDeployer
 	sDeployer, dReader := testLoadAndBindDeploymentYAML(t, TEST_DATA, TEST_TRIGGER, TEST_ANNOTATION)
 
 	// test Project exists with expected name in Deployment file

deployers/whiskclient_test.go

@@ -282,5 +282,5 @@ func TestNewWhiskConfigWithAdditionalHeaders(t *testing.T) {
 	newHeaderValue := "NewValue"
 	AddAdditionalHeader(newHeader, newHeaderValue)
 	config, _ := NewWhiskConfig(propPath, deploymentPath, manifestPath)
-	assert.Equal(t, newHeaderValue, config.AdditionalHeaders.Get(newHeader), "Failed to set an addtional header")
+	assert.Equal(t, newHeaderValue, config.AdditionalHeaders.Get(newHeader), "Failed to set an additional header")
 }

docs/sync_projects_between_client_and_server.md

@@ -33,7 +33,7 @@ whisk-managed:
 
 > Where the text “OpenWhisk” is a constant prefix and “\0” is the NULL character. The <size_of_manifest_file> and <contents_of_manifest_file> vary depending on the file.
 
-Now, subsequent deployments of the same project in `sync` mode, calculates a new `projectHash` on client and compares it with the one on the server for every entity in that project. This comparision could lead us to following two scenarios:
+Now, subsequent deployments of the same project in `sync` mode, calculates a new `projectHash` on client and compares it with the one on the server for every entity in that project. This comparison could lead us to following two scenarios:
 
 * **Scenario 1:** If `projectHash` on client is same as `projectHash` on the server i.e. there were no changes in the project on the client side, the project on server side is left as is except wskdeploy redeploys all the entities from manifest file to capture any changes in deployment file.
 

docs/wskdeploy_action_env_var_parms.md

@@ -86,7 +86,7 @@ In this example:
 - we further demonstrated how string values from environment variables could be concatenated with other strings within a Manifest file
 
 ### Notes:
-- These methods for binidng environment variables to input parameters are also available within Deployment files.
+- These methods for binding environment variables to input parameters are also available within Deployment files.
 
 ### Source code
 The manifest file for this example can be found here:

docs/wskdeploy_apigateway_http.md

@@ -87,9 +87,9 @@ Because a HTTP response disables the API Gateway default handling, you have to p
 - a `body` field that contains your normal payload,
 - an optional `headers` field that includes any HTTP header you want to set, typically `Content-Type`.
 
-If you don't provide this structure, the API Gateway will generate a HTTP response with status code `204: No Content` and an empty body. If this occurs when it shouldn't, it's probably a sign that you have a HTTP response specified with the gateway but the undelying action doesn't return this structure.
+If you don't provide this structure, the API Gateway will generate a HTTP response with status code `204: No Content` and an empty body. If this occurs when it shouldn't, it's probably a sign that you have a HTTP response specified with the gateway but the underlying action doesn't return this structure.
 
-When you want to return an error, you need to provide the same structure wrapped into an `error` object. If you don't wrap it into an `error` object, it will still work from an HTTP prespective but OpenWhisk will not recognise it as an error.
+When you want to return an error, you need to provide the same structure wrapped into an `error` object. If you don't wrap it into an `error` object, it will still work from an HTTP perspective but OpenWhisk will not recognise it as an error.
 
 This structure will work with any language that is supported by OpenWhisk, such as python or Java. If you are using JavaScript, you can make use of `Promise.resolve` and `Promise.reject` to make your code more readable by removing the need for the `error` wrapper:
 

docs/wskdeploy_apigateway_http_sequence.md

@@ -144,7 +144,7 @@ You should then see a JSON response with status code `200` and the following res
 
 ### Discussion
 
-By combining HTTP responses and sequences, you can re-use existing actions that are not designed to return HTTP responses by adding the necesary wrapper to the final result. You need to be careful how errors are handled as they will short-circuit the sequence execution and return early.
+By combining HTTP responses and sequences, you can re-use existing actions that are not designed to return HTTP responses by adding the necessary wrapper to the final result. You need to be careful how errors are handled as they will short-circuit the sequence execution and return early.
 
 ### Source code
 The source code for the manifest and JavaScript files can be found here:

docs/wskdeploy_apigateway_open_api_spec.md

@@ -112,7 +112,7 @@ There are two major differences from _"Hello World" API_ example:
 - the root key is now project as the open api specification is a project wide concept.
 - a new `config` key specifying where the Open API Specification is located.
 
-The `config` key under `project` in the manifest file specifies where the Open API Specification is located. The keyword `config` was chosen to remain consistent with the `config-file` terminology in OpenWhisk CLI flag option. The Open API Specification describes in a JSON document the the base path, endpoint, HTTP verb, and other details describing the API. For example, the document above describes a GET endpoint at `/hello/world` that recieves JSON as input and returns JSON as output.
+The `config` key under `project` in the manifest file specifies where the Open API Specification is located. The keyword `config` was chosen to remain consistent with the `config-file` terminology in OpenWhisk CLI flag option. The Open API Specification describes in a JSON document the the base path, endpoint, HTTP verb, and other details describing the API. For example, the document above describes a GET endpoint at `/hello/world` that receives JSON as input and returns JSON as output.
 
 ### Deploying
 

docs/wskdeploy_faq.md

@@ -30,7 +30,7 @@
 
 ### What is the order of precedence for OpenWhisk credentials?
 
-- The ```wskdeploy``` utility finds the credentials (apihost, namespace, and auth) as well as the APIGW_ACCESS_TOKEN in the folowing precedence from highest to lowest:
+- The ```wskdeploy``` utility finds the credentials (apihost, namespace, and auth) as well as the APIGW_ACCESS_TOKEN in the following precedence from highest to lowest:
   - ```wskdeploy``` command line (i.e. ```wskdeploy --apihost --namespace --auth```)
   - The deployment file
   - The manifest file

docs/wskdeploy_sequence_basic.md

@@ -21,7 +21,7 @@
 
 ## Creating a basic Action sequence
 
-OpenWhisk supports creating a new, named composite action from sequencung multiple, compatible Actions.
+OpenWhisk supports creating a new, named composite action from sequencing multiple, compatible Actions.
 
 This example:
 - Shows how to use a Manifest to sequence three actions together to:
@@ -180,7 +180,7 @@ params: {
     "job": "gentleman"
  }
 ```
-the input paramaters are augmented by the first Action in the sequence to produce the output "member" object:
+the input parameters are augmented by the first Action in the sequence to produce the output "member" object:
 
 ```json
 member: {

parsers/manifest_parser.go

@@ -660,7 +660,7 @@ func (dm *YAMLParser) readActionFunction(manifestFilePath string, manifestFileNa
 
 	if utils.IsDirectory(actionFilePath) {
 		zipFileName = actionFilePath + "." + runtimes.ZIP_FILE_EXTENSION
-		err := utils.NewZipWritter(actionFilePath, zipFileName, action.Include, action.Exclude, filepath.Dir(manifestFilePath)).Zip()
+		err := utils.NewZipWriter(actionFilePath, zipFileName, action.Include, action.Exclude, filepath.Dir(manifestFilePath)).Zip()
 		if err != nil {
 			return actionFilePath, nil, err
 		}