Skip to main content
Guides

Jira ticket linking

Detect Jira ticket IDs in issue and PR text and render them as inline links in release notes.

When your team puts Jira ticket IDs in PR or issue titles or descriptions (e.g. "Fix login PROJ-123"), ReleaseJet detects them and renders clickable links beside each issue line in the generated release notes. There are no Jira API calls — detection is pure text matching against an allowlist of project keys, so unrelated patterns like HTTP-2 or IPV-6 don't false-positive.

Available since 1.18.0.

Configuration

Add a top-level jira: block to .releasejet.yml:

jira:
  baseUrl: https://acme.atlassian.net   # or ${JIRA_URL}
  projects: [PROJ, BUG]

Both fields are required when the jira: block is present:

  • baseUrl — Jira instance root. A trailing slash is allowed and stripped at config load. Supports ${ENV_VAR} expansion (same mechanism as notifications.webhookUrl), so self-hosted hostnames can stay out of source control.
  • projects — non-empty allowlist of Jira project keys. Each key must match ^[A-Z][A-Z0-9]+$ — uppercase letters/digits, must start with a letter, length at least 2. Lowercased keys, leading-digit keys, and underscored keys are rejected at config-load time.

Activation is presence-driven: omit the jira: block to disable. There is no enabled flag.

Detection behavior

  • Case-sensitive. Only uppercase keys match. proj-1 does not match.
  • Word-boundary anchored on both sides. FOOPROJ-1 does not match. PROJ-1.0 matches as PROJ-1 (the period is a word boundary).
  • First-appearance order preserved, scanning the title first, then the body.
  • Duplicates removed. A ticket mentioned in both the title and the body appears once.
  • Both title and body are scanned for every issue or PR.

URL construction

The link target is ${baseUrl}/browse/${id} exactly. No path normalization is applied beyond the trailing-slash strip at config load.

Output

A bullet for an issue with one detected ID:

- Fix login (#42) — [PROJ-123](https://acme.atlassian.net/browse/PROJ-123)

Multiple IDs on the same issue render space-separated:

- Export PDF (#43) — [PROJ-2](https://acme.atlassian.net/browse/PROJ-2) [BUG-9](https://acme.atlassian.net/browse/BUG-9)

Issues with no detected IDs render unchanged — no trailing em-dash, no placeholder:

- Refactor settings panel (#44)

Coexistence with description: extract

Jira links and the description: extract feature compose cleanly. Jira links stay inline on the bullet line; the extracted description renders as a nested sub-bullet underneath:

- Fix login (#42) — [PROJ-123](https://acme.atlassian.net/browse/PROJ-123)
  - Users were redirected to /login instead of their target after SSO callback…

Validation errors

Errors raised at config-load time, with their literal text:

TriggerError
jira: is not an objectjira: expected an object with "baseUrl" and "projects" fields.
baseUrl missing or emptyjira.baseUrl is required when jira section is present (non-empty string).
projects missing or emptyjira.projects must be a non-empty array of project keys.
A project key fails the ^[A-Z][A-Z0-9]+$ checkjira.projects[i] '<value>' is not a valid project key (expected uppercase letters and digits, e.g. PROJ).

All errors are prefixed with Invalid config in .releasejet.yml, the same as other config errors.

${ENV_VAR} expansion

baseUrl participates in the same env-var expansion pipeline as notifications.webhookUrl. Useful when the Jira hostname differs across environments or you don't want it stored in the repo:

jira:
  baseUrl: ${JIRA_URL}
  projects: [PROJ, BUG]

If JIRA_URL is unset at load time, expansion produces an empty string and the baseUrl is required validation error fires.

releasejet init

releasejet init prompts for Jira setup after the contributors question:

Set up Jira ticket linking? (y/N)

If you answer yes:

  1. The wizard prompts for the base URL. It accepts a literal URL or an ${ENV_VAR} reference. Empty input re-prompts.
  2. It then prompts for project keys, comma-separated. Input is auto-uppercased and deduped. Empty input re-prompts.

If you decline, the wizard writes a commented-out jira: placeholder block to the generated .releasejet.yml so the feature stays discoverable when you open the file later.

Tips

  • Keep the project allowlist tight — only the keys your team actually uses. Adding * or every key in the org defeats the false-positive guard that's the whole point of the allowlist.
  • For self-hosted Jira behind SSO, prefer ${JIRA_URL} over a literal so dev, staging, and CI can each point at the right instance.
  • Combine with description: extract and the contributors section for a one-stop release-notes summary that links out to the underlying tracker tickets.