Configuration
Configure data sources, analytics scope, and publication targets.
Last updated
Was this helpful?
Configure data sources, analytics scope, and publication targets.
User Story Coverage uses JSON settings files with environment variable overrides. Build the configuration in three parts: data sources, analytics scope, and publication targets.
Use Installation and first run for the first working setup.
Use the child pages in this order:
Start with Data sources.
This page defines where User Story Coverage reads source data from.
Use it to choose:
Jira or Azure DevOps as the ticket source
JQL or WIQL queries
SeaLights, Git, and SCM connection settings
Then use Project analytics scope.
This page defines what coverage data is included in the result.
Use it to choose:
which SeaLights apps are in scope
which repositories are included
which test stages or grouped stages are reported
Finish with Publication targets.
This page defines where the output is published.
Use it to choose:
Jira plugin, ADO plugin, or legacy Jira custom fields for KPIs
Confluence for detailed reports
target-specific publishing behavior and templates
Use these quick rules when you are not sure where a setting belongs:
If you are asking where does the source data come from? — use Data sources
If you are asking what coverage data is included? — use Project analytics scope
If you are asking where do the results go? — use Publication targets
By default, scripts look for a file named settings in the current directory.
You can also pass one or more --settings files.
Use CLI Reference for exact command syntax and flag usage.
You can layer several settings files in one run.
Single values are replaced by the last file.
Arrays are appended.
Objects are merged recursively.
Start from settings.sample when you need a complete example.
All settings can be overridden with environment variables.
Environment variables always win over settings files.
Use Environment variables for the full variable table, JSON examples, and CI/CD patterns.
Use output_folder to control where generated files are saved.
Leave it empty to use the current directory.
Scripts validate configuration at startup.
Check these first when a run fails:
missing required fields
invalid regex patterns
invalid URLs
invalid JSON passed through environment variables
Split shared settings and secrets into different files.
Prefer environment variables in CI/CD.
Keep credentials out of version control.
Do not commit API tokens, passwords, or production credentials.
Use Security Considerations for credential, network, and CI/CD security practices.
Last updated
Was this helpful?
Was this helpful?
{
"output_folder": "./reports"
}
