Work items

codev reads work-item references straight from your commit messages and shows them across the delivery pipeline — on builds, on release candidates, and on releases. It recognises pull request numbers, Jira issue keys, and Azure DevOps work items with no configuration.

What codev recognises

Detection runs over each commit's subject and body. A reference is picked up when it appears in one of these forms:

You write

Detected as

#123 or (#123)

Pull request

SALES-301 standing on its own (a space or line start before it, a space or colon after)

Issue key

[SALES-301]

Issue key

feat: SALES-301 …, fix(payments): SALES-301 …, feat/SALES-301

Issue key

AB#123

Azure DevOps work item

An issue key is two or more letters, a hyphen, and digits (SALES-301, DP-12). Matching is case-insensitive, and keys are shown in upper case.

When a reference is not detected

An issue key is picked up only when it stands on its own — with a space, a line start, or a colon around it — when it is in square brackets, or when it follows a conventional-commit prefix such as feat: or fix:. An issue key wrapped in round parentheses is not picked up.

For example, chore: bump to 1.4.45 (SALES-301) records no work item: the key is jammed against the (, so it is none of the recognised forms. Write it in one of these instead:

SALES-301: bump to 1.4.45
chore: bump to 1.4.45 [SALES-301]
feat: SALES-301 bump to 1.4.45

This round-parenthesis rule applies to issue keys only. A pull request number in parentheses — (#123), the form GitHub adds to squash-merge commits — is always detected.

Where work items appear

On a build, the references found in that build's commits.
On a release candidate, under the Work Items tab — the items new in that candidate, alongside the cumulative set since the last release.
On a release, the items that were deployed, with cumulative totals.

When a Jira integration is connected, detected issue keys are shown with their summary, status, and a link to the issue. Without one, the keys are still detected and listed; they are simply not enriched or linked.

Customising

Everyday detection needs no configuration — writing commit messages in a recognised form is enough. Two things can be tuned when you need them:

Which Jira issues are read. The Jira integration can be limited to specific project keys and uses a base URL to build issue links. See Jira.
Custom key patterns for the generated changelog. If your project records work items in a form the defaults do not recognise, sfp's changelog generation accepts custom workItemFilters regular expressions under the changelog block of your release configuration:
```
releaseName: sales
releasedefinitionProperties:
  changelog:
    workItemFilters:
      - "SALES-[0-9]{3,4}"
    workItemUrl: https://your-domain.atlassian.net/browse/
```
This governs the changelog file sfp writes during a release. See sfp: Generating a changelog and the Release config reference for placement and the full set of options.

workItemFilters shapes the changelog file sfp writes during a release. The work items shown in codev — on builds, release candidates, and releases — come from the built-in detection described above and are not changed by it.

Last updated 12 days ago

Was this helpful?

Good afternoon

What codev recognises

When a reference is not detected

Where work items appear

Customising

Related