Caliper 0.7.0 is very broken (#1729)

Caliper 0.7.0 is very broken, as we don't have any tests that test
either the npm packages or the Docker image before they get published we
have no way to detect this (luckily someone was trying to use the latest
release)

We need to publish a complete new version (0.7.1) and ditch the 0.7.0
docs completely publish 0.7.1 doc

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

Author: davidkel

.build/publish-caliper.sh

@@ -22,9 +22,13 @@ cp ./README.md ./packages/caliper-core/README.md
 cp ./README.md ./packages/caliper-fabric/README.md
 
 # distribute root package-lock file as npm-shrinkwrap file to packages before publishing
-cp ./package-lock.json ./packages/caliper-cli/npm-shrinkwrap.json
-cp ./package-lock.json ./packages/caliper-core/npm-shrinkwrap.json
-cp ./package-lock.json ./packages/caliper-fabric/npm-shrinkwrap.json
+# We can't do this because caliper-cli declares dependencies on caliper-core and caliper-fabric 
+# and the packaged shrinkwrap for caliper-cli will not be correct to resolve them as package-lock.json
+# is mono-repo aware but the published packages won't understand it in shrinkwrap.json so will create
+# invalid references. Doing this would force everyone to have to install all 3 packages manually.
+#cp ./package-lock.json ./packages/caliper-cli/npm-shrinkwrap.json
+#cp ./package-lock.json ./packages/caliper-core/npm-shrinkwrap.json
+#cp ./package-lock.json ./packages/caliper-fabric/npm-shrinkwrap.json
 
 cd ./packages/caliper-publish/
 npm ci

docs/source/concepts/logging-control.md

@@ -8,7 +8,7 @@ Caliper builds on the [winston](https://github.com/winstonjs/winston) logger mod
 
 The first two points can be achieved through the [runtime configuration](runtime-config.md) mechanism of Caliper. So make sure that you are familiar with the different way of overriding runtime settings before reading on. The examples below only set the different options through the command line. Naturally, any other setting source could be used.
 
-The runtime configuration settings corresponding to logging reside under the `caliper-logging` key hierarchy. See the `caliper.logging` section of the [default configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/config/default.yaml) bundled with Caliper for the general structure of the settings.
+The runtime configuration settings corresponding to logging reside under the `caliper-logging` key hierarchy. See the `caliper.logging` section of the [default configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/config/default.yaml) bundled with Caliper for the general structure of the settings.
 
 ## Customizing the logging style
 

docs/source/connectors/fabric-config.md

@@ -84,7 +84,7 @@ peers:
 Caliper has it's on configuration file and contains configuration options which have an effect on the fabric adapter.
 These runtime properties can be set through Caliper’s [runtime configuration mechanism](../concepts/runtime-config.md). Note that this caliper runtime configuration file is a different file to the network configuration file discussed later.
 
-For the available settings, see the `caliper.fabric` section of the [default configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/config/default.yaml) and its embedded documentation.
+For the available settings, see the `caliper.fabric` section of the [default configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/config/default.yaml) and its embedded documentation.
 
 The above settings are processed when starting Caliper. Modifying them during testing will have no effect. However, you can override the default values *before Caliper* starts from the usual configuration sources. In the following example the `localhost` property applies only when binding with Fabric 2.2.
 
@@ -117,11 +117,11 @@ See the [corresponding documentation](../concepts/workload-module.md/#initialize
 
 The last argument of the function is a `sutContext` object, which is a platform-specific object provided by the backend blockchain’s connector. The context object provided by this connector is a `FabricConnectorContext` instance but this doesn’t provide anything of use at this time.
 
-For the current details/documentation of the API, refer to the [source code](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-fabric/lib/FabricConnectorContext.js).
+For the current details/documentation of the API, refer to the [source code](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-fabric/lib/FabricConnectorContext.js).
 
 ### The `submitTransaction` function
 
-The `sutAdapter` object received (and saved) in the `initializeWorkloadModule` function is of type `[ConnectorInterface](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/core/connector-interface.js)`. Its `getType()` function returns the `fabric` string value.
+The `sutAdapter` object received (and saved) in the `initializeWorkloadModule` function is of type `[ConnectorInterface](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/core/connector-interface.js)`. Its `getType()` function returns the `fabric` string value.
 
 The `sendRequests` method of the connector API allows the workload module to submit requests to the SUT. It takes a single parameter: an object or array of objects containing the settings of the requests.
 
@@ -158,7 +158,7 @@ await this.sutAdapter.sendRequests(requestSettings);
 
 ## Gathered TX data
 
-The previously discussed `sendRequests` function returns the result (or an array of results) for the submitted request(s) with the type of [TxStatus](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/core/transaction-status.js). The class provides some standard and platform-specific information about its corresponding transaction.
+The previously discussed `sendRequests` function returns the result (or an array of results) for the submitted request(s) with the type of [TxStatus](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/core/transaction-status.js). The class provides some standard and platform-specific information about its corresponding transaction.
 
 The standard data provided are the following:
 - `GetID():string` returns the transaction ID.

docs/source/connectors/writing-connectors.md

@@ -60,7 +60,7 @@ You should treat a connector implementation process as a full-fledged Node.js pr
 
 ### The connector interface
 
-Once you add the `@hyperledger/caliper-core` package (or one of its specific versions) as your project dependency, you will gain access to its exported `ConnectorInterface` class, which declares the following [interface](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/core/connector-interface.js):
+Once you add the `@hyperledger/caliper-core` package (or one of its specific versions) as your project dependency, you will gain access to its exported `ConnectorInterface` class, which declares the following [interface](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/core/connector-interface.js):
 
 ```sh
 class ConnectorInterface extends EventEmitter {
@@ -137,13 +137,13 @@ The interface is detailed in the next subsection, but for now, keep the followin
 
 `sendRequests`
 
-- **Description:** This method is the hot path of the connector, called in the worker processes by the workload modules of the rounds. The method must accept one or multiple settings objects pertaining to the request or requests that must be sent to the SUT. The connector doesn’t have to preserve the order of execution for the requests, unless the target SUT type supports such request batches. The connector must gather at least the start time, finish time, and final status (successful or failed) of every request through [TxStatus](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/core/transaction-status.js) instances.
+- **Description:** This method is the hot path of the connector, called in the worker processes by the workload modules of the rounds. The method must accept one or multiple settings objects pertaining to the request or requests that must be sent to the SUT. The connector doesn’t have to preserve the order of execution for the requests, unless the target SUT type supports such request batches. The connector must gather at least the start time, finish time, and final status (successful or failed) of every request through [TxStatus](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/core/transaction-status.js) instances.
 - **Return type:** *Promise<TxStatus|TxStatus[]>*
 - **Returns:** The promise of one or more request execution results that will resolve upon method completion.
 
 #### Exposed events
 
-The connector must expose the following events with names matching the defined [constants](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-core/lib/common/utils/constants.js) for them. Without these events the Caliper scheduling mechanism won’t function correctly, and other components might also rely on them (like TX monitors).
+The connector must expose the following events with names matching the defined [constants](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-core/lib/common/utils/constants.js) for them. Without these events the Caliper scheduling mechanism won’t function correctly, and other components might also rely on them (like TX monitors).
 
 `txsSubmitted`
 
@@ -373,21 +373,21 @@ If you would like to expose you connector to a wider user-base, then you should
 
     *Don’t hesitate to reach out to the project maintainers on Rocket.Chat (`#caliper-contributors` channel) who will help you with the integration.*
 
-The integration consists of the following steps (for an example, see the `[caliper-fabric](https://github.com/hyperledger-caliper/caliper/tree/v0.6.0/packages/caliper-fabric)` connector):
+The integration consists of the following steps (for an example, see the `[caliper-fabric](https://github.com/hyperledger-caliper/caliper/tree/v0.7.1/packages/caliper-fabric)` connector):
 
 1. Create a `caliper-fast-ledger` directory in the `packages` directory of the repository. This will contain your connector implementation.
 2. Update your metadata in your own `package.json` file accordingly. The package name should be scoped: `@hyperledger/caliper-fast-ledger`.
-3. If your connector supports binding, then you should list the dynamic packages in the `devDependencies` section, so they’re not automatically installed with Caliper (since the users will rebind it anyway). Also, add your connector’s binding specifications to the built-in [binding configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-cli/lib/lib/config.yaml).
+3. If your connector supports binding, then you should list the dynamic packages in the `devDependencies` section, so they’re not automatically installed with Caliper (since the users will rebind it anyway). Also, add your connector’s binding specifications to the built-in [binding configuration file](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-cli/lib/lib/config.yaml).
 4. Add your new directory path to the root `lerna.json` file, under the `packages` section. This will ensure that your package is bootstrapped correctly for other developers (and for testing, publishing, etc.).
-5. Add your new package (by name) to the [Caliper CLI dependencies](https://github.com/hyperledger-caliper/caliper/blob/v0.6.0/packages/caliper-cli/package.json).
+5. Add your new package (by name) to the [Caliper CLI dependencies](https://github.com/hyperledger-caliper/caliper/blob/v0.7.1/packages/caliper-cli/package.json).
 6. List your connector as a built-in connector in the `caliper-utils.js` module, under the `BuiltinConnectors` variable:
 ```sh
 const BuiltinConnectors = new Map([
  ['fast-ledger', '@hyperledger/caliper-fast-ledger'],
  // other connectors...
 ]);
 ```
-7. It is highly recommended to provide [integration tests](https://github.com/hyperledger-caliper/caliper/tree/v0.6.0/packages/caliper-tests-integration) for your connector.
+7. It is highly recommended to provide [integration tests](https://github.com/hyperledger-caliper/caliper/tree/v0.7.1/packages/caliper-tests-integration) for your connector.
 8. Make sure that every code-related artifact (mostly `.js`, `.yaml` and `.md` files) contains the appropriate license header!
 9. And you’re done! Now users can refer to the connector as `fast-ledger` in their network configuration files. The connector package will be published automatically upon every merged PR.
 

docs/source/getting-started/installing-caliper.md

@@ -40,7 +40,7 @@ The entry point of the CLI is the `caliper` binary. You can confirm whether the
 
 ```sh
 user@ubuntu:~/caliper-benchmarks$ npx caliper --version
-v0.6.0
+v0.7.1
 ```
 
 The CLI provides multiple commands to perform different tasks. To check the available commands and their descriptions, execute:
@@ -227,7 +227,7 @@ But why is all this important to you? Because Caliper is still in its pre-releas
 
 Let’s see the three types of version numbers you will encounter:
 
-- `0.6.0`: Version numbers of this form denote releases deemed *stable* by the maintainers. Such versions have a corresponding GitHub tag, both in the `caliper` and `caliper-benchmarks` repositories. Moreover, the latest stable version is documented by the matching version of the documentation page. So make sure to align the different versions if you run into some issue.
+- `0.7.1`: Version numbers of this form denote releases deemed *stable* by the maintainers. Such versions have a corresponding GitHub tag, both in the `caliper` and `caliper-benchmarks` repositories. Moreover, the latest stable version is documented by the matching version of the documentation page. So make sure to align the different versions if you run into some issue.
 - `0.6.1-unstable-20240422122901`: Such version “numbers” denote unstable releases that are published upon every merged pull request (hence the timestamp at the end), and eventually will become a stable version, e.g., `0.6.1`. This way you always have access to the NPM (and Docker) artifacts pertaining to the `main` branch of the repository. Let’s find and fix the bugs of new features before they make it to the stable release!
 - `unstable`: This is the very latest unstable release that has been published and would correspond to a version also published as `0.6.1-unstable-<some date>`. This lets you quickly work with the very latest code from the `main` branch.
 
@@ -250,14 +250,14 @@ The following tools may be required depending on which SUT and version you bind
 
     *this is the highly recommended way to install Caliper for your project. Keeping the project dependencies local makes it easier to setup multiple Caliper projects. Global dependencies would require re-binding every time before a new benchmark run (to ensure the correct global dependencies).*
 
-1. Install the Caliper CLI as you would any other NPM package. It is highly recommended to explicitly specify the version number, e.g., `@hyperledger/caliper-cli@0.6.0`
+1. Install the Caliper CLI as you would any other NPM package. It is highly recommended to explicitly specify the version number, e.g., `@hyperledger/caliper-cli@0.7.1`
 2. Bind the CLI to the required platform SDK (e.g., `fabric` with the `fabric-gateway` SDK).
 3. Invoke the local CLI binary (using [npx](https://www.npmjs.com/package/npx)) with the appropriate parameters. You can repeat this step for as many benchmarks as you would like.
 
 Putting it all together:
 
 ```sh
-user@ubuntu:~/caliper-benchmarks$ npm install --only=prod @hyperledger/caliper-cli@0.6.0
+user@ubuntu:~/caliper-benchmarks$ npm install --only=prod @hyperledger/caliper-cli@0.7.1
 user@ubuntu:~/caliper-benchmarks$ npx caliper bind --caliper-bind-sut fabric:fabric-gateway
 user@ubuntu:~/caliper-benchmarks$ npx caliper launch manager \
     --caliper-workspace . \
@@ -268,7 +268,7 @@ user@ubuntu:~/caliper-benchmarks$ npx caliper launch manager \
 We could also perform the binding automatically when launching the manager process (note the extra parameter for `caliper launch manager`):
 
 ```sh
-user@ubuntu:~/caliper-benchmarks$ npm install --only=prod @hyperledger/caliper-cli@0.6.0
+user@ubuntu:~/caliper-benchmarks$ npm install --only=prod @hyperledger/caliper-cli@0.7.1
 user@ubuntu:~/caliper-benchmarks$ npx caliper launch manager \
     --caliper-bind-sut fabric:fabric-gateway \
     --caliper-workspace . \
@@ -298,7 +298,7 @@ There are some minor differences compared to the local install:
 4. You can omit the `npx` command, since `caliper` will be in your `PATH`.
 
 ```sh
-user@ubuntu:~$ npm install -g --only=prod @hyperledger/caliper-cli@0.6.0
+user@ubuntu:~$ npm install -g --only=prod @hyperledger/caliper-cli@0.7.1
 user@ubuntu:~$ caliper bind --caliper-bind-sut fabric:2.2 --caliper-bind-args=-g
 user@ubuntu:~$ caliper launch manager \
     --caliper-workspace ~/caliper-benchmarks \
@@ -342,7 +342,7 @@ Parts of starting a Caliper container (following the recommendations above):
 
 !!! note
 
-    *the **latest** tag is **not supported**, i.e, you explicitly have to specify the image version you want: hyperledger/caliper:0.6.0, similar to the recommended approach for the [NPM packages](#versioning-semantics).*
+    *the **latest** tag is **not supported**, i.e, you explicitly have to specify the image version you want: hyperledger/caliper:0.7.1, similar to the recommended approach for the [NPM packages](#versioning-semantics).*
 
 Putting it all together, split into multiple lines for clarity, and naming the container `caliper`:
 
@@ -352,7 +352,7 @@ user@ubuntu:~/caliper-benchmarks$ docker run \
     -e CALIPER_BIND_SUT=fabric:fabric-gateway \
     -e CALIPER_BENCHCONFIG=benchmarks/scenario/simple/config.yaml \
     -e CALIPER_NETWORKCONFIG=networks/fabric/test-network.yaml \
-    --name caliper hyperledger/caliper:0.6.0 launch manager
+    --name caliper hyperledger/caliper:0.7.1 launch manager
 ```
 
 !!! note
@@ -369,7 +369,7 @@ version: '2'
 services:
     caliper:
         container_name: caliper
-        image: hyperledger/caliper:0.6.0
+        image: hyperledger/caliper:0.7.1
         command: launch manager
         environment:
         - CALIPER_BIND_SUT=fabric:fabric-gateway

docs/source/index.md

@@ -30,7 +30,7 @@ Sample benchmarks that may be used by Caliper are hosted on a companion [GitHub
 
 !!! note "Important"
 
-    *make sure that the version/tag of the benchmark repository matches the version of Caliper you are using! For example, if you are using Caliper v0.6.0, then `checkout` the `v0.6.0` tag after cloning the benchmark repository. The `main` branch of the benchmark repository corresponds to the latest `unstable` Caliper version.*
+    *make sure that the version/tag of the benchmark repository matches the version of Caliper you are using! For example, if you are using Caliper v0.7.1, then `checkout` the `v0.7.1` tag after cloning the benchmark repository. The `main` branch of the benchmark repository corresponds to the latest `unstable` Caliper version.*
 
 ## How to Contribute
 Every contribution is welcome! See the [Contributing](getting-started/contributing.md) page for details.

docs/source/tutorial/fabric.md

@@ -35,7 +35,7 @@ Create a folder named **caliper-workspace** at the same level as the **fabric-sa
 Caliper installation and use will be based on a local npm installation. Within the **caliper-workspace** directory, install caliper CLI using the following terminal command:
 
 ```sh
-npm install --only=prod @hyperledger/caliper-cli@0.6.0
+npm install --only=prod @hyperledger/caliper-cli@0.7.1
 ```
 
 Bind the SDK using the following terminal command: