Mark issues fixed from GitHub

Connect an app, step by step

1. In qarunbook

   Open the app's GitHub settings

   Open the app, choose App configuration, then the Integrations tab, and choose the GitHub tile under Where developers fix it.

   Choose Connect GitHub. GitHub opens in the same tab.

2. In GitHub

   Install the qarunbook app

   GitHub asks where to install qarunbook. Pick the account or organisation that owns the code.

   Under Repository access, choose Only select repositories and pick the repository this app is built from — or every one of them, if it is built from several. Choose Install.

   The app asks 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 pick.

3. In qarunbook

   Add the repository

   GitHub sends you back to the app's Integrations tab, which says GitHub is connected. Now add the repositories this app is built from. Under Repositories, choose it from Choose a repository….

   If the list says The app can't see any repositories, choose Give it access to one and add it in GitHub.

   One repository that builds the whole app is all most teams need: leave its Builds chips unticked, which reads Every platform, and go to the next step.

4. In qarunbook

   Built from several repositories? Add each one and tick what it builds

   Choose the next one from Add another repository…, and repeat for each — the backend, the web app, the mobile app.

   On each repository, under Builds, tick the platforms it builds: WEB on the web repository, IOS and AND on the mobile one. Leave a repository unticked if it builds everything, like a backend or a monorepo. A pull request then fixes a bug only on the platforms its repository builds — see Several repos, one app.

   The first repository you add is the Default. To change it, choose Make default on another. A new bug is filed in the repository that builds its platforms; one no single repository builds, like a bug on web and iOS, goes to the default.

5. In qarunbook

   Say when a fix counts, and save

   On each repository, under A fix counts, choose When its pull request merges or When it is deployed. For a deploy, fill in Environment, as GitHub names it — like staging. Each repository has its own: a web app deployed through GitHub can wait for its deploy while a mobile app counts on merge. More on both below.

   Under New issues, choose File every new issue in GitHub or Only when someone sends it. Then choose Save.

   The card now shows each Repository — with what it builds and when a fix there counts, once there are several — and what happens to New issues. There is no webhook to add: the qarunbook app brings its own.

Check it works

1. In qarunbook

   Raise a test bug and copy its code

   On any check, write a line under Issues — Test: GitHub connection — and choose Add issue. The issue shows its code, like QA-12. Click the code to copy it.

2. In GitHub

   Merge a pull request that names it

   Open a pull request into the default branch with Fixes QA-12 in its description (or the code in its title or branch name), and merge it.

3. In qarunbook

   See it come back

   The issue now reads Fixed by [name] via GitHub · PR #[number], links to the pull request, and sits under Needs retest. Whoever raised it has been told to look again. Confirm the fix, or reopen it, as usual.

   If a fix counts when it is deployed, the issue first reads PR #[number] merged, waiting for deploy, and is marked fixed once a deployment to that environment includes the change.

4. In qarunbook

   Several repositories? Check a part fix too

   Raise a test bug on two platforms built in different repositories — say WEB and IOS — and merge a pull request naming its code in the web repository only.

   The issue stays open and reads Partly fixed · WEB fixed · PR #[number] · Still open on IOS. The check reads R on web and stays failed on iOS. Merge the iOS pull request and the issue is fixed as usual.

How it works

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. When the pull request merges into the repository's default branch, qarunbook marks the issue fixed, exactly as an admin choosing 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.

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.

When a fix counts

Each repository says this for itself:

• 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.

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.

Issues in GitHub, too

With File every new issue in GitHub, the moment anyone raises an issue on the app it opens in the repository as [QA-12] the first line of the issue, with a link back. With Only when someone sends it, an admin chooses Send to GitHub on an issue to file just that one. Either way the qarunbook issue shows a link naming the repository and the number, like GitHub · web#45.

With several repositories, an issue is filed in the one that builds its platforms — a web-only bug in the web repository — and otherwise in the default. Send to GitHub asks which repository, starting from that one.

Closing that GitHub issue as completed marks the qarunbook issue fixed, and so does a pull request that closes it — Fixes #45 works as well as Fixes QA-12. Closing it as not planned changes nothing here.

Several repos, one app

Many teams keep the backend, the web app and the mobile apps in separate repositories, while one qarunbook app tests every platform. Tell each repository which platforms it builds, and a pull request fixes a bug only where it can:

• QA-13 was raised on WEB and IOS. A pull request naming it merges in the web repository, which builds WEB. The issue stays open, fixed on web: the check reads R on web and stays failed on iOS, and the card shows which pull request fixed which platform and what is still open.
• Whoever raised it is told QA-13 is fixed on Web; still open on iOS — in the app and by email, the same way they hear of any fix — so they can retest web now.
• When the iOS pull request merges, the issue is fixed exactly as it would be from one repository: the check reads R on iOS, the reporter is told, and Slack, Teams, Jira, Linear and the rest hear of it as usual. If web was retested in between, the check keeps that result rather than asking for web again.
• A repository that builds every platform — a backend, a monorepo — fixes the whole bug, and so does any repository for a bug raised on every platform.
• A pull request in a repository that builds none of the bug's platforms changes nothing: a web fix cannot close an iOS-only bug.
• A repository that fixes on deploy holds its pull request until its own environment includes it, then fixes its own platforms.
• Mark fixed in qarunbook still fixes every platform at once, and accepting an AI suggestion fixes the platforms of the repository the pull request merged in. Reopen clears the part fixes: the bug is broken everywhere it says again.

The API and the MCP tools show the same: an issue's fixed_on lists each platform fixed and the pull request that fixed it, and still_open_on what is left. Its status stays open until the last one is fixed.

Good to know

• Merges into branches other than the default branch are ignored until they reach it.
• GitHub receives bugs, not your test plan: checks and sections stay in qarunbook, and nothing from GitHub creates them.
• Issues raised before an app was connected get their codes when the repositories are saved.
• Fixing in qarunbook first is fine — a later merge that names the code changes nothing.
• An app connected before it could have several repositories carries on exactly as it was: its repository reads as the default, building every platform. Choose Change to add more.
• To add or remove repositories, change what they build or when a fix counts, choose Change on the card. To give the app other repositories, or uninstall it, use GitHub's own settings for the installation; qarunbook forgets a repository the app can no longer see, and if that was the default, the next one takes over.
• Disconnect stops pull requests marking issues fixed. Issues keep their links to the pull requests that fixed them.
• On GitLab instead? Mark issues fixed from GitLab works the same way. Using Linear? Send issues to Linear: moving an issue to Done there marks it fixed here.