fix(typo): Typos on user outputs and docs

decision records/release/001-release.md

@@ -17,7 +17,7 @@ sfpowerscripts currently does not have a notion of 'release', which some CICD pl
 
 Utilises a release definition file (YAML format) and combines the steps in a release into a single SFDX command: fetching artifacts, installing dependencies, deployment and release changelog generation.
 
-This command utilizes a YAML based release defintion as opposed to sfdx-project.json which is used by the orchestrator elsewhere. The benefit of using a seperate defintion is to keep release and build defintions seperated, as one could use for selective deployments.
+This command utilizes a YAML based release definition as opposed to sfdx-project.json which is used by the orchestrator elsewhere. The benefit of using a separate definition is to keep release and build definitions separated, as one could use for selective deployments.
 
 Pros:
 * Easy to use
@@ -40,7 +40,7 @@ Cons:
 * Unintuitive to use, requires external documentation
 
 
-## Decision 
+## Decision
 
 Chosen option: 1. `orchestrator:release` command
 

decision records/release/003-release-autorollback.md

@@ -10,23 +10,23 @@ Issue: [Issue #478](https://github.com/flxbl-io/sfp/issues/478) <!-- optional --
 When one releases a set of packages into an environment, there could be situations where one of the package fails and resulting in an incorrect org in
 terms of functionality.
 For eg: A release which consists of packages A,B and C failed during the installation of C, has new versions of A and B, introducing new functionality
-to the org, where as its not accurate without package 'C'.  
+to the org, where as its not accurate without package 'C'.
 
 Though number of these instances are pretty low in higher environments, as a particular release would be tested a number of times in multiple environments in lower environments. There are still instances where packages fail to install mostly due to a missing manual step. This results in a potential downtime till the team addresses the failure by a roll-forward.
 
 It would be ideal in this scenario to have a rollback option, which basically realigns the org back to the versions of the packages that were available in the org before the release was intiated.
 
-## Decision 
+## Decision
 
 ### Release command to support a rollback function
 
-Release command will support an optional rollback function enabled through `rollback:true` parameter in the release defintion. Once this functionality is activated, release command will keep track of existing packages in the org (in memory) before deploying packages as part of the current release. In case of any failures, release command will fetch the old artifacts from the artifact repository and proceed to installing these packages into the org.
+Release command will support an optional rollback function enabled through `rollback:true` parameter in the release definition. Once this functionality is activated, release command will keep track of existing packages in the org (in memory) before deploying packages as part of the current release. In case of any failures, release command will fetch the old artifacts from the artifact repository and proceed to installing these packages into the org.
 
-Unlocked packages have its own lifecycle and Salesforce would maintain deprecation and removal of unused components arising from a rollback. However for source packages, it needs to have a destructive manifest to remove the items already deployed. This functionality only attemps to install an earlier set of packages, and doesnt attempt to destroy any deployed components, especially in the case of source packages. However we could let the users know what are the components left dangling by providing a table of metadata components that will not be removed.
+Unlocked packages have its own lifecycle and Salesforce would maintain deprecation and removal of unused components arising from a rollback. However for source packages, it needs to have a destructive manifest to remove the items already deployed. This functionality only attempts to install an earlier set of packages, and doesnt attempt to destroy any deployed components, especially in the case of source packages. However we could let the users know what are the components left dangling by providing a table of metadata components that will not be removed.
 
-## Conseuqences <!-- optional --> 
+## Consequences <!-- optional -->
 
-This functionality will support ability to rollback an org to an earlier release. However not every rollbacks in Salesforce is going to be successfull, as the platform doesn't inherently support the notion of a rollback for many components and its tightly based on dependencies of a particular component. This rollback functionality could also leave the org with items that are not removed
+This functionality will support ability to rollback an org to an earlier release. However not every rollbacks in Salesforce is going to be successful, as the platform doesn't inherently support the notion of a rollback for many components and its tightly based on dependencies of a particular component. This rollback functionality could also leave the org with items that are not removed
 
 
 

decision records/release/006-release-defn-generator.md

@@ -10,7 +10,7 @@ sfpowerscripts allow a release manager to utilize  'LATEST_GIT_TAG' or to use 'S
 
 ## Decision
 
-sfpowerscripts will introduce a new command 'releasedefinition:generate' that can be used to generate a release definition file, The generatated release definiton  can then be used as an input to 'orchestrator:release' to deploy artifacts in the pipeline.
+sfpowerscripts will introduce a new command 'releasedefinition:generate' that can be used to generate a release definition file, The generatated release definition  can then be used as an input to 'orchestrator:release' to deploy artifacts in the pipeline.
 
 ```mermaid
 flowchart TD
@@ -24,20 +24,20 @@ direction LR
   B --> E[[release--<<< 3 >>>.yml]]
   A--pushes tag--->id1
   id1[(Git)]--fetches info from tag--> B
- 
+
 end
 
 subgraph ZB["release<< env >>"]
 direction LR
-   
+
     F[[release--<<< 2 >>>.yml]]-- 1.Input to command -->G[orchestrator:release < env >]
     id2[(Git)]--2.Fetches info from tag--> G
-    id3[(Artifact Repo)]--3.Fetches artifacts--> G  
+    id3[(Artifact Repo)]--3.Fetches artifacts--> G
 end
 
 subgraph ZC["release<< env >>"]
 direction LR
-   
+
     F1[[release--<<< 2 >>>.yml]]-- 1.Input to command -->G1[orchestrator:release < env >]
     id21[(Git)]--2.Fetches info from tag--> G1
     id31[(Artifact Repo)]--3.Fetches artifacts--> G1
@@ -46,15 +46,15 @@ end
 ZA -.on demand.-> ZB-.followed by.->ZC
 ```
 
-The command need a mechanism to figure out  versions of articats that constitute a release. This can be either done by utilizing an org as a reference or pointing to a particular commit reference.  
+The command need a mechanism to figure out  versions of articats that constitute a release. This can be either done by utilizing an org as a reference or pointing to a particular commit reference.
 
 The mechanism of using Org as a source of truth, was discarded due to the following reasons:
 
 * Version of artifacts in an org could be impacted by developer actions such as installing a package locally, without necessarily using sfpowerscripts command leaving the org in an incorrect state. This will result in a incorrect release definition that doesnt match the state of the particular org.
 * Strong dependency on an org in the pipeline is against the guidelines in DX@Scale principles, as any org could be refreshed at any point in time.
 * An org could be installed with artifacts created from 'quick build' stage. However these artifacts are typically not published in to the artifacts repositoy
 
-However, using tags on the version control closely matches the existing behaviour of the release command with 'LATEST_GIT_TAG', but provide additional traceability  by providing the user ability to generate and store the release defintions in version control. These versioned release defintions then could be used on demand at any point in time.
+However, using tags on the version control closely matches the existing behaviour of the release command with 'LATEST_GIT_TAG', but provide additional traceability  by providing the user ability to generate and store the release definitions in version control. These versioned release definitions then could be used on demand at any point in time.
 
 The command will utilize a schema to generate the release  definition. This allows the user for flexibility in terms of selecting artifacts
 
@@ -81,10 +81,10 @@ excludeArtifactsWithTag:
 # Exclude the following package dependecies from the generated definition
 excludePackageDependencies:
  - Pkg1
-# set below properties in generated release definition 
+# set below properties in generated release definition
 baselineOrg: << org >>
 promotePackagesBeforeDeploymentToOrg: << org >>
-skipIfAlreadyInstalled: <<whether to skip artifacts installed >> 
+skipIfAlreadyInstalled: <<whether to skip artifacts installed >>
 changelog:
   workItemFilters:
     -  <<regex pattern1>>
@@ -97,8 +97,8 @@ changelog:
 ***Implementation notes***
 
 1. The command should expect the name of the release as an input. The passed in name will be substituted in the generated release file
-2. The command is expectected to be used from any stage in the repository
+2. The command is expected to be used from any stage in the repository
 3. The input definition to this file will be called as *release definition config*
 4. Packages defined in sfdx-project.json will be filtered by the inputs in release definition config
 5. IncludeOnly or ExcludeArtifacts are mutually exclusive, with include taking precedence over exclude
-6. PackageDependencies are picked from the packageAliases 
+6. PackageDependencies are picked from the packageAliases

packages/sfp-cli/command-docs/changelog.md

@@ -21,7 +21,7 @@ FLAGS
   -n, --releasename=<value>     (required) Name of the release for which to generate changelog
   -w, --workitemfilter=<value>  (required) Regular expression used to search for work items (user stories) introduced in
                                 release
-      --directory=<value>       Relative path to directory to which the release defintion file should be generated, if
+      --directory=<value>       Relative path to directory to which the release definition file should be generated, if
                                 the directory doesnt exist, it will be created
       --limit=<value>           limit the number of releases to display in changelog markdown
       --loglevel=<option>       [default: info] logging level for this command invocation

packages/sfp-cli/command-docs/release.md

@@ -24,7 +24,7 @@ FLAGS
   -g, --logsgroupsymbol=<value>...    Symbol used by CICD platform to group/collapse logs in the console. Provide an
                                       opening group, and an optional closing group symbol.
   -o, --targetorg=<value>             (required) Username or alias of the target org.
-  -p, --releasedefinition=<value>...  (required) Path to release definiton yaml, Multiple paths can be seperated by
+  -p, --releasedefinition=<value>...  (required) Path to release definition yaml, Multiple paths can be seperated by
                                       commas
   -t, --tag=<value>                   Tag the release with a label, useful for identification in metrics
   -v, --devhubalias=<value>           Username or alias of the Dev Hub org.

packages/sfp-cli/command-docs/releasedefinition.md

@@ -1,7 +1,7 @@
 `@flxbl-io/sfp releasedefinition`
 =================================
 
-Commands around managing release defintion
+Commands around managing release definition
 
 * [`@flxbl-io/sfp releasedefinition generate`](#flxbl-iosfp-releasedefinition-generate)
 
@@ -16,7 +16,7 @@ USAGE
 
 FLAGS
   -b, --branchname=<value>   Repository branch in which the release definition files are to be written
-  -c, --gitref=<value>       (required) Utilize the tags on the source branch to generate release definiton
+  -c, --gitref=<value>       (required) Utilize the tags on the source branch to generate release definition
   -d, --directory=<value>    Relative path to directory to which the release definition file should be generated, if the
                              directory doesnt exist, it will be created
   -f, --configfile=<value>   (required) Path to the release config file which determines how the release definition

packages/sfp-cli/command-docs/repo.md

@@ -19,7 +19,7 @@ FLAGS
                                        the registry
   -g, --logsgroupsymbol=<value>...     Symbol used by CICD platform to group/collapse logs in the console. Provide an
                                        opening group, and an optional closing group symbol.
-  -p, --releasedefinitions=<value>...  (required) Path to release definiton yaml
+  -p, --releasedefinitions=<value>...  (required) Path to release definition yaml
   -s, --sourcebranchname=<value>       (required) Name of the source branch to be used on which the alignment need to be
                                        applied
   -t, --targetbranchname=<value>       (required) Name of the target branch to be created after the alignment

packages/sfp-cli/messages/generate_changelog.json

@@ -10,5 +10,5 @@
     "noPushFlagDescription":"Do not push the changelog to a repository to the provided branch",
     "showAllArtifactsFlagDescription": "Show all artifacts in changelog markdown, including those that have not changed in the release",
     "forcePushFlagDescription": "Force push changes to the repository branch",
-    "directoryFlagDescription": "Relative path to directory to which the release defintion file should be generated, if the directory doesnt exist, it will be created"
+    "directoryFlagDescription": "Relative path to directory to which the release definition file should be generated, if the directory doesnt exist, it will be created"
 }

packages/sfp-cli/messages/patch.json

@@ -1,6 +1,6 @@
 {
     "commandDescription": "Generate a dynamic branch with the packages patched to the contents as mentioned in the release config file",
-    "releaseDefinitionFlagDescription": "Path to release definiton yaml",
+    "releaseDefinitionFlagDescription": "Path to release definition yaml",
     "sourcebranchNameFlagDescription": "Name of the source branch to be used on which the alignment need to be applied",
     "targetbranchNameFlagDescription": "Name of the target branch to be created after the alignment",
     "scriptPathFlagDescription": "(Optional: no-NPM) Path to script that authenticates and downloads artifacts from the registry",

packages/sfp-cli/messages/release.json

@@ -1,6 +1,6 @@
 {
     "commandDescription": "Release a set of artifact(s) as defined by a release definition into a target org",
-    "releaseDefinitionFlagDescription": "Path to release definiton yaml, Multiple paths can be seperated by commas",
+    "releaseDefinitionFlagDescription": "Path to release definition yaml, Multiple paths can be seperated by commas",
     "targetOrgFlagDescription": "Alias/User Name of the target environment",
     "scriptPathFlagDescription": "(Optional: no-NPM) Path to script that authenticates and downloads artifacts from the registry",
     "npmFlagDescription": "Download artifacts from a pre-authenticated private npm registry",

packages/sfp-cli/messages/releasedefinition_generate.json

@@ -2,7 +2,7 @@
     "commandDescription": "Generates release definition based on the artifacts at the specified head of source branch/commit ref",
     "configFileFlagDescription":"Path to the release config file which determines how the release definition should be generated",
     "releaseNameFlagDescription": "Set a release name on the release definition file created",
-    "commitFlagDescription": "Utilize the tags on the source branch to generate release definiton",
+    "commitFlagDescription": "Utilize the tags on the source branch to generate release definition",
     "directoryFlagDescription": "Relative path to directory to which the release definition file should be generated, if the directory doesnt exist, it will be created",
     "branchNameFlagDescription": "Repository branch in which the release definition files are to be written",
     "noPushFlagDescription":"Do not push the changelog to a repository to the provided branch",

packages/sfp-cli/package.json

@@ -110,7 +110,7 @@
         "topicSeparator": " ",
         "topics": {
             "releasedefinition": {
-                "description": "Commands around managing release defintion"
+                "description": "Commands around managing release definition"
             },
             "pool": {
                 "description": "Build and manage scratch org or sandbox pools"

packages/sfp-cli/resources/schemas/pooldefinition.schema.json

@@ -48,7 +48,7 @@
         },
         "releaseConfigFile": {
             "title": "Path to release config file",
-            "description": "Path to the config file which determines how a release defintion should be generated, enable this for pools to use this release config to only utilize artifacts described the releae config",
+            "description": "Path to the config file which determines how a release definition should be generated, enable this for pools to use this release config to only utilize artifacts described the releae config",
             "type": "string"
         },
         "succeedOnDeploymentErrors": {

packages/sfp-cli/src/commands/release.ts

@@ -148,7 +148,7 @@ export default class Release extends SfpCommand {
                 this.flags.targetorg == releaseDefinition.promotePackagesBeforeDeploymentToOrg &&
                 !this.flags.devhubalias
             )
-                throw new Error('DevHub is mandatory when promote is used within release defintion');
+                throw new Error('DevHub is mandatory when promote is used within release definition');
 
             releaseDefinitions.push(releaseDefinition);
         }
@@ -238,7 +238,7 @@ export default class Release extends SfpCommand {
         for (const succeededDeployment of releaseResult.succeededDeployments) {
             SFPLogger.log(
                 COLOR_HEADER(
-                    `\n Release Defintion: ${succeededDeployment.releaseDefinition.release} for Release Config: ${
+                    `\n Release Definition: ${succeededDeployment.releaseDefinition.release} for Release Config: ${
                         succeededDeployment.releaseDefinition.releaseConfigName
                             ? succeededDeployment.releaseDefinition.releaseConfigName
                             : 'N/A'
@@ -250,7 +250,7 @@ export default class Release extends SfpCommand {
         }
 
         for (const failedDeployment of releaseResult.failedDeployments) {
-            SFPLogger.log(COLOR_HEADER(`\n Release Defintion: ${failedDeployment.releaseDefinition.release} for for Release Config: ${
+            SFPLogger.log(COLOR_HEADER(`\n Release Definition: ${failedDeployment.releaseDefinition.release} for for Release Config: ${
                 failedDeployment.releaseDefinition.releaseConfigName
                     ? failedDeployment.releaseDefinition.releaseConfigName
                     : 'N/A'

packages/sfp-cli/src/commands/repo/patch.ts

@@ -80,7 +80,7 @@ export default class Patch extends SfpCommand {
                 logger
             );
             SFPLogger.log(
-                COLOR_HEADER(`Release Defintion: ${this.flags.releasedefinitions}`),
+                COLOR_HEADER(`Release Definition: ${this.flags.releasedefinitions}`),
                 LoggerLevel.INFO,
                 logger
             );

packages/sfp-cli/src/impl/changelog/ChangelogMarkdownGenerator.ts

@@ -46,7 +46,7 @@ export default class ChangelogMarkdownGenerator {
                 payload += `## ${release.names.join(`/`)}\n `;
                 payload += `Cumulative Release Number: <b>${release.buildNumber}</b> \n\n`;
                 if(release.date && !this.isForWorkItemOnlyOutput)
-                  payload += `Matching defintion first created or deployed to an org on: ${release.date}\n `
+                  payload += `Matching definition first created or deployed to an org on: ${release.date}\n `
 
             }