Mark issues fixed from GitLab

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 merge request that fixes the bug — in its title, its description or its source branch. When the merge request merges into the project'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 merge request, and whoever raised it is told to look again.

Fixed is not verified. GitLab 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.

Make an access token

qarunbook talks to GitLab with an access token you make, so it works the same on gitlab.com and on a GitLab you run yourself. Either kind will do:

• A project access token — in the project, Settings → Access tokens. Best: it reaches this one project and nothing else, and it is not tied to a person who might leave.
• A personal access token — under your avatar, Preferences → Access tokens. It acts as you, in every project you can reach.

Give it the api scope and the Maintainer role. qarunbook uses it to add a webhook to the project and, if you ask, to file issues there — both are writes, which a read_api token cannot do. Set an expiry date you will remember: when the token expires, GitLab stops listening for us until you paste a new one.

Connect an app

1. Open the app, choose Configure, then the Integrations tab, and find GitLab. You need to be an admin of the app.
2. Leave the address as https://gitlab.com, or put in the one you open your own GitLab at. It must be reachable from the internet over https.
3. Paste the token and choose Load projects. Pick the project this app is built from, choose when a fix counts (below), then Connect.

qarunbook adds a webhook to the project for merge request, issue and — if a fix waits for a deploy — deployment events, and nothing else. The token is stored encrypted and never shown again; the screen only shows its last four characters.

When a fix counts

• When its merge 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 GitLab names it, like production) includes the merged change. Testers are not asked to retest a fix they cannot reach yet. GitLab records a deployment whenever a CI/CD job with an environment runs.

Naming the code

Any of these marks QA-12 fixed when the merge request merges:

• In the title: Fix the cart total (QA-12)
• In the description: Fixes QA-12
• In the source branch: qa-12-cart-total

One merge request can name several codes, and fixes each of them.

Issues in GitLab, too

Developers who work from GitLab issues can have every bug there as well. Under New issues in the connection, choose File every new issue in GitLab: the moment a tester raises one in qarunbook, it opens in the connected project with its code in the title and a link back. Or leave it off and send issues one at a time — on an issue, an admin chooses Send to GitLab.

Either way the loop closes itself. Closing that GitLab issue marks the qarunbook issue fixed, and so does a merge request that closes it — GitLab's own Closes #45 works as well as Fixes QA-12. The tester who raised it is asked to retest, and everyone sees the same state in both places.

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 project is saved.
• Fixing in qarunbook first is fine — a later merge that names the code changes nothing.
• Disconnecting removes qarunbook's webhook from the project and stops merge requests marking issues fixed. Issues keep their links to the merge requests that fixed them. Deleting the app disconnects it too.
• On GitHub instead? Mark issues fixed from GitHub works the same way.