Overview
Functional validation reads the issues a PR claims to close, breaks each one into individual objectives, and judges every objective against the diff. The result is an Implementation Status section in the Gitar dashboard comment, one block per linked issue, least complete first.Objective by Objective
Each requirement in the issue is tracked on its own, so a PR that does most of the work reads as partial rather than done
Re-Judged on Every Push
New commits are re-checked against the same objectives, so the section keeps up with the branch
Functional validation is included on the Enterprise plan. A tracker issue needs that integration connected. Your code host’s own issues need nothing connected.
Supported Issue Sources
Bitbucket Data Center has no issue tracker of its own, so link a Jira issue there instead.
A tracker key is the same shape on Jira, Linear, Plane, and YouTrack, so connect one tracker per organization. With more than one connected, Gitar reads the key against Jira first, then Linear, then Plane, then YouTrack.
How It Works
1
Gitar finds the linked issue
Gitar looks for issue keys in the PR title, description, and branch name. Nothing is linked unless the PR claims the issue, so a passing mention is ignored.
2
The issue becomes a list of objectives
Gitar reads the issue text from its source and derives the concrete objectives it asks for.
3
Each objective is judged against the diff
Every objective is marked complete or pending based on the current diff. Pushing new commits re-runs the judgement, and editing the issue reconciles the objective list against it.
4
Implementation Status appears in the dashboard comment
The section is added to the existing Gitar comment on the PR. Gitar posts no separate comment and adds no status check.
Linking an Issue
Reference the issue in the PR title, the PR description, or the branch name, the way you already do to close an issue. A tracker key (PROJ-123) and your code host’s own issue number (#123) both work.
A #123 refers to an issue in the PR’s own repository. Another repository’s issue (other/repo#123) is not linked.
On Azure DevOps, work items attached to the PR are picked up directly, so there is nothing to write in the description.
Once Gitar finds an issue it can read, it links it and validates the PR against it. Nothing needs configuring.
Reading the Section
The section header carries a count of issues fully implemented, and each issue gets its own block with a status badge and an objective counter.
Pending objectives are listed in full, since they are the ones that need attention. Completed objectives collapse behind a complete toggle. Blocks are ordered least complete first, and the whole section renders collapsed once every linked issue is fully implemented.
On Bitbucket the same content renders as headings and lists, since collapsible sections are not supported there.
The section is hidden when no linked issue produced any objectives, so a PR with no tracked issue looks unchanged.
Changing the Issue
Objectives track the issue rather than a snapshot of it. Add a requirement and it shows up as pending on the next run. Remove one and it stops counting against the PR: the objective total drops instead of the completion count going up, so cutting scope can never read as work finished.Limits
A PR validates at most 5 linked issues. Extra keys beyond that are ignored. Gitar reads the issue text but never writes to it. Objectives, statuses, and counts live only in the PR comment - your tracker stays the source of truth. To have Gitar post back to the issue on merge, see Jira, Linear, Plane, and YouTrack. Objectives belong to the PR being reviewed. Two PRs against the same issue each track their own set, and Gitar has no combined per-issue view.Related
Jira Integration
Connect Jira so Gitar can read linked issues
Linear Integration
Connect Linear so Gitar can read linked issues
Plane Integration
Connect a Plane workspace so Gitar can read linked work items
The Gitar Dashboard
Where Implementation Status is rendered
Plans
What each plan includes