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-circuits
starts and that the App’sselftest
passesRun any unit tests found with
tox
(if installed)Run a
pylint
scan (if installed) using our definedpylint
config fileRun 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 anapp.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-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 update
to Dockerfile template
2024-05: version 51.0.2.0
Added official support for Python 3.12
Improved the
docgen
command for export files to eliminate duplicate objectsThe
gather-results
feature of thecodegen
command now clears out sensitive host valuesThe
validate
command now checks apps for any playbooks which are dependent on SOAR objects that might not have been included in during thecodegen
process. 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
init
command now includes an option to create anapp.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 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 currentDockerfile
toDockerfile.bak
so 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-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 dateThe
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 conditionsThe
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 detailsThe
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 forcopyright
lives in thecodegen
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 withdocgen
will be included in a future release
2023-04: version 48.1
Added new
init
functionality to the SDKAdded
--settings
option forcodegen
,docgen
, andvalidate
Bug fixes for
validate
2023-02: version 48.0
clone
command fixed when cloning subplaybooks with multiple input fieldsresilient-sdk
version is now added as a comment to all files generated or updated by the SDKAdded new
--poller
flag todocgen
to support documentation for poller-based apps generated withresilient-sdk codegen [...] --poller
, including automatically formatting the poller template file contents into the README fileUpdated
validate
markdown report to include total issue countsvalidate
automatically checks the Python version of all scripts from SOAR included in your appvalidate
will fail if any Playbook or Workflow scripts are written in Python 2Default
apikey_permissions.txt
file generated bycodegen
updated to include latest available API permissionspackage
now supports blank lines inapikey_permissions.txt
Updated project to use
pyproject.toml
andsetup.cfg
metadata files. Build backend continues to usesetuptools
. Instead of directly invoking setup.py to get a sdist or wheel, usebuild
as a build frontend:pip install build python -m build
2022-12: version 47.1
clone
,extract
, andpackage
commands fixed to avoid clearing out overrides for disabled Tasks in SOARPoller 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 syntaxAdded new
--poller
flag tocodegen
. This allows for creating poller-based apps which generates alib
directory in the package and apoller
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 PyPiSlight enhancements to the
codegen
templatevalidate
updates:Ensure the base image of in an App’s Dockerfile is valid
Further checks of
setup.py
fileValidate 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 theclone
command that if specified with the--playbook
option will clone the Playbook into a Draft state, allowing you to change it’s Activation Typecodegen
andextract
now exclude thecreator
from the generatedexport.res
fileMinor 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
andclone
for PlaybooksBump
Jinja2
to~=3.0
for Python>=3.6
Officially support
Python 3.9
2022-01: version 43.1
Added new
validate
functionality to the SDKAdded genson 1.2 dependency to generate JSON schemas
codegen
now producesoutput_json_example.json
andoutput_json_schema.json
files for each function in thepayload_samples
directory to aid with building Playbookscodegen
has a new argument--gather-results
which will scan anapp.log
file to get the results for theoutput_json_example.json
fileWhen
docgen
is now ran, it will look for anoutput_json_example.json
file for each function and use that for theREADME.md
Function Output ExamplesAdded
global-exclude *.bak
to the MANIFEST.in file in thecodegen
template so.bak
files are not included when packaged
2021-11: version 43.0
Added examples to
codegen
templateFormatted 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 filescodegen
to includeapikey_permissions.txt
in MANIFEST.in file
2021-10: version 42.2
Bug fix for
clone
to support Python 2.7Ability 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 indocgen
README templateBug 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 ensureresilient-circuits
is 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
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 topackage
and when set do not look for the payload_samples directory or try add them to the export.res file.Added
--image-hash
flag topackage
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
anddev --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
andpackage
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 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:package
command topackage
.Bug fixes.