Follow the directions in Setting Up a Git Pre-Commit Hook to Parse KRL to set up the KRL parser and ensure that KRL files are parsed before they are committed.
Add the file to the repository and commit it.
$ git add hello_world.krl $ git commit -a -m "initial commit" Flushing com.windley.hello_world [master (root-commit) 4a2f95c] initial commit 1 file changed, 34 insertions(+) create mode 100644 hello_world.krl
With the pre-commit hook in place, you're assured that there are no parse errors in your ruleset if it commits.
Registering a ruleset associates its ruleset ID (RID) with a URL where it is located.
Because rulesets in KRL are hosted internet objects, the engine loads, parses, compiles, and caches them for efficiency. Each ruleset only needs to be registered once on a given pico engine. Registering the ruleset associates its ruleset ID ( RID ) with the URL where it's found. The RID is taken from the ruleset source. It's the identifier that directly follows the
ruleset keyword. Best practice is to use a reversed domain name that you control in the RID to ensure uniqueness since two developers could choose the same name otherwise.
The engine will parse, compile, and make your ruleset available for use by any pico in that engine.
File-based URLs for work great for development where quick turnaround is needed. If you want to host rulesets somewhere else, please be sure to read the tips for hosting rulesets.
Again, you only need a register a ruleset once on any engine, even if the source code changes. The only reason to re-register a ruleset is if it's RID or URL change.
Deploying includes two different tasks: flushing cached artifacts from the ruleset in the engine and installing the ruleset in any picos it needs to run in.