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:
Verify that App files conform to our latest standard
Test that
resilient-circuitsstarts and that the App’sselftestpassesRun any unit tests found with
tox(if installed)Run a
pylintscan (if installed) using our definedpylintconfig fileRun a
banditscan (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
validatealso has the ability to accept anapp.configfile 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
distdirectory and included in the.zipfile 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-07: version 51.0.2.2 * Update dependency version of setuptools version to 70.3.x to address CVE-2024-6345
2024-07: version 51.0.2.1
All IBM SOAR Python libraries now only officially support Python 3.9, 3.11, and 3.12. To continue using SOAR libraries on earlier versions of Python, use v52.0.2.0.974
Improvements for docgen with poller apps
Added
yum updateto Dockerfile template
2024-05: version 51.0.2.0
Added official support for Python 3.12
Improved the
docgencommand for export files to eliminate duplicate objectsThe
gather-resultsfeature of thecodegencommand now clears out sensitive host valuesThe
validatecommand now checks apps for any playbooks which are dependent on SOAR objects that might not have been included in during thecodegenprocess. Developers should still be sure to test their apps in a staging environments to ensure that all objects are properly packaged
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
initcommand now includes an option to create anapp.configfile:$ resilient-sdk init -c /my_path/app.config
The
initcommand option to create an.sdk_settings.jsonfile has changed to be--settings:$ resilient-sdk init --settings /my_path/.sdk_settings.json
Added new
listcommand 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
codegencommand uses a new Dockerfile template which takes advantage of the newsoarapps-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 currentDockerfiletoDockerfile.bakso that your changes are not lost. Then runresilient-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 withresilient-sdkwhen 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 dateThe
docgencommand now supports export files and directories of exports, including Playbooks. Use-eor--exportfilefollowed 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
docgencommand now fully supports Playbooks, including function script examples and extended details for each Playbook including activation conditionsThe
codegencommand 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 detailsThe
initcommand now includes a setting to set copyright in.sdk_settings.jsonfile.codegenwill now automatically read this setting and set the copyright at the top of each Python file generated. The setting forcopyrightlives in thecodegensection 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
codegenwhen exporting playbooks. Expanded support for playbooks withdocgenwill be included in a future release
2023-04: version 48.1
Added new
initfunctionality to the SDKAdded
--settingsoption forcodegen,docgen, andvalidateBug fixes for
validate
2023-02: version 48.0
clonecommand fixed when cloning subplaybooks with multiple input fieldsresilient-sdkversion is now added as a comment to all files generated or updated by the SDKAdded new
--pollerflag todocgento support documentation for poller-based apps generated withresilient-sdk codegen [...] --poller, including automatically formatting the poller template file contents into the README fileUpdated
validatemarkdown report to include total issue countsvalidateautomatically checks the Python version of all scripts from SOAR included in your appvalidatewill fail if any Playbook or Workflow scripts are written in Python 2Default
apikey_permissions.txtfile generated bycodegenupdated to include latest available API permissionspackagenow supports blank lines inapikey_permissions.txtUpdated project to use
pyproject.tomlandsetup.cfgmetadata files. Build backend continues to usesetuptools. Instead of directly invoking setup.py to get a sdist or wheel, usebuildas a build frontend:pip install build python -m build
2022-12: version 47.1
clone,extract, andpackagecommands fixed to avoid clearing out overrides for disabled Tasks in SOARPoller Jinja templates for
codegen --pollerupdated to reference “cases” rather than “incidents”
2022-11: version 47.0
Added support to
extractcommand 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
codegentemplate updates with Python 3 syntaxAdded new
--pollerflag tocodegen. This allows for creating poller-based apps which generates alibdirectory in the package and apollerdirectory each with items needed to create a poller-based app.docgentemplate updated with references to Edge Gateway (formerly App Host)Added support for activation fields in manually activated playbooks in the
clonecommand
2022-08: version 46.0
Check to see if the current installed version of the
resilient-sdkis the latest available version on PyPiSlight enhancements to the
codegentemplatevalidateupdates:Ensure the base image of in an App’s Dockerfile is valid
Further checks of
setup.pyfileValidate 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-playbookto theclonecommand that if specified with the--playbookoption will clone the Playbook into a Draft state, allowing you to change it’s Activation Typecodegenandextractnow exclude thecreatorfrom the generatedexport.resfileMinor 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,extractandclonefor PlaybooksBump
Jinja2to~=3.0for Python>=3.6Officially support
Python 3.9
2022-01: version 43.1
Added new
validatefunctionality to the SDKAdded genson 1.2 dependency to generate JSON schemas
codegennow producesoutput_json_example.jsonandoutput_json_schema.jsonfiles for each function in thepayload_samplesdirectory to aid with building Playbookscodegenhas a new argument--gather-resultswhich will scan anapp.logfile to get the results for theoutput_json_example.jsonfileWhen
docgenis now ran, it will look for anoutput_json_example.jsonfile for each function and use that for theREADME.mdFunction Output ExamplesAdded
global-exclude *.bakto the MANIFEST.in file in thecodegentemplate so.bakfiles are not included when packaged
2021-11: version 43.0
Added examples to
codegentemplateFormatted 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 filescodegento includeapikey_permissions.txtin MANIFEST.in file
2021-10: version 42.2
Bug fix for
cloneto support Python 2.7Ability to use different app.config file per command using
-cflag
2021-08: version 42.1
No major changes. Just bumping build number to coincide with other builds
2021-08: version 42.0
codegennow 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
codegenand extract. See the command line parameters-iand--incidenttype.
2021-06: version 41.1
To address a security vulnerability, the Dockerfile
codegentemplate 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 indocgenREADME templateBug fixes
2021-03: version 40.2
Bug fix for to use
setuptools_scm < 6.0.0for Python 2.7 environments
2021-03: version 40.1
Adjust
entrypoint.shtemplate to ensureresilient-circuitsis restarted when a fatal error occurs when running on App HostAdded timestamp to logs on App Host
2021-02: version 40.0
The function template that is produced when you run
codegennow includes references to the resilient-lib library.When the var RES_SDK_DEV is set,
codegennow creates the payload_samples directory with JSON examples for the Resilient UI and mock results for a “mock server”.Added
--no-samplesflag topackageand when set do not look for the payload_samples directory or try add them to the export.res file.Added
--image-hashflag topackageto specify the SHA256 of an image that the app.zip refers to.
2020-10: version 39.0
The
docgencommand 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
packagecommand replaces tags on Resilient objects in export.res instead of extending them.Added environmental variable RES_SDK_DEV.
Added
--set-versionargument to the dev command.Added
display_nameattribute to the setup.py file.The
codegen,codegen --reloadanddev --set-versioncommands 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 --reloadon packages created with Resilient SDK < 39.0.0, ensure the MANIFEST.in file includes the line: recursive-include <package_name>/util *The
codegenandpackagecommands return errors if the package name contains uppercase characters.Added a
clonecommand 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:packagecommand topackage.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:packagecommand topackage.Bug fixes.