> For the complete documentation index, see [llms.txt](https://docs.sealights.io/knowledgebase/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealights.io/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/publication-targets.md).
# Publication targets
Configure where generated analytics are published for issue-level KPI updates and shared coverage pages.
{% hint style="info" %}
Use [Installation and first run](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/installation.md) for plugin installation and first-run steps.
{% endhint %}
Use [Data sources](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/data-sources.md) for Jira and Azure DevOps source-side queries and authentication.
{% hint style="info" %}
Prefer the Jira plugin and ADO plugin when possible.
Treat Jira custom fields as a legacy path.
{% endhint %}
### How publication targets are organized
Start with the publishing outcome you want:
* **Issue coverage KPIs** — write coverage values and summaries back to Jira issues or Azure DevOps work items.
* **Detailed coverage reports** — publish shared HTML-style coverage pages to a knowledge system.
### Which section answers which question
* **How do I publish coverage back to tickets or work items?** — use **Issue coverage KPIs**.
* **How do I publish a shared report page for stakeholders?** — use **Detailed coverage reports**.
* **Which targets are supported?** — use **Supported publishing targets**.
* **How does the publishing flow work overall?** — use **Publishing model**.
### Supported publishing targets
* Jira plugin
* Azure DevOps plugin
* Jira custom fields
* Confluence
* Azure DevOps Wiki — planned
### Typical use cases
* Publish sprint or release coverage to a shared knowledge base
* Give stakeholders a stable URL for detailed coverage results
* Combine issue-level KPI updates with richer shared reports
### Publishing model
A typical publishing flow looks like this:
1. Generate report data files
2. Create HTML reports when needed
3. Publish coverage to the target system
4. Share links in tickets, chat, or release notes
### Issue coverage KPIs
Use this path when you publish coverage values and short summaries back to Jira issues or Azure DevOps work items.
{% tabs %}
{% tab title="Jira plugin" %}
Use this when you are using Jira.
#### ✅ Prerequisites
* Jira connection settings already work in [Data sources](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/data-sources.md)
* The Jira plugin is installed
* You know whether the target is Jira Cloud or Jira Server/Data Center
#### 🚀 Steps
{% stepper %}
{% step %}
### Choose the template path
Use `summary_rich_layout_v1` for Jira Cloud. Use `text_only_layout_v1` when `on_prem` is `true`.
Use raw Jira ADF JSON only when you need full document control.
{% endstep %}
{% step %}
### Add the summary template
Provide the template in your settings file or with `JIRA_SUMMARY_RICH_TEMPLATE`.
{% endstep %}
{% step %}
### Publish the KPI update
Run the publish flow from [CLI Reference](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/cli-reference.md).
{% endstep %}
{% endstepper %}
#### 📤 Expected Outcome
Jira issues show updated coverage values and summary content. Optional detailed report links appear when the template includes them.
Jira Cloud template
Use `summary_rich_layout_v1` for rich Jira Cloud output.
```json
{
"template_type": "summary_rich_layout_v1",
"content": [
{
"type": "quality_gate",
"field": "overall",
"warning": 80,
"failure": 30,
"label": "Code Changes Coverage",
"coverage_text": "{overall}%"
},
{
"type": "text",
"text": "{overall_count} covered / {results_count} modified methods"
},
{
"type": "link",
"text": "Coverage Report",
"text_url": "{detailed_coverage_report_url}",
"skip_if_empty": true
}
]
}
```
Supported rich blocks:
* `quality_gate` — renders a Jira panel colored from coverage thresholds. Set `warning`/`failure` thresholds; above `warning` = success panel, above `failure` = warning panel, otherwise error. Use `field` with a report key (e.g. `overall`).
* `info` — renders a Jira panel with a fixed label and highlighted coverage value. Use `info_type` (`info`, `note`, `success`, `warning`, `error`).
* `stage_badges` — renders a row of stage coverage badges. Provide `stages` as an ordered array, or set `source` to `grouped_test_stages`, `test_stages`, or `all`.
* `text` — plain paragraph with `{placeholder}` substitution.
* `link` — linked text or external image. `skip_if_empty: true` omits the block when the URL is empty. For images, provide `image` with `url`, `layout`, `alt_text`, `height`, `width`, and optional `external_url`.
* `divider` — horizontal rule.
* `empty_paragraph` — blank spacing.
Jira Server or Data Center template
Use `text_only_layout_v1` when `on_prem` is `true`.
```json
{
"template_type": "text_only_layout_v1",
"indent": " ",
"content": [
{
"type": "coverage_section",
"header": "Coverage:",
"stages": [
{ "label": "Overall", "field": "overall", "warning": 80, "failure": 30, "show_icon": true }
]
},
{ "type": "empty_line" },
{
"type": "link",
"text": "Detail report: {detailed_coverage_report_url}"
}
]
}
```
This produces output like:
```
Coverage:
Overall: 🟢 87%
Test Stage 1: 🟡 65%
Test Stage 2: 🔴 22%
Test Stage 3: 🟢 91%
Summary:
Total of 42 methods were modified in 8 files.
Number of methods tested in one or more test stages: 37
Number of methods untested in one or more test stages: 5
Number of methods untested in Test Stage 1: 15
Number of methods untested in Test Stage 2: 33
Number of methods untested in Test Stage 3: 4
Here is the detail report: https://confluence.example.com/display/MYSPACE/PROJ-123
```
Supported plain-text blocks:
* `coverage_section`
* `summary_section`
* `text`
* `link`
* `divider`
* `empty_line`
Common placeholders
| Key | Description |
| -------------------------------- | ---------------------------------------------------------- |
| `{ticket_id}` | The Jira ticket key |
| `{results_count}` | Total modified methods |
| `{results_files}` | Total modified files |
| `{overall_count}` | Covered methods (overall) |
| `{_coverage}` | Raw coverage % for a stage |
| `{_coverage_rounded}` | Rounded coverage % for a stage |
| `{}` | Alias for rounded coverage % |
| `{detailed_coverage_report_url}` | URL of the Confluence detail page, if generated |
| `{uncovered_method_report_url}` | URL of the uncovered-methods Confluence page, if generated |
| `{extra_link_url}` | URL from `jira.extra_link` |
| `{extra_link_text}` | Text from `jira.extra_link` |
{% endtab %}
{% tab title="ADO plugin" %}
Use this when you are using Azure DevOps.
#### ✅ Prerequisites
* Azure DevOps source settings already work in [Data sources](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/data-sources.md)
* The ADO plugin is installed
* The WIQL query already returns the target work items
#### 🚀 Steps
{% stepper %}
{% step %}
### Reuse the Azure DevOps connection
In most setups, the plugin reuses:
* `authorization`
* `organization`
* `project`
* the work items selected by `wiql`
{% endstep %}
{% step %}
### Confirm the plugin setup
Use [Installation and first run](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/installation.md) for the install and updater flow.
{% endstep %}
{% step %}
### Publish the KPI update
Run the publish flow from [CLI Reference](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/cli-reference.md).
{% endstep %}
{% endstepper %}
#### 📤 Expected Outcome
Azure DevOps work items show updated coverage values and summaries.
{% endtab %}
{% tab title="Jira Custom Fields (Legacy)" %}
Use this when you are using legacy Jira custom fields.
{% hint style="warning" %}
Use this path only when you cannot use the Jira plugin.
{% endhint %}
#### ✅ Prerequisites
* Jira access already works in [Data sources](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/data-sources.md)
* Target custom fields already exist in Jira
* You know the custom field IDs for summary and numeric coverage
#### 🚀 Steps
{% stepper %}
{% step %}
### Add the custom field mapping
```json
{
"jira": {
"jira_custom_fields": {
"summary_rich": {
"id": "customfield_10918",
"template_file": "summary_template.json"
},
"coverage": {
"overall": "customfield_10900",
"unit_tests": "customfield_10901"
}
},
"extra_ticket_fields": [
{"name": "Team", "field": "customfield_10400.name"},
{"name": "Priority", "field": "priority.name"}
],
"extra_link": {
"link": "https://yourcompany.com/coverage/{ticket_id}",
"text": "View Coverage Dashboard",
"image": {
"url": "https://yourcompany.com/badge/{ticket_id}.png",
"layout": "center",
"alt_text": "Coverage badge",
"height": 20,
"width": 100
}
},
"notify_users": false,
"on_prem": false
}
}
```
{% endstep %}
{% step %}
### Set the optional fields
* `extra_ticket_fields` — optional extra Jira fields for reports.
* `extra_link` — optional external dashboard link.
* `notify_users` — optional Jira notification behavior.
* `on_prem` — toggle for Jira Server or Data Center behavior.
{% endstep %}
{% step %}
### Publish the KPI update
Run the publish flow from [CLI Reference](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/cli-reference.md).
{% endstep %}
{% endstepper %}
#### 📤 Expected Outcome
Jira custom fields receive updated coverage values and summary content.
{% endtab %}
{% endtabs %}
### Detailed coverage reports
Use this path when you publish richer HTML-style coverage pages instead of issue-level KPI updates.
{% tabs %}
{% tab title="Confluence" %}
Use this when you are using Confluence.
#### ✅ Prerequisites
* Confluence access details
* A target space and parent page
* Generated report data ready for publishing
#### 🚀 Steps
{% stepper %}
{% step %}
### Add the Confluence connection
```json
{
"confluence": {
"authorization": "Basic base64-credentials",
"base_url": "https://yourcompany.atlassian.net",
"space_key": "DEV",
"ancestor_id": "123456789",
"verify_ssl": true
}
}
```
{% endstep %}
{% step %}
### Set the publishing options
Use `type: "single_page"` for new configurations.
{% endstep %}
{% step %}
### Publish the report
Run the report generation and publishing flow from [CLI Reference](/knowledgebase/setup-and-configuration/integrations/user-story-coverage/cli-reference.md).
{% endstep %}
{% endstepper %}
#### 📤 Expected Outcome
Confluence receives a published coverage summary page and related detail content.
Key fields
* `authorization` — required authorization header.
* `base_url` — required Confluence URL.
* `space_key` — required target space.
* `ancestor_id` — required parent page ID.
* `verify_ssl` — optional SSL verification toggle.
Publishing options
```json
{
"confluence": {
"on_prem": false,
"note": "This page is auto-generated. Changes will be overwritten.",
"extra_summary_fields": ["Team", "Priority"],
"summary_page_title": "Sprint Coverage Summary",
"details_page_prefix": "Coverage -",
"report_format": {
"type": "single_page",
"primary_coverage": {
"stage": "overall",
"quality_gate": {
"warning": 80,
"failure": 30
}
}
}
}
}
```
{% endtab %}
{% tab title="ADO Wiki" %}
Use this when you are using Azure DevOps Wiki.
{% hint style="info" %}
Azure DevOps Wiki support is planned by EOY2026.
{% endhint %}
#### ✅ Prerequisites
* A need to publish into Azure DevOps documentation
* A temporary Confluence target for current production use
#### 🚀 Steps
{% stepper %}
{% step %}
### Use Confluence for the current rollout
Use Confluence until Azure DevOps Wiki support is available.
{% endstep %}
{% endstepper %}
#### 📤 Expected Outcome
Current production publishing continues through Confluence. You can switch when Azure DevOps Wiki support is released.
{% endtab %}
{% endtabs %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.sealights.io/knowledgebase/setup-and-configuration/integrations/user-story-coverage/configuration/publication-targets.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.