feat(jira): add --jira-trailer flag to extract Jira issue key from git trailer

[vidhu-balad]

Summary

• Adds a --jira-trailer <key> flag to kosli attest jira
• When set, the command reads only lines of the form <key>: <value> from the commit message and uses those values as the sole source of Jira issue references
• The full commit message body and branch name scan are skipped entirely, eliminating false positives from other trailers (e.g. Ona-Environment-Id: ONA-456) whose values happen to match the Jira key pattern
• Key match is case-insensitive; multiple occurrences of the same trailer key are supported
• All existing behaviour is unchanged for users who do not set the flag

Changes

• internal/gitview/gitView.go — new GetTrailerValues(message, key string) []string function
• internal/gitview/gitView_test.go — 6 unit tests covering no match, single match, case-insensitive key, multiple occurrences, non-matching trailers ignored, whitespace trimming
• cmd/kosli/root.go — jiraTrailerFlag constant
• cmd/kosli/attestJira.go — --jira-trailer flag wired into the issue-finding logic
• cmd/kosli/attestJira_test.go — 3 integration tests: trailer used successfully, trailer absent (non-compliant but reported), trailer absent with --assert (error)

Test plan

• make test_integration_single TARGET=AttestJiraCommandTestSuite — tests 27, 28, 29 cover the new flag
• go test ./internal/gitview/... -run TestGitViewTestSuite/TestGetTrailerValues — unit tests for GetTrailerValues
• make lint — passes with 0 issues

🤖 Generated with Claude Code

[claude]

Reviewing latest changes

• Gather context (diff vs origin/main, prior review threads)
• Static analysis (go build, go vet, go mod tidy)
• Review changed code
• Post review

View job run · feat/jira-trailer-flag

[claude]

Two edge cases in the prefix match:

1. Leading whitespace is not tolerated. HasPrefix runs on the raw line, so " Jira: EX-1" does not match. Commit messages written through editors/templates or pasted from git log output (which indents by 4 spaces) will silently produce no matches.
2. A key supplied with a trailing colon breaks silently. --jira-trailer "Jira:" builds the prefix "jira::", which never matches, with no error or warning.

Trimming both sides handles (1) cheaply and keeps everything else identical (TrimSpace on the value already covers \r from CRLF messages):

Suggested change

	for _, line := range strings.Split(message, "\n") {
	if strings.HasPrefix(strings.ToLower(line), prefix) {
	value := strings.TrimSpace(line[len(prefix):])
	for _, line := range strings.Split(message, "\n") {
	line = strings.TrimSpace(line)
	if strings.HasPrefix(strings.ToLower(line), prefix) {
	value := strings.TrimSpace(line[len(prefix):])

For (2), consider prefix := strings.ToLower(strings.TrimSuffix(strings.TrimSpace(key), ":")) + ":".

[claude]

--jira-trailer silently disables --jira-secondary-source and --ignore-branch-match. Both are accepted without complaint and then have no effect, which is easy to get wrong in a CI pipeline (--jira-secondary-source ${{ github.head_ref }} quietly becoming a no-op is a compliance-relevant silent change). This file already uses the repo's helper for exactly this shape of problem (lines 220–233), so:

err = MuXRequiredFlags(cmd, []string{"jira-trailer", "jira-secondary-source"}, false)
if err != nil {
	return err
}

For --ignore-branch-match a logger.Warn in run() would be enough, since it's already implied by the trailer mode.

Separately: trailer values are still fed through jira.FindJiraIssueKeys, so Jira: EX1 or Jira: 1234 yields nothing at all — no warning, just a non-compliant attestation. Worth a logger.Warn when len(trailerValues) > 0 && len(issueIDs) == 0, since in trailer mode the user has explicitly declared where the key lives and a mismatch is almost certainly a mistake rather than an absent reference.

[claude]

Naming/semantics nit worth resolving before this ships, since the name sets an expectation the implementation doesn't meet: real git trailers (per git interpret-trailers) live only in the last paragraph of the message. This function matches <key>: on any line, including the subject and prose in the body — so fix: EX-1 handled\n\nJira: ask the team which ticket applies would treat the prose line as a trailer value.

For the current use case that leniency is harmless (the value goes through the Jira key regex anyway), but the doc comment should say so explicitly rather than calling them "trailer lines", e.g. "matches any line of the form <key>: <value> anywhere in the message, not only trailers in the final paragraph". Otherwise the next caller will reasonably assume git trailer semantics.

[claude]

Flag help is clear and accurate. The gap is the command's Long description in cmd/kosli/attestJira.go:41–68, which documents the search sources in prose and wasn't updated:

• Line 41 still says the command "Parses the given commit's message, current branch name or the content of --jira-secondary-source" with no mention of trailer mode.
• Line 68 documents --ignore-branch-match but not that --jira-trailer supersedes it.
• Lines 60–63 recommend --jira-secondary-source as the workaround for the CVE--style project-key collision — --jira-trailer is now the better answer to that exact problem and should be mentioned there.

Per the slice checklist in CLAUDE.md ("Does kosli <command> --help reflect the change?"), the prose in Long is part of --help. An attestJiraExample entry would help too, since every other non-obvious flag has one.

[claude]

The --assert failure messages still say "commit message or branch name", which is exactly what trailer mode does not read.

Both assert paths below hardcode the old wording:

• attestJira.go:374 — "no Jira references are found in commit message or branch name"
• attestJira.go:382 — "missing Jira issues from references found in commit message or branch name"

With --jira-trailer Jira the commit body and branch were never scanned, so a user who hits the first error is told to look in two places the command deliberately ignored. The actual cause is "the commit has no Jira: trailer" (or the trailer value didn't match the Jira key pattern) — a materially different fix on the user's side, and this is the one message they get in a failing CI job.

Test 29 pins the wrong wording as golden (attestJira_test.go:364), so the wording is now covered by a test asserting it, which makes it harder to notice later.

Threading the source through both messages keeps them accurate in either mode:

searchedIn := "commit message or branch name"
if o.trailerKey != "" {
	searchedIn = fmt.Sprintf("the '%s' trailer of the commit message", o.trailerKey)
}

then fmt.Errorf("%sno Jira references are found in %s", errString, searchedIn) and fmt.Errorf("%smissing Jira issues from references found in %s%s", errString, searchedIn, issueLog), with test 29's golden updated to match.

Fix this →

[mbevc1]

@vidhu-balad there is still some feedback from the bot

[claude]

Half of the headline claim is untested: nothing covers "the branch name scan is skipped".

Test 27 (now with --assert — good fix) proves the commit body is not scanned, because ONA-999 sits in the message and would break the assert if it leaked. But the PR description makes two claims, and the branch half has no test: execJiraTestCase already supports branchName (line 414), so the case is cheap to add and the code path (jiraSearchText vs. the trailer branch, attestJira.go:312-320) is genuinely distinct.

ONA-999 in the branch name is the right probe — it matches the Jira key pattern, so under the old scanning behaviour it becomes an issue ID that Jira cannot resolve, and issueFoundCount != len(issueIDs) fails the assert:

Suggested change

	},
	},
	{
	name: "30 --jira-trailer does not scan the branch name for issue references",
	cmd: fmt.Sprintf(`attest jira --name bar
	--jira-base-url https://kosli-test.atlassian.net
	--jira-trailer Jira
	--assert
	--repo-root %s %s`, suite.tmpDir, suite.defaultKosliArguments),
	golden: "jira attestation 'bar' is reported to trail: test-123\n",
	additionalConfig: jiraTestsAdditionalConfig{
	branchName: "bugfix/ONA-999",
	commitMessage: "fix: some change\n\nJira: EX-1",
	},
	},

A second gap worth a test either way: --jira-trailer together with --jira-secondary-source (see the open thread on attestJira.go) — whichever way that's resolved (error via MuXRequiredFlags, or warn-and-ignore), the resolution deserves a case pinning it, since today it silently does nothing.

[claude]

"bypasses pattern-scanning entirely" isn't true, and this paragraph is the one place a user acts on it.

Trailer values still go through jira.FindJiraIssueKeys (attestJira.go:344), which applies both the key regex and isPartialMultiSegment. --jira-trailer changes which text is scanned, not how it is parsed.

Concretely, a user with project key CVE who reads this and writes Jira: CVE-2026-41284 gets the regex match CVE-2026, whose only occurrence is followed by -4, so it is filtered out and the attestation is non-compliant — the exact outcome the paragraph promises to avoid. (The new logger.Warn at line 347 does at least surface it now, which is a good addition.)

The flag genuinely does help — it removes the surrounding commit text that causes most collisions — so the fix is just to scope the claim:

Suggested change

	Note: if your Jira project key collides with this pattern (e.g. a project key of ^CVE^), an
	issue reference that happens to be the prefix of a longer hyphenated number (such as a CVE
	identifier) will be filtered out. Use ^--jira-secondary-source^ with a different identifier
	format as a workaround.
	identifier) will be filtered out. Use ^--jira-trailer^ to read issue keys from a dedicated
	git trailer line (e.g. ^Jira: CVE-42^), which bypasses pattern-scanning entirely.
	Alternatively, use ^--jira-secondary-source^ with a different identifier format.
	Note: if your Jira project key collides with this pattern (e.g. a project key of ^CVE^), an
	issue reference that happens to be the prefix of a longer hyphenated number (such as a CVE
	identifier) will be filtered out. Use ^--jira-trailer^ to read issue keys from a dedicated
	git trailer line (e.g. ^Jira: CVE-42^), which narrows the scanned text to the trailer value
	so unrelated identifiers elsewhere in the commit cannot interfere. The same pattern rules
	still apply to the trailer value itself.
	Alternatively, use ^--jira-secondary-source^ with a different identifier format.

Fix this →

[claude]

Leftover from splitting the sentence: line 43 ends for Jira issue references of the form. — the "of the form" now dangles, since the form is defined two lines later under its own heading. This is the first thing kosli attest jira --help prints.

Suggested change

	By default, parses the given commit's message, current branch name, or the content of the
	^--jira-secondary-source^ argument for Jira issue references of the form.
	By default, parses the given commit's message, current branch name, or the content of the
	^--jira-secondary-source^ argument for Jira issue references.

[claude]

Two leftovers from the previous round, both cheap:

1. The key itself is never TrimSpaced — only TrimRight(key, ":"). Lines are trimmed (line 286) but the key isn't, so --jira-trailer " Jira" builds the prefix " jira:" and silently matches nothing. Since a value coming from a config file or KOSLI_JIRA_TRAILER can easily pick up a stray space, this fails in the one place it's hardest to spot.
2. Empty values are now silently dropped (line 289) — a deliberate and sensible choice, but the doc comment doesn't say so, and there's no unit case for it. It also interacts with the new warning in attestJira.go:347: Jira: with an empty value yields len(trailerValues) == 0, so the user gets neither the issue key nor the "trailer found but no valid keys" warning.

Both are covered by tightening the comment and the prefix:

Suggested change

	// GetTrailerValues extracts the values of all trailer lines in a commit message
	// that match the given key. The key comparison is case-insensitive. Trailer lines
	// have the format "<key>: <value>". Returns an empty (non-nil) slice if none are found.
	func GetTrailerValues(message, key string) []string {
	result := []string{}
	prefix := strings.ToLower(strings.TrimRight(key, ":")) + ":"
	// GetTrailerValues returns the values of every line in a commit message of the form
	// "<key>: <value>". The key comparison is case-insensitive, surrounding whitespace on
	// both the key and the line is ignored, and a trailing ":" on the key is tolerated.
	// Note this matches any such line anywhere in the message, not only trailers in the
	// final paragraph as `git interpret-trailers` defines them. Lines with an empty value
	// are skipped. Returns an empty (non-nil) slice if none are found.
	func GetTrailerValues(message, key string) []string {
	result := []string{}
	prefix := strings.ToLower(strings.TrimRight(strings.TrimSpace(key), ":")) + ":"

[claude]

Three behaviours added in the latest commit have no test, which is worth closing given the TDD discipline in CLAUDE.md — the first in particular is a new error path that changes what a valid command line is:

1. MuXRequiredFlags(cmd, []string{"jira-trailer", "jira-secondary-source"}, false) (attestJira.go:260) — nothing pins the error. A one-line golden case locks it in and documents the resolution of that thread.
2. The branch-name half of the PR's headline claim — test 27 proves the commit body isn't scanned (ONA-999 would break the assert); nothing proves the branch isn't. execJiraTestCase already supports branchName (line 414).
3. The two new logger.Warn branches (attestJira.go:338 and 347) — optional, but (2) below is nearly free.

Suggested change

	additionalConfig: jiraTestsAdditionalConfig{
	{
	wantError: true,
	name: "30 --jira-trailer and --jira-secondary-source are mutually exclusive",
	cmd: fmt.Sprintf(`attest jira --name bar --commit HEAD
	--jira-base-url https://kosli-test.atlassian.net
	--jira-trailer Jira
	--jira-secondary-source some-branch %s`, suite.defaultKosliArguments),
	golden: "Error: only one of --jira-trailer, --jira-secondary-source is allowed\n",
	},
	{
	name: "31 --jira-trailer does not scan the branch name for issue references",
	cmd: fmt.Sprintf(`attest jira --name bar
	--jira-base-url https://kosli-test.atlassian.net
	--jira-trailer Jira
	--assert
	--repo-root %s %s`, suite.tmpDir, suite.defaultKosliArguments),
	golden: "jira attestation 'bar' is reported to trail: test-123\n",
	additionalConfig: jiraTestsAdditionalConfig{
	branchName: "bugfix/ONA-999",
	commitMessage: "fix: some change\n\nJira: EX-1",
	},
	},
	}

ONA-999 in the branch is the right probe for (2): it matches the Jira key pattern, so under the old scanning behaviour it becomes an unresolvable issue ID and issueFoundCount != len(issueIDs) fails the assert.

Fix this →

[claude]

Now that --jira-trailer and --jira-secondary-source are mutually exclusive (attestJira.go:260), neither flag's help says so. Worth noting in both strings, because bindFlags sets flags from env/config via cmd.Flags().Set(...) (root.go:673), which marks them Changed — so an org that exports KOSLI_JIRA_SECONDARY_SOURCE in a shared CI step and then adds --jira-trailer Jira on the command line hits a hard error, not a silently-ignored flag.

That's the right behaviour (a silent no-op here is compliance-relevant, which is what the earlier thread was about) — it just needs to be discoverable from --help rather than from a failing pipeline.

Suggested change

	jiraTrailerFlag = "[optional] The git trailer key to use as the sole source of Jira issue references (e.g. '--jira-trailer Jira' extracts the value of 'Jira: <issue-key>' lines from the commit message). When set, the commit message body and branch name are not scanned."
	jiraSecondarySourceFlag = "[optional] An optional string to search for Jira ticket reference, e.g. '--jira-secondary-source ${{ github.head_ref }}'. Mutually exclusive with --jira-trailer."
	ignoreBranchMatchFlag = "Ignore branch name when searching for Jira ticket reference."
	jiraTrailerFlag = "[optional] The git trailer key to use as the sole source of Jira issue references (e.g. '--jira-trailer Jira' extracts the value of 'Jira: <issue-key>' lines from the commit message). When set, the commit message body and branch name are not scanned. Mutually exclusive with --jira-secondary-source."

[claude]

Corrected anchor for the suggestion in my comment just above — that one was anchored to line 172 alone, so its three-line block would have duplicated lines 170–171. This range is the right one; ignore the other block.

Now that --jira-trailer and --jira-secondary-source are mutually exclusive (attestJira.go:260), neither flag's help says so. Worth stating in both, because bindFlags sets flags from env/config via cmd.Flags().Set(...) (root.go:673), which marks them Changed — so an org that exports KOSLI_JIRA_SECONDARY_SOURCE in a shared CI step and then adds --jira-trailer Jira on the command line hits a hard error rather than a silently-ignored flag.

That's the right behaviour (a silent no-op here is compliance-relevant, which is what the earlier thread was about) — it just needs to be discoverable from --help instead of from a failing pipeline.

Suggested change

	jiraSecondarySourceFlag = "[optional] An optional string to search for Jira ticket reference, e.g. '--jira-secondary-source ${{ github.head_ref }}'"
	ignoreBranchMatchFlag = "Ignore branch name when searching for Jira ticket reference."
	jiraTrailerFlag = "[optional] The git trailer key to use as the sole source of Jira issue references (e.g. '--jira-trailer Jira' extracts the value of 'Jira: <issue-key>' lines from the commit message). When set, the commit message body and branch name are not scanned."
	jiraSecondarySourceFlag = "[optional] An optional string to search for Jira ticket reference, e.g. '--jira-secondary-source ${{ github.head_ref }}'. Mutually exclusive with --jira-trailer."
	ignoreBranchMatchFlag = "Ignore branch name when searching for Jira ticket reference."
	jiraTrailerFlag = "[optional] The git trailer key to use as the sole source of Jira issue references (e.g. '--jira-trailer Jira' extracts the value of 'Jira: <issue-key>' lines from the commit message). When set, the commit message body and branch name are not scanned. Mutually exclusive with --jira-secondary-source."