fix last typo

docs/ciTests.md

@@ -58,7 +58,7 @@ It's important to realize the image will be named using the arg from the `-c` fl
 **Goal:** When a PR is created, have a GitHub workflow that:
 
 1. Builds a Docker image with the latest code changes to the binary.
-2. Synchronously spin up runners (one for each test), load Docker image, and run tests. 
+2. Synchronously spin up runners (one for each test), load Docker image, and run tests.
 
 We recommend having this workflow run only on PR's.
 
@@ -115,7 +115,7 @@ jobs:
     strategy:
         matrix:
             # names of `make` commands to run tests
-            test: 
+            test:
               - ictest-tkn-factory
               - ictest-packet-forward
               - ictest-paramauthority
@@ -132,7 +132,7 @@ jobs:
         uses: actions/setup-go@v3
         with:
           go-version: 1.19
-              
+
       - name: checkout chain
         uses: actions/checkout@v3
 
@@ -224,7 +224,7 @@ The example below will spin up 9 runners, one for each test.
     strategy:
         matrix:
             # names of `make` commands to run tests
-            test: 
+            test:
               - ictest-tkn-factory
               - ictest-packet-forward
               - ictest-paramauthority
@@ -241,7 +241,7 @@ The example below will spin up 9 runners, one for each test.
         uses: actions/setup-go@v3
         with:
           go-version: 1.19
-              
+
       - name: checkout chain
         uses: actions/checkout@v3
 

docs/conformance-tests-bin.md

@@ -2,7 +2,7 @@
 
 `interchaintest` comes with a suite of conformance tests. These tests ensure IBC and relayer compatibility. On a high-level it tests:
 - `client`, `channel`, and `connection` creation
-- messages are properly relayed and acknowledged 
+- messages are properly relayed and acknowledged
 - packets are being properly timed out
 
 You can view all the specific conformance test by reviewing them in the [conformance](../conformance/) folder.
@@ -20,7 +20,7 @@ go test -v ./cmd/interchaintest/
 ### Custom Environment
 Using the binary allows for easy custom chain pairs and custom testing environments.
 
-This is accomplished via the `-matrix` argument. 
+This is accomplished via the `-matrix` argument.
 ```shell
 interchaintest -matrix <path/to/matrix.json>
 ```
@@ -39,13 +39,13 @@ By passing in a matrix file you can customize these aspects of the environment:
 
 **Pre-Configured Chains**
 
-`interchaintest` comes with [pre-configured chains](../configuredChains.yaml). 
-In the matrix file, if `Name` matches the name of any pre-configured chain, `interchaintest` will use standard settings UNLESS overriden in the matrix file. [example_matrix_custom.json](../cmd/interchaintest/example_matrix_custom.json) is an example of overriding all options.
+`interchaintest` comes with [pre-configured chains](../configuredChains.yaml).
+In the matrix file, if `Name` matches the name of any pre-configured chain, `interchaintest` will use standard settings UNLESS overridden in the matrix file. [example_matrix_custom.json](../cmd/interchaintest/example_matrix_custom.json) is an example of overriding all options.
 
 
 **Custom Binaries**
 Chain binaries must be installed in a docker container.
-The `Image` array in the matrix json file allows you to pass in docker images with your chain binary of choice. 
+The `Image` array in the matrix json file allows you to pass in docker images with your chain binary of choice.
 If the docker image does not live in a public repository, can you **pass in a local docker image like so:**
 
 ```json

docs/conformance-tests-lib.md

@@ -9,7 +9,7 @@ You can view all the specific conformance test by reviewing them in the [conform
 
 ## Importing Conformance Tests In Your Project
 
-`interchaintest` can be imported into your own packages to be used as a library as well as being used from the 
+`interchaintest` can be imported into your own packages to be used as a library as well as being used from the
 binary itself, see [here](conformance-tests-bin.md).
 
 A common pattern when importing `interchaintest` into your own repositories is to use a Go submodule. The reason being
@@ -21,16 +21,16 @@ to use specific versions of dependencies. To avoid this issue one will typically
 
 The main entrypoint exposed by the `conformance` package is a function named `Test`.
 
-Here is the function signature of `Test`:   
+Here is the function signature of `Test`:
 ```go
 func Test(t *testing.T, ctx context.Context, cfs []interchaintest.ChainFactory, rfs []interchaintest.RelayerFactory, rep *testreporter.Reporter)
 ```
 
-It accepts a normal `testing.T` and `context.Context` from the Go standard library as well as a few types defined in `interchaintest`.  
+It accepts a normal `testing.T` and `context.Context` from the Go standard library as well as a few types defined in `interchaintest`.
 
 - `testreporter.Reporter` is used for collecting detailed test reports, you can read more about it [here](../testreporter/doc.go).
 - `interchaintest.ChainFactory` is used to define which chain pairs should be used in conformance testing.
-- `interchaintest.RelayerFactory` is used to define which relayer implementations should be used to test IBC functionality between your chain pairs.  
+- `interchaintest.RelayerFactory` is used to define which relayer implementations should be used to test IBC functionality between your chain pairs.
 
 It is important to note that the `Test` function accepts a slice of `ChainFactory`, currently the `conformance` tests only work against
 a pair of two chains at a time. This means that each `ChainFactory` should only contain definitions for two chains,

docs/writeCustomTests.md

@@ -2,11 +2,11 @@
 
 This document breaks down code snippets from [learn_ibc_test.go](../examples/ibc/learn_ibc_test.go). This test:
 
-1) Spins up two chains (Gaia and Osmosis) 
+1) Spins up two chains (Gaia and Osmosis)
 2) Creates an IBC Path between them (client, connection, channel)
 3) Sends an IBC transaction between them.
 
-It validates each step and confirms that the balances of each wallet are correct. 
+It validates each step and confirms that the balances of each wallet are correct.
 
 
 ### Three basic components of `interchaintest`:
@@ -26,21 +26,21 @@ cf := interchaintest.NewBuiltinChainFactory(zaptest.NewLogger(t), []*interchaint
 })
 ```
 
-The chain factory is where you configure your chain binaries. 
+The chain factory is where you configure your chain binaries.
 
-`interchaintest` needs a docker image with the chain binary(s) installed to spin up the local testnet. 
+`interchaintest` needs a docker image with the chain binary(s) installed to spin up the local testnet.
 
 `interchaintest` has several [pre-configured chains](../configuredChains.yaml). These docker images are pulled from [Heighliner](https://github.com/strangelove-ventures/heighliner) (repository of docker images of many IBC enabled chains). Note that Heighliner needs to have the `Version` you are requesting.
 
 When creating your `ChainFactory`, if the `Name` matches the name of a pre-configured chain, the pre-configured settings are used. You can override these settings by passing them into the `ibc.ChainConfig` when initializing your ChainFactory. We do this above with `GasPrices` for gaia.
 
-You can also pass in **remote images** and/or **local docker images**. 
+You can also pass in **remote images** and/or **local docker images**.
 
 See an examples below:
 
 ```go
 cf := interchaintest.NewBuiltinChainFactory(zaptest.NewLogger(t), []*interchaintest.ChainSpec{
-    
+
     // -- PRE CONFIGURED CHAIN EXAMPLE --
     {Name: "gaia", Version: "v7.0.2"},
 
@@ -71,7 +71,7 @@ If you are not using a pre-configured chain, you must fill out all values of the
 
 By default, `interchaintest` will spin up a 3 docker images for each chain:
 - 2 validator nodes
-- 1 full node. 
+- 1 full node.
 
 These settings can all be configured inside the `ChainSpec`.
 
@@ -94,9 +94,9 @@ gaia, osmosis := chains[0], chains[1]
 
 ## Relayer Factory
 
-The relayer factory is where relayer docker images are configured. 
+The relayer factory is where relayer docker images are configured.
 
-Currently only the [Cosmos/Relayer](https://github.com/cosmos/relayer)(CosmosRly) is integrated into `interchaintest`. 
+Currently only the [Cosmos/Relayer](https://github.com/cosmos/relayer)(CosmosRly) is integrated into `interchaintest`.
 
 Here we prep an image with the Cosmos/Relayer:
 ```go
@@ -107,7 +107,7 @@ r := interchaintest.NewBuiltinRelayerFactory(ibc.CosmosRly, zaptest.NewLogger(t)
 
 ## Interchain
 
-This is where we configure our test-net/interchain. 
+This is where we configure our test-net/interchain.
 
 We prep the "interchain" by adding chains, a relayer, and specifying which chains to create IBC paths for:
 
@@ -146,20 +146,20 @@ Upon calling build, several things happen (specifically for cosmos based chains)
     - 1 trillion "stake" are staked
     - 100 billion "stake" are self delegated
 - Each chain gets a faucet address (key named "faucet") with 10 billion units of denom funded in genesis
-- The relayer wallet gets 1 billion units of each chains denom funded in genesis 
+- The relayer wallet gets 1 billion units of each chains denom funded in genesis
 - Genesis for each chain takes place
 - IBC paths are created: `client`, `connection`, `channel` for each link
 
 
-Note that this function takes a `testReporter`. This will instruct `interchaintest` to export and reports of the test(s). The `RelayerExecReporter` satisfies the reporter requirement. 
+Note that this function takes a `testReporter`. This will instruct `interchaintest` to export and reports of the test(s). The `RelayerExecReporter` satisfies the reporter requirement.
 
 Note: If report files are not needed, you can use `testreporter.NewNopReporter()` instead.
-    
+
 
 Passing in the optional `BlockDatabaseFile` will instruct `interchaintest` to create a sqlite3 database with all block history. This includes raw event data.
 
 
-Unless specified, default options are used for `client`, `connection`, and `channel` creation. 
+Unless specified, default options are used for `client`, `connection`, and `channel` creation.
 
 
 Default `createChannelOptions` are:
@@ -206,7 +206,7 @@ osmosisUser := users[1]
 
 ## Interacting with the Interchain
 
-Now that the interchain is built, you can interact with each binary. 
+Now that the interchain is built, you can interact with each binary.
 
 EXAMPLE: Getting the RPC address:
 ```go
@@ -225,7 +225,7 @@ transfer := ibc.WalletAmount{
 tx, err := gaia.SendIBCTransfer(ctx, gaiaChannelID, gaiaUser.KeyName, transfer, ibc.TransferOptions{})
 ```
 
-The `Exec` method allows any arbitrary command to be passed into a chain binary or relayer binary. 
+The `Exec` method allows any arbitrary command to be passed into a chain binary or relayer binary.
 
 EXAMPLE: Sending an IBC transfer with the `Exec`:
 ```go