Design

Trigger: git post-receive hook

• Installed into every bare repo under hooks/post-receive at creation time
• One-line addition to RepoHandler.CreateRepo in Sztabina
• Migration script installs hook into all existing repos
• Hook reads stdin (oldSha newSha refName), fetches commit messages via git log, calls POST /internal/notify/push on Sztabina

Sztabina: new internal endpoint

• POST /internal/notify/push
• Receives push data, extracts commits and branch name
• Fires POST /api/internal/hooks/push on Spring backend

Spring backend: IssueReferenceService

• Parses issue keys from commit messages and branch name
• Resolves keys to issue IDs via existing global key lookup
• Persists to issue_references table
• Duplicate guard: upsert on (issue_id, commit_sha, source_type)

PR linking

• On PR create/update: parse PR title for issue keys
• Same IssueReferenceService, source_type = PR

Manual linking

• Issue UI: "Link" button → search/select issue → source_type = MANUAL

New table: issue_references

Visibility

• Issue view: new "References" section showing:
  • Linked commits (sha, message, author, date)
  • Linked PRs (title, status, author)
• PR view: linked issue badge in PR header

Flyway migration

• V16__add_issue_references.sql

Out of scope

• Automatic status transitions on PR merge — separate ticket, policy is complex
• Commit detail page — follow-up

Task breakdown

• post-receive hook script + install on create: 2h
• Sztabina /internal/notify/push endpoint: 3h
• Spring IssueReferenceService + V16 migration: 4h
• PR title parsing on create/update: 2h
• Issue view References section (frontend): 6h
• PR view linked issue badge (frontend): 2h
• Manual link UI: 3h
• Existing repo migration script: 1h
• Testing + regression: 1h

On 19/03/2026 21:23, rk@tigase.net wrote:

I think this will be valuable - I recall you raised this before.

Good memory, I don't remember mentioning it :)

This is my approach to automatic commit <=> issue <=> PR linking using Sztabina push webhooks. Pl let me know if I am overcomplicating:

• On every push, Sztabina fires a webhook to the backend
• Commit messages and branch names are parsed for Sztab issue keys (SZTaa00001 format)
• Matching issues are automatically linked and shown in the issue view
• PR titles are also parsed on creation/update
• Manual linking from the issue UI as a fallback

Thoughts?

Seems about right.

One problem I see is matching the issues from the commit message - over the years we used so many systems that the issue format differed a lot from one to another: from the base #<issue_number> to #<[short-]project-ID>-number to full-blown#-issue-id (e.g. #tigase/_clients/beagle-im#654 or #SZ-122 or #122 )

Sztab will probably have its own ID system so we should think how (if we want past commits association) do that.

Ps: Why not take it a step further with automatic issue status transitions driven by PR state transitions: if a PR title references an issue key and the PR is merged, the issue automatically transitions to RESOLVED. keywords — for example, a commit message containing "fixes SZTsz00121" would automatically move that issue to RESOLVED via the existing state machine. Conversely, when the PR is reopened (APPROVED => IN PROGRESS), the issue goes from R -> O. But this gets complicated as there could be more than one PR addressing an issue - Dobra, nie mieszam, bo się jeszcze zsiądzie.

Some systems do that though, to be honest, I never used that nor was convinced by it. I guess one of the reasons is/was because Tigase is quite modular and quite often you had to make changes in multiple repositories then changes from one could trigger issue state while not finally fixing something. But it could be usefull.