Fix contributing.md

- add binding `gateway` (to replace `fabric-gateway`) and make this the
default in the docs
- change the integration tests to bind to gateway instead of 2.4

Signed-off-by: Dave Kelsey <d_kelsey@uk.ibm.com>

CONTRIBUTING.md

@@ -7,4 +7,4 @@ This guideline intends to make contribtuions to Caliper easier by:
 
 If you have further suggestions about improving the guideline, then you can follow the presented workflow to make your contribution.
 
-Jump to [Contributing documentation](https://hyperledger.github.io/caliper/v0.6.0/getting-started/contributing.md) to get started on your journey.
+Jump to [Contributing documentation](https://hyperledger.github.io/caliper/v0.6.0/contributing) to get started on your journey.

docs/source/connectors/fabric-config.md

@@ -51,7 +51,7 @@ It is confirmed that a 2.2 Fabric SDK is compatible with 2.2 and later Fabric SU
 
 ### Binding with Fabric Gateway Client SDK
 
-To bind with this client sdk, use `fabric:fabric-gateway`. This is now the preferred SDK to use given that Fabric 2.2 and earlier is now not in LTS and as such the Fabric 1.4 and 2.2 SDKs are now deprecated.
+To bind with this client sdk, use `fabric:gateway`. This is now the preferred SDK to use given that Fabric 2.2 and earlier is now not in LTS and as such the Fabric 1.4 and 2.2 SDKs are now deprecated.
 
 Only Fabric 2.4 and later with the Peer Gateway capability enabled (which is the default setting for a Fabric peer) can be used so for older versions of Hyperledger Fabric you cannot bind with this client SDK.
 
@@ -73,7 +73,7 @@ Network builders and providers should generate connection profiles (for example
 
 Unfortunately the documentation provided by Hyperledger Fabric is more focused on static connection profiles rather than dynamic connection profiles and your aim should be to create the simpler and smaller dynamic connection profile.
 
-With the introduction of using the Peer Gateway rather than the traditional node sdks (1.4 and 2.2) caliper has introduced the concept of declaring peers in an organization within the network configuration file as an alternative to connection profiles. This provides a simple way to describe either peers to discover from (when binding to Fabric 1.4 or 2.2, for Fabric 1.4 you must enable the gateway option as it won’t work otherwise as discovery is not supported with the Fabric 1.4 binding when the gateway option is not enabled) or the peer to be used as a gateway into the Fabric network (when binding to Fabric 2.4). An example of a peers section in the network configuration is
+With the introduction of using the Peer Gateway rather than the traditional node sdks (1.4 and 2.2) caliper has introduced the concept of declaring peers in an organization within the network configuration file as an alternative to connection profiles. This provides a simple way to describe either peers to discover from (when binding to Fabric 1.4 or 2.2, for Fabric 1.4 you must enable the gateway option as it won’t work otherwise as discovery is not supported with the Fabric 1.4 binding when the gateway option is not enabled) or the peer to be used as a gateway into the Fabric network (when binding to Fabric 2.4/2.5/gateway). An example of a peers section in the network configuration is
 
 ```sh
 peers:
@@ -433,7 +433,7 @@ The following sections detail each part separately. For a complete example, plea
           grpc.http2.max_pings_without_data: 0
           grpc.keepalive_permit_without_calls: 1
   ```
-  
+
   Each organization must have <code>mspid</code>, <code>identities</code> and either <code>connectionProfile</code> or <code>peers</code> provided and at least 1 certificate or wallet definition in the identities section so that at least 1 identity is defined
   <ul>
     <li>
@@ -510,7 +510,7 @@ The following sections detail each part separately. For a complete example, plea
         <ul>
         <li>a peer to discover the network from when bound to Fabric 2.2 or Fabric 1.4 in conjunction with using the gateway enabled option
         </li>
-        <li>a gateway peer when bound to Fabric 2.4</li>
+        <li>a gateway peer when bound to Fabric gateway</li>
         </ul>
 
         This option removes the need for connection profiles but the Fabric network must be set up correctly to allow the network to be discovered. These entries are the equivalent of a dynamic connection profile but in a more compact and easier form.
@@ -607,7 +607,7 @@ The following sections detail each part separately. For a complete example, plea
         ```
         </details>
         </li>
-        
+
       </details>
     </li>
     <li>
@@ -1053,7 +1053,7 @@ organizations:
             -----BEGIN CERTIFICATE-----
             ...
             -----END CERTIFICATE-----
-```            
+```
 
 ## License
 

packages/caliper-cli/lib/lib/config.yaml

@@ -29,14 +29,14 @@ settingProfiles:
 sut:
     # Specifies the available SDK bindings and their Node.js-specific install settings
     # IMPORTANT:
-    # The Integration tests cache all the SUT bindings EXCEPT for the fabric:2.4 binding. Therefore
+    # The Integration tests cache all the SUT bindings EXCEPT for the fabric:gateway binding. Therefore
     # for those bindings if you want to update a binding with new version dependencies you need to
     # create a new version and update the integration tests explicitly to reference this new version.
     # For example if the current version of the fabric 2.2 binding is 2.2.14 and you want to update
     # the binding to include a new level of dependencies, you must create a 2.2.15 binding and update
     # the integration tests to reference this.
-    # The exception is fabric:2.4 which isn't cached in the integration tests. This means you can modify
-    # the 2.4 key without creating a new version and the integration tests will automatically pick it up.
+    # The exception is fabric:gateway which isn't cached in the integration tests. This means you can modify
+    # the gateway key without creating a new version and the integration tests will automatically pick it up.
     fabric:
         # The name/key of the SDK binding
         1.4: &fabric-sdk-v1
@@ -51,6 +51,7 @@ sut:
         2.5: *fabric-gateway
         3: *fabric-gateway
         fabric-gateway: *fabric-gateway
+        gateway: *fabric-gateway
 
     ethereum:
         1.2.1:

packages/caliper-tests-integration/fabric_tests/run.sh

@@ -112,10 +112,10 @@ if [[ ${rc} != 0 ]]; then
     exit ${rc};
 fi
 
-# BIND with 2.4 SDK (which is the same as 2.5, 3, fabric-gateway), using the package dir as CWD
+# BIND with gateway SDK (which is the same as 2.4, 2.5, 3), using the package dir as CWD
 # Note: do not use env variables for unbinding settings, as subsequent launch calls will pick them up and bind again
-# Note: Fabric 2.4 binding is NOT cached in CI. This binding is lightweight so doesn't take much time and allows the 2.4 binding to be modified in the config.yaml binding file
-export FABRIC_VERSION=2.4
+# Note: Fabric gateway binding is NOT cached in CI. This binding is lightweight so doesn't take much time and allows the gateway binding to be modified in the config.yaml binding file
+export FABRIC_VERSION=gateway
 export NODE_PATH="$SUT_DIR/uncached/v$FABRIC_VERSION/node_modules"
 if [[ "${BIND_IN_PACKAGE_DIR}" = "true" ]]; then
     mkdir -p $SUT_DIR/uncached/v$FABRIC_VERSION