Skip to content

Latest commit

 

History

History
 
 

kazoo_ast

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 

Kazoo AST

This library is for parsing the Erlang AST (Abstract Syntax Tree) of various Kazoo Erlang modules, looking to automatically pull out information for use by developers or users of Kazoo.

Existing AST modules

cb_api_endpoints

This module primarily looks for what endpoint paths are exposed by each Crossbar endpoint module. This is done by parsing each module’s `allowed_methods` exported functions and using the function’s arguments and the returned list of HTTP verbs.

Additionally, this module can take a JSON schema (using the module’s name to determine the schema file name) and create a Markdown table.

This functionality is utilized in the `to_ref_doc/0` and `to_swagger_json/0` to create reference documentation files for each Crossbar endpoint and to populate/update a swagger.json file. The ref docs are then used as guides in creating/updating the Crossbar documentation.

The next step is to create an escript that will, on each PR, run the `to_ref_doc/0`; if there are changes to the ref doc files, there will be unstaged changes that should trigger the committer to fold those into the docs. These unstaged changes can also be detected in CI and fail the build so that committers will be alerted.

cf_data_usage

This module looks for callflow action modules and traces the usage of `Data` in the `handle/2` exported function. It then looks for where the call paths get values out of the `Data` JSON object. Once collected, the module attempts to create/update a `callflows.{ACTION}.json` JSON schema document. The module inserts the keys found, tries to guess the type permitted, and includes the default if applicable.

This functionality is utilized in the `to_schema_docs/0` (to process all callflow actions - that is, modules that implement the gen_cf_action Erlang behaviour) and the `to_schema_doc/1`, which takes the callflow action’s module name (eg cf_park, cf_user, cf_voicemail, etc).

Similar to `cb_api_endpoints`, the next step is to make this an escript that runs on each build, creates unstaged changes, and forces a committer to address the detected changes.

kapps_config_usage

This module looks in all Kazoo Erlang application modules for calls to kapps_config (docs in the `system_config` database) getters. Similar to `cf_data_usage`, `kapps_config_usage` will create schemas if missing, update existing schemas, guess types, and include defaults if appropriate.

It also builds schemas for account config documents (account-overrides of system_config parameters).

code_usage

This module looks across the project for function call usage. It counts M:F/A and M:F(Args) instances (counting the length of Args to get arity) in the AST. The printer then takes an optional argument to print the Top hits.

`code_usage:tabulate()`: print the top 25 M:F/A across the project
`code_usage:tabulate(50)`: print the top 50 M:F/A across the project
`code_usage:tabulate(crossbar)`: print the top 25 M:F/A in Crossbar
`code_usage:tabulate(crossbar, 50)`: print the top 50 M:F/A in Crossbar