Buildfixes, trying to unblock current builds (#777)

* make example/test script more robust for meager github actions environment
* improve wording around op template resolution
* remove blocking issues github actions plugin, since it is broken

.github/workflows/blocking_issues.yml

@@ -1,15 +0,0 @@
-name: Blocking Issues
-
-on:
-  issues:
-    types: [closed]
-  pull_request_target:
-    types: [opened, edited]
-
-jobs:
-  blocking_issues:
-    runs-on: ubuntu-latest
-    name: Checks for blocking issues
-
-    steps:
-      - uses: Levi-Lesches/blocking-issues@v1.1

adapters-api/src/main/resources/workload_definition/README.md

@@ -63,17 +63,21 @@ The process of loading a workload definition occurs in several discrete steps du
 session:
 
 1. The workload file is loaded.
-2. Template variables are interposed.
+2. Template variables from the activity parameters are interposed into the raw contents of the
+   file.
 3. The file is deserialized from its native form into a raw data structure.
 4. The raw data structure is transformed into a normalized data structure according to the Op
    Template normalization rules.
-5. The data is provided to the ParsedOp API for use by the developer.
+5. Each op template is then denormalized as a self-contained data
-6. The DriverAdapter is loaded which understands the op fields provided in the op template.
+   structure, containing all the provided bindings, params, and tags from the upper layers of the
-7. The DriverAdapter uses its documented rules to determine which types of native driver operations
+   doc structure.
+6. The data is provided to the ParsedOp API for use by the developer.
+7. The DriverAdapter is loaded which understands the op fields provided in the op template.
+8. The DriverAdapter uses its documented rules to determine which types of native driver operations
    each op template is intended to represent. This is called **Op Mapping**.
-8. The DriverAdapter uses the identified types to create dispensers of native driver operations.
+9. The DriverAdapter (via the selected Op Mapper) uses the identified types to create dispensers of
-   This is called **Op Dispensing**.
+   native driver operations. This is called **Op Dispensing**.
-9. The op dispensers are arranged into an indexed bank of op sources according to the specified
+10. The op dispensers are arranged into an indexed bank of op sources according to the specified
    ratios and or sequencing strategy. From this point on, NoSQLBench has the ability to
    construct an operation for any given cycle at high speed.
 

nbr-examples/src/test/resources/scripts/examples/extension_histostatslogger.js

@@ -18,16 +18,14 @@ activitydef = {
     "alias" : "testhistostatslogger",
     "driver" : "diag",
     "cycles" : "50000",
-    "threads" : "20",
+    "threads" : "5",
-    "interval" : "2000",
+    "rate" : "100.0",
-    "targetrate" : "10000.0",
     "op" : "noop"
 };
 
 histostatslogger.logHistoStats("testing extention histostatslogger", ".*", "logs/histostats.csv", "0.5s");
 print("started logging to logs/histostats.csv for all metrics at 1/2" +
     " second intervals.");
-
 scenario.start(activitydef);
-scenario.waitMillis(2000);
+scenario.waitMillis(4000);
 scenario.stop(activitydef);