outsource getcustomscripts to container, fix identifier env replacing

Author: Georg Martin Weber

hull-vidispine-addon/Chart.yaml

@@ -3,4 +3,4 @@ apiVersion: v1
 appVersion: 1.30.0
 description: hull-vidispine-addon
 name: hull-vidispine-addon
-version: 1.30.0
+version: 1.30.1

hull-vidispine-addon/README.md

@@ -173,6 +173,7 @@ Describes a particular entity on a subresource on an endpoint which is communica
 | `getQueryParams` | Query Parameters to add to the Url of a GET command, for example for filtering from a list of objects. This is a key-value style dictionary<br><br>It is a very common scenario that you want to refer to the __identifier__ in your query parameters in case the API identifies objects via query parameter filtering. For this scenario you can use the `$identifier` placeholder in your values and this placeholder will be replaced with the actual identifier (either the value of `identifier` or the objects key if `identifier` is not provided). | | `GET` 
 | `getUriExcludeIdentifier` | Normally in a REST style API GET calls include the identifier of the object as the last segment of the URI. By setting this to `true` GET calls will not include the identifier segment. The use of this is for some specific APIs the usual REST style is not used and it may be required to make a GET call to the object resource and process the result via `getCustomScript` functionality or get the object via query parameters with `getQueryParams`.  | `false` | `GET`
 | `getCustomScript` | Offers the possibility to provide a custom Powershell script that further processes the result of the GET call. May be used in conjunction with setting `getUriExcludeIdentifier` to true so you can take custom actions given all found existing objects.<br><br>Using a custom script, variables from the outer script can be read and used within the script, so you may find it useful to access the following local variables in the script: <br><br>`$responseGet`: the string result of the GET call<br>`$apiEndpoint`: the apiEndpoint field of the subresource<br>`$entity`: the entity configuration options<br><br>As a further usage improvement, you can add additional properties (names need to be different from well-known properties, best add a `_` prefix to the variable name) to `$entity` configuration which contain Helm templating expressions that are resolved when rendering the chart. Then access these variables via the `$entity` object in the script. Here is an example:<br><br>`entity:`<br>&#160;&#160;`_helm_chart_name_:`&#160;`_HT!{{ (index . "$").Chart.Name }}`<br>&#160;&#160;`_helm_chart_version_:`&#160;`_HT!{{ (index . "$").Chart.Version }}`<br><br> where in the `getCustomScript` you can simply access the current Helm chart name with `$entity._helm_chart_name_` and version with `$entity._helm_chart_version_`<br><br>        The script can return either a boolean value for general success of the GET call (translating to a 200 or 404 status code) or it may return a JSON with additional information useful for adjusting a subsequent PUT or DELETE call. The JSON is allowed to return the following fields that will update the local PowerShell variables accordingly if present:<br><br>`statusCode`: sets the virtual statusCode for further processing<br>`uriPut`: sets the full URI used for putting the `config` content.<br>`uriDelete`: sets the full URI used for deleting the entity.<br>`identifier`: sets the `identifier` for all further PUT or DELETE operations.<br><br>A JSON returned from `getCustomScript` may look like this: `{"statusCode":200, "uriPut":"https://host.com/API/notifications/groups/NOTIFICATION-VX-99"}`<br><br>An example of this coming together is the usage of notifications in VidiCore, to find out whether a particular notification needs to be updated it is required to get a list of all existing notifications and update the POST/DELETE uri to correctly address the targeted resource. See the VidiCore or MediaPortal Helm Chart for the implementation of this. | | `GET`
+| `getCustomScriptFromFile` | Provides the possibility to load a custom GET script from a file instead of specifying it inline as with `getCustomScript`. The main reason to to this is to pack the script with the `hull-integration` container to not clutter the `hull-vidispine-addon.yaml` with large scripts. Functionality-wise it behaves the same as `getCustomScript`. Note that when both `getCustomScript` and `getCustomScriptFromFile` are specified, the `getCustomScript` script content takes precedence. | | `GET`
 | `noGet` | If `true` the check for existence is skipped and a PUT or POST is done directly. This is treated same as receiving a 404 on the GET request. | `false` | `GET`
 | `customGetScriptJsonResponseConfigReplacements` | An optional dictionary with key value pairs where the keys specify placeholders that are supposed to be contained in the `config` contents and values specify keys in a JSON response from `getCustomScript` which are supposed to be set by the script. <br><br> The idea behind this setting is to allow reading custom data from an API, store the results in a JSON key value dictionary and use the values to dynamically modify the `config` contents. It only works if a) a `getCustomScript` is used, b) the response JSON from the script populates keys with values, c) the `config` contains placeholder keys that are substituted with the JSON response values.<br><br>As an example let us assume a case where it is not possible to address a particular object instance via a GET call with an `identifier` because the `identifier` was dynamically created by a prior call and it is unknown if the object already exists or not. However it is known that for example a `name` property exists on the instances which is also unique for all object instances. To find out if an instance already exists, it may be possible to get a list of all objects of a particular kind and filter them via their `name` property in order to find the instance in question if it already exists, this would be the content of a `customGetScript`. Thus the JSON response from `getCustomScript` could look like this: `{"statusCode":200, "identifier":"123923213123"` in case an instance was already found via its name. Now it becomes possible to setup the <br><br>`customGetScriptJsonResponseConfigReplacements:`<br>&#160;&#160;`'$$identifier$$':`&#160;`identifier`<br><br>and a<br><br>`config:`<br>&#160;&#160;`id:`&#160;`'$$identifier$$'`<br>&#160;&#160;`value:`&#160;`something`<br><br>The value of `$$identifier$$` is then replaced in the `config` and now when doing a PUT call the correct object is being updated:<br><br>`config:`<br>&#160;&#160;`id:`&#160;`'123923213123'`<br>&#160;&#160;`value:`&#160;`something`<br><br> | | `GET`
 | `readConfigFromFile` | Allows to either map complete file contents to the `config` value or the contents from a particular JSON key from a file to `config`. The content of this field if provided must be a dictionary which can have the following fields: <br><br>`path`:  mandatory and points to the mounted file's path, the source file can be of any text format. Optionally you can additionally specify `putPath` and/or `postPath` to use different source files depending on PUT or POST case. Note that when specifying `putPath` and/or `postPath` you also need to specify `path` which is resorted to in case the PUT or POST case is not matched with a `putPath` or `postPath`<br> `key`: optional and if specified declares the source files JSON key to import from, for this to work the source file must be a JSON file.<br><br>To use this feature, the file being refered to needs to be mounted into the `hull-install` or `hull-configure` job's pod via providing an additional `volume` and `volumeMount`. | | `POST`<br>`PUT` | `readConfigFromFile:`<br>&#160;&#160;`path:`&#160;`workflow-deploy.json`