Improves documentation

docs/chainlink_nodes.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Chainlink Nodes
-nav_order: 4
+nav_order: 5
 has_children: false
 ---
 
@@ -35,10 +35,10 @@ var (
 
 By("Deploying the environment", func() {
   suiteSetup, err = actions.SingleNetworkSetup(
-    environment.NewMixedVersionChainlinkCluster(6, 2),
-    actions.EVMNetworkFromConfigHook,   // Default, uses the first network defined in our config file
-    actions.EthereumDeployerHook,       // Default, creates a contract deployer for our network
-    actions.EthereumClientHook,         // Default, establishes client connection to our network
+    environment.NewMixedVersionChainlinkCluster(6, 2), // Use a mix of different chainlink versions
+    actions.EVMNetworkFromConfigHook,                  // Default, uses the first network defined in our config file
+    actions.EthereumDeployerHook,                      // Default, creates a contract deployer for our network
+    actions.EthereumClientHook,                        // Default, establishes client connection to our network
     tools.ProjectRoot,
   )
   Expect(err).ShouldNot(HaveOccurred())
@@ -76,4 +76,4 @@ By("Funding Chainlink nodes", func() {
   )
   Expect(err).ShouldNot(HaveOccurred())
 })
-```
+```

docs/contracts/contracts.md

@@ -1,15 +1,15 @@
 ---
 layout: default
 title: Contracts
-nav_order: 3
+nav_order: 4
 has_children: true
 permalink: docs/contracts
 ---
 
 # Contracts
 
 We have a few deployable contracts, right now all geared towards chainlink functionality. The hope is to allow anyone to
-deploy their contracts and interact with them using the framework, but that presents some serioud difficulties we're
+deploy their contracts and interact with them using the framework, but that presents some serious difficulties we're
 currently trying to work through. Until then, we have a few contracts ready to be deployed.
 
-New to smart contracts? Learn more [here](https://docs.chain.link/docs/beginners-tutorial/)!
+New to smart contracts? Learn more [here](https://docs.chain.link/docs/beginners-tutorial/)!

docs/contracts/flux.md

@@ -7,7 +7,7 @@ parent: Contracts
 
 # Flux Aggregator
 
-[Example Usage](../suite/integration/contracts_flux_test.go)
+[Example Usage](../../suite/smoke/contracts_flux_test.go)
 
 ```go
 type FluxAggregator interface {

docs/contracts/keeper.md

@@ -7,7 +7,7 @@ parent: Contracts
 
 # Keeper
 
-[Example Usage](../suite/integration/contracts_keeper_test.go)
+[Example Usage](./../suite/smoke/contracts_keeper_test.go)
 
 ```go
 type UpkeepRegistrar interface {

docs/contracts/ocr.md

@@ -7,7 +7,7 @@ parent: Contracts
 
 # OCR
 
-[Example Usage](../suite/integration/contracts_ocr_test.go)
+[Example Usage](./../suite/smoke/contracts_ocr_test.go)
 
 ```go
 type OffchainAggregator interface {

docs/contracts/storage.md

@@ -7,7 +7,7 @@ parent: Contracts
 
 # Storage
 
-[Example Usage](../suite/integration/contracts_test.go)
+[Example Usage](./../suite/smoke/contracts_test.go)
 
 ```go
 type Storage interface {

docs/contracts/vrf.md

@@ -7,7 +7,7 @@ parent: Contracts
 
 # VRF
 
-[Example Usage](../suite/integration/contracts_vrf_test.go)
+[Example Usage](./../suite/smoke/contracts_vrf_test.go)
 
 ```go
 type VRF interface {

docs/index.md

@@ -12,18 +12,25 @@ permalink: /
 [![Go Reference](https://pkg.go.dev/badge/github.com/smartcontractkit/integrations-framework.svg)](https://pkg.go.dev/github.com/smartcontractkit/integrations-framework)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
-The Chainlnk Integration Framework is a blockchain development and testing framework written in Go. Its primary purpose
-is to help chainlink developers create extensive integration, e2e, performance, and chaos tests to ensure the stability
-of the chainlink project. It can also be helpful to those who just want to use chainlink oracles in their projects to help
-test their contracts, or even for those that aren't using chainlink.
+The Chainlnk Integrations Framework is a blockchain development and testing framework written in Go. While the framework
+is designed primarily with testing Chainlink nodes in mind, it's not at all limited to that function. With this
+framework, blockchain developers can create extensive integration, e2e, performance, and chaos tests for almost anything!
 
-## Setup
+Are you new to [blockchain development](https://ethereum.org/en/developers/docs/),
+[smart contracts](https://docs.chain.link/docs/beginners-tutorial/),
+or [Chainlink](https://chain.link/)? Learn more by clicking the links!
+
+## Kubernetes Setup
 
 In order to use this framework, you must have a connection to an actively running
 [Kubernetes cluster](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/). If you don't have
 one handy, check out [minikube](https://minikube.sigs.k8s.io/docs/start/) which should work fine for smaller tests,
-but will likely need to be allocated more power, or you'll need to use a more powerful cluster in general to run tests
-that require lots of services, like OCR.
+but if you write tests that make use of multiple Chainlink nodes, or try to run many tests in parallel, you'll likely
+find minikube inadequeate. A Kubernetes cluster with 4 vCPU and 10 GB RAM is a good starting point for when you start
+to notice issues.
+
+**The framework will use whatever your primary KUBECONFIG cluster is.** Learn more
+about setting up Kubernetes [here](https://kubernetes.io/docs/setup/).
 
 ### Why?
 
@@ -37,77 +44,3 @@ There's a lot of different components to bring up for each test, most of which i
 Following the good testing practice of having clean, non-dependent test environments means we're creating a lot of these
 components for each test, and tearing them down soon after. In order to organize these test environments, and after
 finding `docker compose` to be woefully inadequate after a certain point, kubernetes was the obvious choice.
-
-## Usage
-
-We recommend using [Ginkgo](https://github.com/onsi/ginkgo), a BDD testing framework for Go that we've found handy
-for organizing and running tests. You should be able to use any other testing framework you like, including Go's built-in
-`testing` package, but the examples you find here will be in Ginkgo and its accompanying assertions library,
-[gomega](https://onsi.github.io/gomega/)
-
-```go
-var _ = Describe("Basic Contract Interactions", func() {
-  var ( // Create variables that we're going to be using across test steps
-    suiteSetup    actions.SuiteSetup
-    networkInfo   actions.NetworkInfo
-    defaultWallet client.BlockchainWallet
-  )
-
-  It("Exercises basic smart contract usage", func() {
-    By("Deploying the environment", func() {
-      var err error
-      // SuiteSetup creates an ephemeral environment for the test, launching a simulated blockchain, an external adapter
-      // and as many chainlink nodes as you would like.
-      suiteSetup, err = actions.SingleNetworkSetup( 
-        environment.NewChainlinkCluster(0), // We're launching this test with 0 chainlnk nodes
-        client.DefaultNetworkFromConfig,    // Using the first network defined in our config file
-        tools.ProjectRoot,                  // The path of our config file.
-      )
-      Expect(err).ShouldNot(HaveOccurred())
-      networkInfo = suiteSetup.DefaultNetwork()
-      defaultWallet = networkInfo.Wallets.Default()
-    })
-
-    By("Deploying and using the storage contract", func() {
-      // Deploy a storage contract, all it does is store a value, then regurgitate that value when called for
-      storeInstance, err := suiteSetup.Deployer.DeployStorageContract(defaultWallet)
-      Expect(err).ShouldNot(HaveOccurred())
-
-      // Value we're going to store
-      testVal := big.NewInt(5)
-
-      // Set the contract value
-      err = storeInstance.Set(testVal)
-      Expect(err).ShouldNot(HaveOccurred())
-      // Retrieve the value
-      val, err := storeInstance.Get(context.Background())
-      // Make sure no errors happened, and the value is what we expect
-      Expect(err).ShouldNot(HaveOccurred())
-      Expect(val).To(Equal(testVal))
-     })
-  })
-
-  AfterEach(func() {
-    // Tears down the environment, deleting everything that the SuiteSetup launched, and collecting logs if the test failed
-    By("Tearing down the environment", suiteSetup.TearDown())
-  })
-})
-```
-
-The `SuiteSetup` does a lot of work for us, allowing us to specify how many chainlink nodes we want to deploy,
-what network we want to run on, and where to look for our config file. There will be quite a few calls creating
-`SuiteSetup`s in our examples.
-
-## Environments
-
-By default, the `TearDown()` method deletes the environment that was launched by the `SuiteSetup`. Sometimes that's not
-desired though, like when debugging failing tests. For that, there's a handy ENV variable, `KEEP_ENVIRONMENTS`.
-
-```sh
-KEEP_ENVIRONMENTS = Never # Options: Always, OnFail, Never
-```
-
-## Logs
-
-`TearDown()` also checks if the test has failed. If so, it builds a `logs/` directory, and dumps the logs and contents
-of each piece of the environment that was launched.

docs/networks/different_networks.md

@@ -7,13 +7,34 @@ parent: Networks
 
 # Using Different Networks
 
-See the `network_configs` in our [config.yml](../config.yml) file to see our list of supported networks. Most of them
+See the `network_configs` in our [config.yml](../../config.yml) file to see our list of supported networks. Most of them
 are different EVM chains, whether test nets, or simulated chains. Non-EVM chains are trickier, but we're actively working
 on integrating as many as we can.
 
 If you want to run your tests on a different network, you can supply it as an environment variable, `NETWORKS` or change
 the config file. Supply a comma-seperated list of networks you wish to run on.
 
 ```sh
-NETWORKS=ethereum_kovan,ethereum_kovan
+NETWORKS=ethereum_kovan,ethereum_geth
 ```
+
+or change the networks in your config file
+
+```yaml
+networks: # Selected network(s) for test execution
+    - "ethereum_kovan"
+    - "ethereum_geth"
+```
+
+## Non-EVM Networks
+
+You'll notice that our network support doesn't have much besides typical EVM based networks. We're actively working
+to expand to other network types however, and hope to have more to say on that soon.
+
+## Simulated vs Live Networks
+
+We've found it easiest and most effective to only use simulated networks when doing our testing, for a host of reasons
+(speed, wallet management, even testnet currencies can be tricky to get large amounts of, etc...) and generally we'd
+recommend you do the same. So, as of writing this, support for live test nets is a bit shaky. We'd obviously like to
+improve on this, but it's not high on our priority list at the moment. However, you're welcome to lend us a hand on this
+front by opening a PR!

docs/networks/multiple_networks.md

@@ -31,4 +31,4 @@ defaultNetwork := suiteSetup.DefaultNetwork() // Get the default network: the on
 This gives you 2 seperate networks to work with, of the type listed in the `NETWORKS` ENV variable. If it's two of the
 same simulated network, like `ethereum_geth,ethereum_geth`, then 2 simulated networks are launched and interacted with
 seperately. Avoid using a test net combination like `ethereum_kovan,ethereum_kovan`, which will probably lead to unexpected
-behaviors.
+behaviors.

docs/networks/networks.md

@@ -1,12 +1,30 @@
 ---
 layout: default
 title: Networks
-nav_order: 2
+nav_order: 3
 has_children: true
 permalink: docs/networks
 ---
 
 # Networks
 
 Most of the time we run our tests on `ethereum_geth`, a simulated ethereum chain that makes our tests fast and cheap.
-But some tests you'll want to run on other simulated chains, or even live test nets.
+But some tests you'll want to run on other simulated chains, or even live test nets. You can see an extensive amount of
+pre-configured networks defined in our [config.yml](../../config.yml) file. You can add more by adding to that list,
+adjusting config values as necessary.
+
+## Config Values
+
+| Config Value           | Type   | Description |
+|------------------------|--------|-------------|
+|  name                  | string | Human-readable name of the network
+|  chain_id              | int    | Chain ID number
+|  type                  | string | The type of chain, right now we only really have `evm` at the moment, but are expanding
+|  secret_private_keys   | bool   | Whether to look for private keys in you Kubernetes deployment or not. Default to false
+|  namespace_for_secret  | string | Which namespace to look for private keys in, probably `default`
+|  private_keys          | list   | List of private keys to use as wallets for tests. Usually the defaults for simulated chains.
+|  transaction_limit     | int    | A limit on how much gas to use in a transaction
+|  transaction_timeout   | time   | How long to wait before timing out on a transaction.
+|  minimum_confirmations | int    | How many block confirmations to wait before declaring a transaction as successful.
+|  gas_estimation_buffer | int    | A buffer to add to gas estimations if you want to ensure transactions going through
+|  block_gas_limit       | int    | The gas limit per-block for the network

docs/networks/special_networks.md

@@ -7,6 +7,7 @@ parent: Networks
 
 # Performance and Reorg Networks
 
-For running performance and chaos tests, use `ethereum_geth_performance`
+For running performance and chaos tests, use `ethereum_geth_performance`. This creates our usual simulated geth network,
+but with different settings tuned to allow for longer waits before transactions timeout.
 
-For running tests with reorganization scenarios, `ethereum_geth_reorg`
+For running tests with reorganization scenarios, `ethereum_geth_reorg`

docs/parallel_transactions.md

@@ -1,7 +1,7 @@
 ---
 layout: default
 title: Parallel Transactions
-nav_order: 5
+nav_order: 6
 has_children: false
 ---
 

docs/usage/suite_setup.md

@@ -0,0 +1,24 @@
+---
+layout: default
+title: Suite Setup
+nav_order: 1
+parent: Usage
+---
+
+The `SuiteSetup` interface provides a lot of convenient ways to setup and interact with your tests, and you should
+probably be using it for most, if not all of your test scenarios.
+
+```go
+suiteSetup, err = actions.SingleNetworkSetup( // Indicating we only want to deal with a single blockchain network
+  environment.NewChainlinkCluster(0),         // We're launching 0 chainlink nodes in this example
+  hooks.EVMNetworkFromConfigHook,             // Default, gets network settings
+  hooks.EthereumDeployerHook,                 // Default, creates a contract deployer for the network
+  hooks.EthereumClientHook,                   // Default, establishes client connection to the network
+  utils.ProjectRoot,                          // Default, the path of our config file.
+)
+Expect(err).ShouldNot(HaveOccurred())         // Make sure no errors happened
+```
+
+The `SuiteSetup` does a lot of work for us, allowing us to specify how many chainlink nodes we want to deploy,
+and where to look for our config file (if we have one). There will be quite a few calls creating `SuiteSetup`s in our
+examples.

docs/usage/tear_down.md

@@ -0,0 +1,20 @@
+---
+layout: default
+title: Tear Down
+nav_order: 99
+parent: Usage
+---
+
+## Environments
+
+By default, the `TearDown()` method deletes the environment that was launched by the `SuiteSetup`. Sometimes that's not
+desired though, like when debugging failing tests. For that, there's a handy ENV variable, `KEEP_ENVIRONMENTS`.
+
+```sh
+KEEP_ENVIRONMENTS = Never # Options: Always, OnFail, Never
+```
+
+## Logs
+
+`TearDown()` also checks if the test has failed. If so, it builds a `logs/` directory, and dumps the logs and contents
+of each piece of the environment that was launched.

docs/usage/usage.md

@@ -0,0 +1,15 @@
+---
+layout: default
+title: Usage
+nav_order: 2
+has_children: true
+permalink: docs/usage
+---
+
+## Ginkgo and Gomega
+
+We've been using [Ginkgo](https://github.com/onsi/ginkgo), a BDD testing framework for Go that we've found handy
+for organizing and running tests. You should be able to use any other testing framework you like, including Go's built-in
+`testing` package, but the examples you find here will be in Ginkgo and its accompanying assertions library,
+[Gomega](https://onsi.github.io/gomega/). Both of which are easily human readable however (part of why we like it) and
+shouldn't hurt your understanding of the framework at all.