resilient-sdk#

Python SDK for developing Apps for IBM SOAR

Installation#

To install the IBM SOAR SDK, execute the following command:

$ pip install resilient-sdk

Configuration#

Similar to our resilient-circuits library, the SDK requires an app.config created in the default location: ~/.resilient with the following minimum configurations:

[resilient]
host=my_soar_instance.ibm.com
org=Test Organization
api_key_id=<id>
api_key_secret=<secret>
cafile=false

Note

Commands that interact with the SOAR platform support the --config|-c argument, which precedes the default location. For example:

$ resilient-sdk clone -r "Display name of Rule" "Cloned Rule display name" -c path/to/my/custom_file.config

Using the SDK#

Python SDK for developing IBM SOAR Apps that provides various subcommands to help with development

usage:
$ resilient-sdk <subcommand> ...
$ resilient-sdk -v <subcommand> ...
$ resilient-sdk codegen -p <name_of_package> -m 'fn_custom_md' -c '/usr/custom_app.config'
$ resilient-sdk -h

options:
-h, --help			show this help message and exit
-v, --verbose			Set the log level to DEBUG

codegen#

Generates boilerplate code used to begin developing an app.

usage:
$ resilient-sdk codegen -p <name_of_package> -m 'fn_custom_md' --rule 'Rule One' 'Rule Two' -i 'custom incident type'
$ resilient-sdk codegen -p <name_of_package> -m 'fn_custom_md' --rule 'Rule One' 'Rule Two' --settings <path_to_custom_sdk_settings_file>
$ resilient-sdk codegen -p <name_of_package> -m 'fn_custom_md' -c '/usr/custom_app.config'
$ resilient-sdk codegen -p <path_current_package> --reload --workflow 'new_wf_to_add'
$ resilient-sdk codegen -p <path_current_package> --poller
$ resilient-sdk codegen -p <path_current_package> --gather-results
$ resilient-sdk codegen -p <path_current_package> --gather-results '/usr/custom_app.log' -f 'func_one' 'func_two'

options:
-h, --help			show this help message and exit
-a, --artifacttype		API names of artifact types to include 
-d, --datatable			API names of datatables to include 
-f, --function			API names of functions to include 
-fd, --field			API names of custom fields to include 
-i, --incidenttype		Display names of custom incident types to include (surrounded by "") 
-m, --messagedestination	API names of message destinations to include 
-pb, --playbook			API names of playbooks to include. Only IBM SOAR >= v44.0 supported 
-r, --rule			Display names of rules to include (surrounded by "") 
-s, --script			Display names of scripts to include (surrounded by "") 
-t, --task			API names of custom tasks to include 
-w, --workflow			API names of workflows to include 
-e, --exportfile		Path to a local (.res or .resz) export file 
-o, --output			Path to output directory. Uses current dir by default 
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
--settings			Path to .sdk_settings.json file. Default is ~/.resilient/.sdk_settings.json 
-p, --package			(required) Name of new or path to existing package 
-re, --reload			Reload customizations and create new customize.py 
-pr, --poller			Build template files for a poller 
--gather-results		Uses the log file specified or if no path specified use the default at '~/.resilient/logs/app.log' to try gather results. Only Python >= 3.6 supported

Basic Usage#

The codegen command is your entry point with resilient-sdk to creating apps. Once one or more functions and an associated message destination are created in the SOAR UI, running resilient-sdk codegen will generate templated python code for your app development.

The following assumes a function fn_my_function on destination fn_my_app exists in your SOAR system. It also assumes that you’ve already completed the Configuration section above and have a fresh Python environment to work in.

To generate an app to implement fn_my_function in a new app called fn_my_app, run the following command:

resilient-sdk codegen -p fn_my_app -f fn_my_function -m fn_my_app

Note

Notice the -p or --package argument in the command above. This argument specifies the path to the package and is used throughout the resilient-sdk suite of commands. When used here to generate a new app, it will create a new directory in your working directory and will generate the contents of the app within that newly created directory.

Navigate to the newly created fn_my_app directory and have a look around. Notice that some files at the root level pertain to app details. In particular, the setup.py file should get strong attention. The setup.py file is where the app’s details are defined and govern much of what will appear when the app is installed in SOAR.

Here is a full overview of the app’s structure with highlights given to the files that require manual edits:

.
├── data
├── doc
│   └── screenshots
│       └── main.png
├── entrypoint.sh
├── fn_my_app
│   ├── LICENSE                     // LICENSE file for your project
│   ├── __init__.py
│   ├── components
│   │   ├── __init__.py
│   │   └── func_fn_my_function.py  // the function's implementation
│   └── util
│       ├── __init__.py
│       ├── config.py               // the configuration section of this app in app.config
│       ├── customize.py
│       ├── data
│       │   └── export.res
│       └── selftest.py             // implementation of this app's configuration test
├── icons
│   ├── app_logo.png                // icons displayed when installed on app host
│   └── company_logo.png
├── tests                           // optional unit tests
├── Dockerfile
├── MANIFEST.in
├── README.md                       // updated via resilient-sdk docgen to document use of the app
├── apikey_permissions.txt          // defines the API key permissions that will be generated when the app is installed
├── setup.py                        // app details; this file is key in defining the appearance of your app
└── tox.ini

In the subdirectory fn_my_app you’ll find the python files which make up the app. The components directory holds the function code. It is currently templated as an outline and will require that you fill it in to fully take advantage of the function. The util directory holds the configuration information for the app. Fill in the appropriate data in config.py to determine how the configuration section of your app will be rendered and the selftest.py file should implement a basic connectivity check to the endpoint, verifying proper configuration. This document omits the details of implementing your code and testing it. For more information on that, please seek learning resources through IBM support.

During the process, you may decide that certain elements in the UI need to be updated and pulled into the app’s package. You can achieve this with the --reload flag which automatically refreshes any components from SOAR that have already been included in your app. You can also pull in new components by referencing them in the command. Example:

resilient-sdk codegen -p fn_my_app -pb pb_to_add_to_package --reload

After you feel comfortable with the contents of your app, you can do a validation to make sure you’re not missing anything. Run validate on your app:

resilient-sdk validate -p fn_my_app --validate

Once you’ve completed the implementation of the app, run docgen to generate the README:

resilient-sdk docgen -p fn_my_app

Then run package to zip the app up so that you can then publish for use:

resilient-sdk package -p fn_my_app

Advanced Usage#

Certain apps may wish to take advantage of the ability to “poll” on an endpoint. This is useful in creating apps that bidirectionally sync between SOAR and a third party system. Adding a poller to an app is achieved by adding the --poller flag to the codegen command when creating a new app. This flag will generate new files in the /lib and /poller directories of the package which are intended to help you start on your way to building a poller. In particular, find and modify the /poller/poller.py file and its associated template files in the /poller/data subdirectory. The /lib/app_common.py file is where common code between the poller and function files can be shared for accessing the endpoints of the third party solution.

See Common Poller Methods for a guide on how to implement a poller app and see examples of poller apps in our public GitHub repository.

docgen#

Generates boilerplate documentation for an app.

usage:
$ resilient-sdk docgen -p <path_to_package>
$ resilient-sdk docgen -p <name_of_package> --settings <path_to_custom_sdk_settings_file>
$ resilient-sdk docgen -p <name_of_package> --poller # for a poller app
$ resilient-sdk docgen -e export.res
$ resilient-sdk docgen -e playbook1.resz playbook2.resz -o /path/to/save/playbooks_readme.md
$ resilient-sdk docgen -e . -o README.md # reads all exports in current directory and outputs to README.md

options:
-h, --help			show this help message and exit
--settings			Path to .sdk_settings.json file. Default is ~/.resilient/.sdk_settings.json 
-p, --package			Path to the package containing the setup.py file 
-e, --exportfile		List of files or directory containing export.res or export.resz file generated by resilient-sdk extract or exported from the SOAR platform. Ignored when used in conjunction with '--package' 
-o, --output			Full or relative path indicating where to save the file that docgen generates 
-pr, --poller			Include poller section in README generated by docgen

package#

Package your Python Package into a SOAR app format.

usage:
$ resilient-sdk package -p <path_to_directory>
$ resilient-sdk package -p <path_to_directory> --display-name "My Custom App"
$ resilient-sdk package -p <path_to_directory> --repository-name "ibmresilient" --image-hash "dd2a1678b6e0..."
$ resilient-sdk package -p <path_to_directory> --keep-build-dir --display-name "My Custom App"
$ resilient-sdk package -p <path_to_directory> --validate

options:
-h, --help			show this help message and exit
-p, --package			(required) Path to the directory containing the setup.py file 
--keep-build-dir		Do not delete the dist/build directory 
--display-name			Display name to give the app 
--repository-name		Name of the repository which contains the app container 
--image-hash			The SHA256 hash of the container image to pull for this App 
--no-samples			Do not look for the payload_samples directory or try add them to the export.res file 
--validate			Run the 'validate' command and generate the validation report to include in packaging

validate#

Tests the content of all files associated with the app, including code, before packaging it. Only Python >= 3.6 supported.

usage:
$ resilient-sdk validate -p <name_of_package>
$ resilient-sdk validate -p <name_of_package> -c '/usr/custom_app.config'
$ resilient-sdk validate -p <name_of_package> --validate
$ resilient-sdk validate -p <name_of_package> --tests
$ resilient-sdk validate -p <name_of_package> --tests --tox-args resilient_password="secret_pwd" resilient_host="ibmsoar.example.com"
$ resilient-sdk validate -p <name_of_package> --tests --settings <path_to_custom_sdk_settings_file>
$ resilient-sdk validate -p <name_of_package> --pylint --bandit --selftest

options:
-h, --help			show this help message and exit
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
--settings			Path to .sdk_settings.json file. Default is ~/.resilient/.sdk_settings.json 
-p, --package			Path to existing package. Defaults to current directory 
--validate			Run validation on package files. No dynamic checks. 
--tests				Run tests using package's tox.ini file in a Python 3.6 environment (if 'tox' is installed and tox tests are configured for the package) 
--pylint			Run a pylint scan of all .py files under package directory. 'pylint' must be installed) 
--bandit			Run a bandit scan of all .py files under package directory. 'bandit' must be installed) 
--selftest			Validate and run the selftest.py file in the package directory. 'resilient-circuits' and the package must be installed in Python environment) 
--tox-args			Pytest arguments to pass to tox when validating tests. Format is <attr1>="<value>". Example: '--tox-args my_arg1="value1" my_arg2="value2"'

Usage#

Run validate without any options to:

  1. Verify that App files conform to our latest standard

  2. Test that resilient-circuits starts and that the App’s selftest passes

  3. Run any unit tests found with tox (if installed)

  4. Run a pylint scan (if installed) using our defined pylint config file

  5. Run a bandit scan (if installed) to identify any common security issues

  • To ensure that all files in your App conform to our latest standard, run:

$ resilient-sdk validate -p <path_to_package> --validate

  • To perform basic testing of the App, run:

$ resilient-sdk validate -p <path_to_package> --selftest

  • validate also has the ability to accept an app.config file in any location. For example:

$ resilient-sdk validate -p <path_to_package> --selftest -c '/usr/custom_app.config'

  • Once completed, a Markdown summary file is added to the dist directory and included in the .zip file when packaged

Note

You can run each validation individually by specifying its related option.

clone#

Duplicate an existing Action related object (Function, Rule, Script, Message Destination, Workflow, or Playbook) with a new api or display name

usage:
$ resilient-sdk clone --workflow <workflow_to_be_cloned> <new_workflow_name>
$ resilient-sdk clone --workflow <workflow_to_be_cloned> <new_workflow_name> --changetype artifact
$ resilient-sdk clone -pb <playbook_to_be_cloned> <new_playbook_name>
$ resilient-sdk clone -pb <playbook_to_be_cloned> <new_playbook_name> --draft-playbook
$ resilient-sdk clone --playbook <playbook_to_be_cloned> <new_playbook_name> --changetype artifact
$ resilient-sdk clone -f <function_to_be_cloned> <new_function_name>
$ resilient-sdk clone -r "Display name of Rule" "Cloned Rule display name"
$ resilient-sdk clone -s "Display name of Script" "Cloned Script display name"
$ resilient-sdk clone -s "Display name of Script" "Cloned Script display name" --changetype task
$ resilient-sdk clone -pre version2 -r "Display name of Rule 1" "Display name of Rule 2" -f <function_to_be_cloned> <function2_to_be_cloned>

options:
-h, --help			show this help message and exit
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
-f, --function			API names of functions to include 
-m, --messagedestination	API names of message destinations to include 
-pb, --playbook			API names of playbooks to include. Only IBM SOAR >= v44.0 supported 
--draft-playbook		If specified with the '--playbook' option will clone the Playbook into a Draft state, allowing you to change it's Activation Type. Only IBM SOAR >= v44.0 supported 
-r, --rule			Display names of rules to include (surrounded by "") 
-s, --script			Display names of scripts to include (surrounded by "") 
-w, --workflow			API names of workflows to include 
-pre, --prefix			The prefix to be placed at the start of cloned Action Objects. Used when cloning more than 1 of each Action Object Type. 
-type, --changetype		The new type of the clone action object. Used when cloning a workflow or script to have the newly cloned workflow at a different object type.

extract#

Extract data in order to publish a .res export file

usage:
$ resilient-sdk extract -m 'fn_custom_md' --rule 'Rule One' 'Rule Two'
$ resilient-sdk extract --playbook my_sub_playbook --function fn_in_sub_playbook
$ resilient-sdk extract --script 'custom_script' --zip
$ resilient-sdk extract --script 'custom_script' --zip -c '/usr/custom_app.config'
$ resilient-sdk extract --script 'custom_script' --name 'my_custom_export'

options:
-h, --help			show this help message and exit
-a, --artifacttype		API names of artifact types to include 
-d, --datatable			API names of datatables to include 
-f, --function			API names of functions to include 
-fd, --field			API names of custom fields to include 
-i, --incidenttype		Display names of custom incident types to include (surrounded by "") 
-m, --messagedestination	API names of message destinations to include 
-pb, --playbook			API names of playbooks to include. Only IBM SOAR >= v44.0 supported 
-r, --rule			Display names of rules to include (surrounded by "") 
-s, --script			Display names of scripts to include (surrounded by "") 
-t, --task			API names of custom tasks to include 
-w, --workflow			API names of workflows to include 
-e, --exportfile		Path to a local (.res or .resz) export file 
-o, --output			Path to output directory. Uses current dir by default 
-z, --zip			Generate a .zip of the generated file 
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
-n, --name			Name to prepend to generated file

list#

List available objects from SOAR. For each of the objects below, either leave blank to list all, provide a prefix string to filter by prefix, or provide a regex to filter matching object names.

usage:
$ resilient-sdk list --function                           # list all functions
$ resilient-sdk list --function "fn_my_app.*" --playbook  # list all functions that start with fn_my_app and all playbooks
$ resilient-sdk list --global-filter ".*(?i)cyber.*"      # matches all objects with "cyber" in them (uses '(?i)' for case-insensitive)
$ resilient-sdk list --function --codegen-format          # list all functions and give output in codegen format

options:
-h, --help			show this help message and exit
-a, --artifacttype		API names of artifact types to include 
-d, --datatable			API names of datatables to include 
-f, --function			API names of functions to include 
-fd, --field			API names of custom fields to include 
-i, --incidenttype		Display names of custom incident types to include (surrounded by "") 
-m, --messagedestination	API names of message destinations to include 
-pb, --playbook			API names of playbooks to include. Only IBM SOAR >= v44.0 supported 
-r, --rule			Display names of rules to include (surrounded by "") 
-s, --script			Display names of scripts to include (surrounded by "") 
-t, --task			API names of custom tasks to include 
-w, --workflow			API names of workflows to include 
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
-g, --global-filter		Regex to filter on all objects. If a specific object filter is provided it overrides the --global-filter filter 
-e, --exportfile		Path to a local (.res or .resz) export file 
-cf, --codegen-format		Output results in codegen-friendly format

init#

Generates sdk_settings.json file to store default settings and generates app.config file to store connection details. Providing a flag will override the default paths.

usage:
$ resilient-sdk init
$ resilient-sdk init --settings <path to settings json>
$ resilient-sdk init --settings <path to settings json> -a/--author you@example.com
$ resilient-sdk init -c/--config <path to app.config>
$ resilient-sdk init --settings <path to settings json> -c/--config <path to app.config>

options:
-h, --help			show this help message and exit
-c, --config			Path to app.config file. Default is ~/.resilient/app.config 
--settings			Path to .sdk_settings.json file. Default is ~/.resilient/.sdk_settings.json 
-a, --author			setup.py author name 
-ae, --author_email		setup.py author email 
-u, --url			setup.py company URL 
-l, --license			setup.py license name

Change Log#

2024-04: version 51.0.1.1

  • No major changes. Just bumping build number to coincide with other builds

2024-02: version 51.0.1.0

  • All SOAR Python libraries now officially support Python 3.11

  • The init command now includes an option to create an app.config file:

    $ resilient-sdk init -c /my_path/app.config

  • The init command option to create an .sdk_settings.json file has changed to be --settings:

    $ resilient-sdk init --settings /my_path/.sdk_settings.json

  • Added new list command to list objects available to use in other resilient-sdk commands. The command supports all common SOAR objects and can be used with regex filters to filter list results.

    Example:

    $ resilient-sdk list -f # to list all functions

    $ resilient-sk list -pb .*my_pb --codegen-format # to list all playbooks that end with my_pb in codegen-format

  • The codegen command uses a new Dockerfile template which takes advantage of the new soarapps-base-docker-image. It is recommended that you update your apps to use this new template. To bring in the new template, simply rename the current Dockerfile to Dockerfile.bak so that your changes are not lost. Then run resilient-sdk codegen --reload. You will notice the new Dockerfile which you can now use to build container images for your apps. The base image has both 3.11 and 3.9 versions to work off of. We recommend you build your apps with 3.11 to take advantage of the latest Python features

2023-12: version 51.0.0.1

  • Bug fix to support Keyring with resilient-sdk commands that use app.config to connect to SOAR. This has been broken since v49.0.0. Please upgrade to v51.0.0.1 to continue using SDK with Keyring.

2023-11: version 51.0.0.0

  • Added support for new SOAR v.r.m.f version scheme. This takes effect with the release of v51.0.0.0 of SOAR and v51.0.0.0 of resilient-sdk. To run SDK commands against SOAR v51.0.0.0 or greater, you must update to the latest SDK. It is important to be up to date with resilient-sdk when working with SOAR. You will know if you’re version of the SDK is out of date by the warning message output when running commands. If you don’t see this message you are up to date

  • The docgen command now supports export files and directories of exports, including Playbooks. Use -e or --exportfile followed by a list of .res or .resz files or a directory with .res or .resz files. For example, to generate one README for a playbook export, a .res export and a directory of exports:

    $ resilient-sdk docgen -e My_Playbook.resz export.res ../Downloads/all_exports -o MyPB_export_and_all_exports.md

  • Added more examples of using the SDK in the API documentation at https://ibm.biz/soar-python-docs

2023-10: version 50.1

  • No major changes. Just bumping build number to coincide with other builds

2023-08: version 50.0

  • The docgen command now fully supports Playbooks, including function script examples and extended details for each Playbook including activation conditions

  • The codegen command better supports Playbooks and Subplaybooks in the markdown files created. Specifically, support was added for function inputs, activation conditions, and subplaybook details for each playbook generate. Subplaybooks are still also described in a separate markdown file for full details

  • The init command now includes a setting to set copyright in .sdk_settings.json file. codegen will now automatically read this setting and set the copyright at the top of each Python file generated. The setting for copyright lives in the codegen section of the settings file and can be formatted with the current year by placing {0} in the location which you wish to include the year. Example:

    // .sdk_settings.json:
{
  "codegen": {
      "copyright": "(c) Copyright My Inc. {0}. All Rights Reserved."
  }
}

2023-07: version 49.1

  • No major changes. Just bumping build number to coincide with other builds

2023-05: version 49.0

  • Added support to create markdown files for Playbooks as they would have been created with Workflows. Includes automatic detection of global scripts in codegen when exporting playbooks. Expanded support for playbooks with docgen will be included in a future release

2023-04: version 48.1

  • Added new init functionality to the SDK

  • Added --settings option for codegen, docgen, and validate

  • Bug fixes for validate

2023-02: version 48.0

  • clone command fixed when cloning subplaybooks with multiple input fields

  • resilient-sdk version is now added as a comment to all files generated or updated by the SDK

  • Added new --poller flag to docgen to support documentation for poller-based apps generated with resilient-sdk codegen [...] --poller, including automatically formatting the poller template file contents into the README file

  • Updated validate markdown report to include total issue counts

  • validate automatically checks the Python version of all scripts from SOAR included in your app validate will fail if any Playbook or Workflow scripts are written in Python 2

  • Default apikey_permissions.txt file generated by codegen updated to include latest available API permissions

  • package now supports blank lines in apikey_permissions.txt

  • Updated project to use pyproject.toml and setup.cfg metadata files. Build backend continues to use setuptools. Instead of directly invoking setup.py to get a sdist or wheel, use build as a build frontend:

    pip install build
python -m build

2022-12: version 47.1

  • clone, extract, and package commands fixed to avoid clearing out overrides for disabled Tasks in SOAR

  • Poller Jinja templates for codegen --poller updated to reference “cases” rather than “incidents”

2022-11: version 47.0

  • Added support to extract command for sub-playbooks. They are treated like normal Playbooks so no further command line args are required. Just ensure you include all other customizations in your command. For example:

    $ resilient-sdk extract --playbook my_sub_playbook --function fn_in_sub_playbook

  • codegen template updates with Python 3 syntax

  • Added new --poller flag to codegen. This allows for creating poller-based apps which generates a lib directory in the package and a poller directory each with items needed to create a poller-based app.

  • docgen template updated with references to Edge Gateway (formerly App Host)

  • Added support for activation fields in manually activated playbooks in the clone command

2022-08: version 46.0

  • Check to see if the current installed version of the resilient-sdk is the latest available version on PyPi

  • Slight enhancements to the codegen template

  • validate updates:

    • Ensure the base image of in an App’s Dockerfile is valid

    • Further checks of setup.py file

    • Validate that all App’s dependencies are using the ~= syntax

2022-07: version 45.1

  • No major changes. Just bumping build number to coincide with other builds

2022-05: version 45.0

  • Added new option --draft-playbook to the clone command that if specified with the --playbook option will clone the Playbook into a Draft state, allowing you to change it’s Activation Type

  • codegen and extract now exclude the creator from the generated export.res file

  • Minor updates to templates produced with codegen

2022-04: version 44.1

  • No major changes. Just bumping build number to coincide with other builds

2022-02: version 44.0

  • Added support to codegen, docgen, package, extract and clone for Playbooks

  • Bump Jinja2 to ~=3.0 for Python >=3.6

  • Officially support Python 3.9

2022-01: version 43.1

  • Added new validate functionality to the SDK

  • Added genson 1.2 dependency to generate JSON schemas

  • codegen now produces output_json_example.json and output_json_schema.json files for each function in the payload_samples directory to aid with building Playbooks

  • codegen has a new argument --gather-results which will scan an app.log file to get the results for the output_json_example.json file

  • When docgen is now ran, it will look for an output_json_example.json file for each function and use that for the README.md Function Output Examples

  • Added global-exclude *.bak to the MANIFEST.in file in the codegen template so .bak files are not included when packaged

2021-11: version 43.0

  • Added examples to codegen template

  • Formatted Sphinx documentation and hosted it at https://ibm.biz/soar-python-docs

  • A packaged App will now include additional files with additions to the MANIFEST.in file

2021-11: version 42.3

  • Enforce unix style line endings (\n) when writing files

  • codegen to include apikey_permissions.txt in MANIFEST.in file

2021-10: version 42.2

  • Bug fix for clone to support Python 2.7

  • Ability to use different app.config file per command using -c flag

2021-08: version 42.1

  • No major changes. Just bumping build number to coincide with other builds

2021-08: version 42.0

  • codegen now generates a template for App’s to be developed to run in a Python >= 3.6 environment.

  • Bug fixes.

  • Support for collecting incident types in codegen and extract. See the command line parameters -i and --incidenttype.

2021-06: version 41.1

  • To address a security vulnerability, the Dockerfile codegen template now assigns user 1001 to the non-root group 1001. User 1001 is used to run a container.

  • Added a new Atomic Function template generated with codegen, which is a condensed version of our Original Function template. It includes comments on best practices.

2021-05: version 41.0

  • List all setup.py "install_requires" dependencies in docgen README template

  • Bug fixes

2021-03: version 40.2

  • Bug fix for to use setuptools_scm < 6.0.0 for Python 2.7 environments

2021-03: version 40.1

  • Adjust entrypoint.sh template to ensure resilient-circuits is restarted when a fatal error occurs when running on App Host

  • Added timestamp to logs on App Host

2021-02: version 40.0

  • The function template that is produced when you run codegen now includes references to the resilient-lib library.

  • When the var RES_SDK_DEV is set, codegen now creates the payload_samples directory with JSON examples for the Resilient UI and mock results for a “mock server”.

  • Added --no-samples flag to package and when set do not look for the payload_samples directory or try add them to the export.res file.

  • Added --image-hash flag to package to specify the SHA256 of an image that the app.zip refers to.

2020-10: version 39.0

  • The docgen command creates a single README and updated the README to include information on App Hosts.

  • Added the Resilient platform version to the customize.py template.

  • The package command replaces tags on Resilient objects in export.res instead of extending them.

  • Added environmental variable RES_SDK_DEV.

  • Added --set-version argument to the dev command.

  • Added display_name attribute to the setup.py file.

  • The codegen, codegen --reload and dev --set-version commands create a /util/data/export.res file that contains the import definition which was previously base64 encoded text in customize.py.

  • Before running the codegen --reload on packages created with Resilient SDK < 39.0.0, ensure the MANIFEST.in file includes the line: recursive-include <package_name>/util *

  • The codegen and package commands return errors if the package name contains uppercase characters.

  • Added a clone command to clone an Action Object.

2020-07: version 37.2

  • Updates to Dockerfile template

  • Support for newest export formats

  • Bug fixes.

2020-05: version 37.0

  • Package created. Using 37 as original version

  • Added support for API key permissions in app.json using permissions file.

  • Added support for new apphost config section.

  • Customization and config properties files now extracted from setup.py.

  • Rename app:package command to package.

  • Bug fixes.

2020-04: version 36.2.dev

  • Package dev version created. Using 36.2 as original version

  • Added support for API key permissions in app.json using permissions file.

  • Added support for new apphost config section.

  • Customization and config properties files now extracted from setup.py.

  • Rename app:package command to package.

  • Bug fixes.