You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide alternative paths for analyzers in addition to standard path.
Request Type
Feature Request
Problem Description
In the application config, there is a "path to analyzers" field. It would be nice to be able to provide "N" number of paths to analyzers so that we could continue to use the built in analyzers, but also provide other locations that are checked. Each path to analyzers would have it's own config associated (We would have to determine if Global was truly global or global PER path to analyzer).
This would allow folks to create alternate repos of analyzers that could be shared in private circles, whether trust groups, whether internally at an org etc, without having to go through a merging process every time new analyzers are added to the main repo. Basically, Analyzers would first be checked in order, and when the config is parsed, analyzers would have to be globally unique from a naming perspective (Failure causes exit).
It would make ease of upgrade, addition, and management of analyzers much easier at scale.
The text was updated successfully, but these errors were encountered:
This is very important indeed and we have it on our roadmap for Cortex 2. Cortex 2 would have a analyzer store from where you'd be able to pick up the public analyzers you are interested in, and add your own private ones. Analyzers will be provided as dockers for easy deployment and they will be configurable from Cortex 2.
Provide alternative paths for analyzers in addition to standard path.
Request Type
Feature Request
Problem Description
In the application config, there is a "path to analyzers" field. It would be nice to be able to provide "N" number of paths to analyzers so that we could continue to use the built in analyzers, but also provide other locations that are checked. Each path to analyzers would have it's own config associated (We would have to determine if Global was truly global or global PER path to analyzer).
This would allow folks to create alternate repos of analyzers that could be shared in private circles, whether trust groups, whether internally at an org etc, without having to go through a merging process every time new analyzers are added to the main repo. Basically, Analyzers would first be checked in order, and when the config is parsed, analyzers would have to be globally unique from a naming perspective (Failure causes exit).
It would make ease of upgrade, addition, and management of analyzers much easier at scale.
The text was updated successfully, but these errors were encountered: