Documentation request: How tools to run are selected

[alles60]

The wiki defines in its FAQ how MSDO selects which tools to run. However, it fails so give more than one example, and not a complete one at that.

The wiki, or the README of the action, should explain clearly the condition that defines which tool will run. From what I could gather, I understand those conditions:

• BinSkim: Runs if .dll files are present in the repository, so it will run if you run the action after a dotnet build.
• Checkov: Runs with bicep or arm files present, as well as GitHub actions workflows.
• ESLint: Will run in javascript project. I'm not sure if an eslint configuration file is mandatory
• TemplateAnalyser: Runs with bicep files or arm files present
• Trivy: I've only been able to run it when called explicitly with the tools input and the GDN_TRIVY_TARGET image environment variable set

The msdo cli tool seems to be closed source, so I haven't been able to analyse the code to find the details of each tool. It should be more explicitly defined in the documentation.

[sourabhsy]

Hi there,

Thank you for raising this request and for your interest in understanding how tools are selected within the MSDO Action.

You're absolutely right that our current public documentation does not yet cover the selection logic for tools in detail and we recognize that this creates a gap in transparency for users like yourself. We are considering adding a dedicated “Examples” section to the documentation that would illustrate how tool selection works across different scenarios. This would include multiple sample configurations to help clarify the behavior and logic behind tool execution.

In the meantime, if you have a specific use case or pipeline setup you’re working with, feel free to share it here. We’d be happy to provide guidance or examples that may help until the documentation is updated.

Thanks again for your feedback—it’s helping us improve the experience for all users.

[DimaBir]

Documentation for this is up in #272.

The README now has a "How tools are selected" section covering the two paths: with tools set, only the listed analyzers run and no content-based selection happens at all; with tools unset, the CLI inspects the repository and decides. categories and languages narrow a run while still letting the CLI select.

Your observation about container-mapping being different is correct and is now documented. It is not a CLI analyzer — it is implemented by this action's own pre and post steps, is explicitly filtered out before the --tool argument is built, and its pre/post steps run on every use of the action regardless of what tools contains. Listing it as the sole value of tools is how you skip the analyzer run while keeping container mapping.

On the per-tool trigger conditions you reconstructed: the selection logic itself lives in the closed-source CLI, so rather than publish a list that could drift out of sync with it, the section states where the logic lives and what the action-side contract is. Getting the detailed per-tool conditions published is a separate ask against the CLI documentation.