The shape of it
Every issue in qarunbook has a short code, like QA-12, shown on the issue with a button to copy it. A developer puts that code in the pull request that fixes the bug — in its title, its description or its branch name. When the pull request merges into the repository's default branch, qarunbook marks the issue fixed, exactly as an admin clicking Mark fixed would: the check reads retest on the platforms it affects, the issue links to the pull request, and whoever raised it is told to look again.
Fixed is not verified. GitHub can say the code changed; only a person can say the bug is gone. The issue waits for a retest exactly as it does after any other fix.
Connect an app
- Open the app, choose Configure, then the Integrations tab, and find GitHub. You need to be an admin of the app.
- Choose Connect GitHub. GitHub asks where to install the qarunbook app: pick the account or organisation that owns the code, then Only select repositories and the repository this app is built from.
- Back in qarunbook, pick the repository and choose when a fix counts (below), then Save.
The app asks GitHub for the least it needs: to read code, pull requests and deployments, and to write issues for Send to GitHub. It sees only the repositories you choose, and you can change them, or uninstall it, from GitHub at any time.
When a fix counts
- When its pull request merges — into the default branch. Best when every merge goes out straight away.
- When it is deployed — once a deployment to the environment you name (as GitHub names it, like
staging) includes the merged change. Testers are not asked to retest a fix they cannot reach yet. Hosts such as Vercel and Netlify report deployments to GitHub for you.
Naming the code
Any of these marks QA-12 fixed when the pull request merges:
- In the title:
Fix the cart total (QA-12) - In the description:
Fixes QA-12 - In the branch name:
qa-12-cart-total
One pull request can name several codes, and fixes each of them.
If the code is forgotten
A merged pull request that names no code is read by AI against the app's open issues — its title, description, branch and changed files. When one is clearly the same problem, the issue shows it: PR #88 was merged and probably fixes this, with the reason. An admin chooses Mark fixed or Not it. Nothing is marked fixed on a guess.
Send an issue to GitHub
Developers who work from GitHub issues can have them there too. On an issue, an admin chooses Send to GitHub: it is filed in the connected repository with its code in the title and a link back. Closing that GitHub issue as completed marks the qarunbook issue fixed — and so does a pull request that closes it.
Every event from GitHub is checked against the app's signing secret before anything is believed. A redelivered event fixes an issue once and tells the reporter once, and nothing from GitHub ever reopens an issue.
Good to know
- Merges into branches other than the default branch are ignored until they reach it.
- Issues raised before an app was connected get their codes when the repository is saved.
- Fixing in qarunbook first is fine — a later merge that names the code changes nothing.
- Disconnecting stops pull requests marking issues fixed. Issues keep their links to the pull requests that fixed them.
- Using Linear instead? Send issues to Linear works the same way: moving an issue to Done there marks it fixed here.