Skip to main content
Guides

Excluding internal issues

Drop internal-only issues from release notes with the excludeLabels filter.

Some issues — refactors, cleanup, internal-only chores — shouldn't appear in client-facing release notes. The excludeLabels field drops any issue carrying one of the listed labels before categorization, so excluded work never makes it into the published markdown or the webhook envelope.

Available since 1.22.0.

Configuration

excludeLabels: [internal, chore]

Any issue tagged with at least one of these labels is filtered out. Omit the field (or set it to []) to keep the previous behavior — every closed issue is considered.

Behavior

  • Exclude wins on collisions with categories. An issue tagged with both internal and feature lands in the excluded bucket, not under "New Features".
  • No interaction with uncategorized: strict. Excluded issues are removed before categorization, so they never trip a strict-mode failure even when they would otherwise be uncategorized.
  • Markdown and webhook output match. Excluded issues are absent from both surfaces — the filter runs once, upstream of every downstream consumer.
  • Order doesn't matter. Listing labels in any order produces the same result; matching is set-membership, not first-match.

CLI output

When at least one issue was excluded, generate prints a single summary line under the spinner success message:

✓ Collected 12 issues
  Excluded 3 issues by excludeLabels filter (internal, chore)

The summary lists only the labels that actually matched something, deduped. It appears on stdout as an operator-facing signal — it is not part of the published release notes.

When nothing was excluded, the line is silent.

Tips

  • Pair with categories to keep your label taxonomy clean: declare the labels that should ship under headings, list the rest under excludeLabels.
  • If you're seeing noise in uncategorized output that is genuinely internal, prefer excludeLabels over a catch-all chore → "Other" mapping — it suppresses the noise instead of reframing it.
  • Use releasejet validate (or run generate with --dry-run) to confirm what gets dropped before cutting a real tag.