A PRM tool can be packaged as a
.tar.gz or hosted in a Github repository.
Tools are how PRM knows to take defined actions against a file or folder; linting, testing, exporting, etc.
A tool can be:
At a minimum, a PRM tool must contain a
prm-config.yml in the root directory.
Optionally, you may include a
content directory, also at the root.
content directory can contain scripts, binaries, config files, etc. required to supplement the functionality of the tool outside the parameters of the configuration file.
When a tool is used with the Docker backend, everything in the
content directory is mounted to
/tmp in the container;
content/myfile.sh will be mounted to
All tools must include mandatory metadata in the
prm-config.yml file which enumerate it for PRM to understand what it is.
They must include:
plugin: author: fantastic-me id: awesome-tool display: Awesome Tool version: 0.1.0 upstream_project_url: https://github.com/fantastic-me/awesome-me
Tools are executed by namespace, always in the form
To execute the example tool above, you would run the command
prm exec fantastic-me/awesome-tool
In addition to the
plugin configuration items, there is a
common section that contains parameters that change the behavior of the tool regardless of underlying implementation details.
trueif the tool is meant to validate a target code directory.
toolArgsflag when executed.
trueif the tool requires a
contentdirectory and have execute permissions set.
chmod +x runme.sh).
common: can_validate: true help_arg: '-h' success_exit_code: 2 default_args: ['--include-tempfiles', '--fail-fast'] env: - "TARGET_VERSION": "1.2.3" - "CONFIG_FILE": "/code/config.yaml" requires_git: true use_script: "collate_files_and_run"
This tool, as configured:
-hto retrieve the help information for the underlying tool
--include-tempfiles --fail-fastwhen executed
TARGET_VERSIONenvironment variable to
CONFIG_FILEenvironment variable to
/code/config.yamlin the execution context
gitto be installed/available
contentdirectory to execute the tool.
gem based tools must declare which gems must be installed and the name of the executable to run.
gem: name: [amazing_gem, dependency_gem, another_dependency_gem] executable: amazing_gem
By default, any gems specified will always attempt to resolve and use the latest released version.
If there are compatibility concerns, version pins by Ruby version can be enumerated under the
gem: name: [amazing_gem, dependency_gem, another_dependency_gem] executable: amazing_gem compatibility: - 2.6: - "amazing_gem": "2.15.0" - 2.7: - "amazing_gem": "~> 3.0"
This will install the latest versions of
another_dependency_gem regardless of Ruby version.
For any version of Ruby other than
2.7, the tool will expect to use the latest version of
amazing_gem as well.
For Ruby 2.6,
amazing_gem will only ever be used at version
For Ruby 2.7,
amazing_gem will always use the latest version greater than or equal to
3.0 and less than
binary based tools must declare the name of the binary which is to be run and installation steps for acquiring that binary on particular platforms.
binary: name: my_tool install_steps: windows: | # Windows specific install steps choco install my_tool linux: | # Linux specific install steps rpm install my_tool darwin: | # MacOS specific install steps brew install my_tool
This configuration will expect to find
my_tool on the
PATH and calls out installation steps for Windows, Linux, and MacOS.
Note: At this time, only Linux docker containers are supported. Future releases will support other platforms and backends.
container based tools must declare the image name and tag to be used.
The images must be available or retrievable by Docker on the machine running PRM.
container: name: myorg/myimage tag: latest
This configuration will execute in the