nit wrangling

Author: grokspawn

Makefile

@@ -46,32 +46,32 @@ framework: CATALOG_OWNERS
 
 # basic target provides an example FBC generation from a `basic` veneer type.  
 # this example takes a single file as input and generates a well-formed FBC operator contribution as an output
-# the 'sanity' target should be used next to validate the output
+# the 'validate' target should be used next to validate the output
 .PHONY: basic
 basic: bin/opm basic-veneer.yaml clean
 	mkdir -p $(OPERATOR_CATALOG_DIR) && bin/opm alpha render-veneer basic -o yaml basic-veneer.yaml > $(OPERATOR_CATALOG_CONTRIBUTION)
 
 
 # semver target provides an example FBC generation from a `semver` veneer type.  
 # this example takes a single file as input and generates a well-formed FBC operator contribution as an output
-# the 'sanity' target should be used next to validate the output
+# the 'validate' target should be used next to validate the output
 .PHONY: semver
 semver: bin/opm semver-veneer.yaml clean
 	mkdir -p $(OPERATOR_CATALOG_DIR) && bin/opm alpha render-veneer semver -o yaml semver-veneer.yaml > $(OPERATOR_CATALOG_CONTRIBUTION)
 
 
-# sanity target illustrates FBC validation
+# validate target illustrates FBC validation
 # all FBC must pass opm validation in order to be able to be used in a catalog
-.PHONY: sanity
-sanity: bin/opm $(OPERATOR_CATALOG_CONTRIBUTION) preverify
+.PHONY: validate
+validate: bin/opm $(OPERATOR_CATALOG_CONTRIBUTION) preverify
 	bin/opm validate catalog && echo "catalog validation passed" || echo "catalog validation failed"
 
 
 # preverify target ensures that the operator name is consistent between the destination directory and the generated catalog
 # since the veneer will be modified outside the build process but needs to be consistent with the directory name
 .PHONY: preverify
 preverify: $(YQ) $(OPERATOR_CATALOG_CONTRIBUTION)
-	./sanity.sh -n $(OPERATOR_NAME) -f $(OPERATOR_CATALOG_CONTRIBUTION)
+	./validate.sh -n $(OPERATOR_NAME) -f $(OPERATOR_CATALOG_CONTRIBUTION)
 
 
 .PHONY: clean

README.md

@@ -5,9 +5,9 @@ Welcome! This repository serves to give a good starting point for those interest
 ## Quickstart
 1. fork this repository
 2. adjust destination fields in .github/workflows/ci.yaml as necessary, commit and push changes
-3. adjust Makefile $OPERATOR_NAME for your operator's name
+3. adjust Makefile `$OPERATOR_NAME` for your operator's name
 2. decide on an approach: basic veneer, semver veneer, custom veneers, raw FBC, etc. and adjust the 'catalog' target in Makefile to generate your desired FBC
-4. run local tests (`make catalog`, `make sanity`, etc.) until happy with the generated FBC.
+4. run local tests (`make catalog`, `make validate`, etc.) until happy with the generated FBC
 6. add, commit, and push the changes
 7. verify that CI passes and opens a PR in the catalog repository
 
@@ -33,7 +33,7 @@ catalog
 
 
 ### Lifecycle
-This repository models a single operator author contributing their FBC to a catalog.  This repository comes configured ready with github actions to deliver the FBC to an example [catalog github repository](https://github.com/grokspawn/cool-catalog/). Github actions are preconfigured to generate the FBC from this repository and open a pull request on the catalog repository to merge them.  (See that repository for more information about the lifecycle steps after creating the pull request.)
+This repository models a single operator author contributing their FBC to a catalog.  This repository has pre-configured GitHub actions to deliver the FBC to an example [catalog GitHub repository](https://github.com/grokspawn/cool-catalog/).  The actions will generate the FBC from this repository and open a pull request on the catalog repository to merge them.  (See that repository for more information about the lifecycle steps after creating the pull request.)
 
 
 ```mermaid
@@ -70,21 +70,22 @@ deactivate CatalogRepo
 ```
 
 1. Fork and Clone Remote Repository  
-IMPORTANT!  Skip this step, and any changes will be ignored.
+IMPORTANT!  Any operator-specific changes contributions to the parent repository will be discarded.
 
 2. Update CI Destination  
-Customize ci.yaml in .github/workflows/ci.yaml to your needs, setting the destination_repo to the URI of your catalog repository. 
+Customize `.github/workflows/ci.yaml` to your needs, including setting the `destination_repo` to the URI of your catalog repository. 
 
 3. Push Changes to Remote
-Push the CI changes to the remote branch so they will be ready/able to trigger when you later push catalog contributions
+Push the CI changes to the remote branch so they will trigger later when you push catalog contributions.
 
 4. Update 'catalog' target
 Locally, update the catalog target in the Makefile to generate your FBC.  Example targets are provided in the Makefile (with supporting artifacts) to support to the following scenarios:  
    1. basic veneer generates FBC
    2. semver veneer generates FBC
    3. compound veneer generates and post-processes FBC  
+
 5. Push Changes to Remote  
-Once happy with the state of the `catalog` make target and the resulting FBC, push the changes to the remote repository.  This will trigger the remote actions to generate a pull request against the destination catalog repository as specified in #2.
+Once the `catalog` make target and the resulting FBC are ready, push the changes to the remote repository.  This will trigger the remote actions to generate a pull request against the destination catalog repository as specified in #2.