Meliora Testlab can be integrated with a Mercurial Version Control System to track links between your changesets, issues, and requirements.
A Version Control System is a repository where the developers commit and push changes to be stored and versioned during the development. The changes are bundled as sets of changes (changesets) and when committed, are stored with a commit message explaining the changes included in the changeset.
When a developer pushes changes to the repository, (s)he can include references to Testlab’s issues and requirements to the commit message. The repository then sends the information of the changeset to Testlab and the changeset information is stored to Testlab project and linked to related issues and/or requirements. When viewed through Testlab’s user interface, you can then inspect which changesets are related to these assets in your VCS repository. You can also – if properly set up – click and navigate via the changeset to dig deeper into the changes included in the changeset.
With this workflow, in the Testlab project, you can
This enables you to better collaborate with your programmers and testers and have changesets as part of your testing project for future reference.
To set up the integration the following steps are needed:
The detailed instructions for each step follow.
For the VCS system to be able to push changeset information to Testlab, an API key must be configured to your Testlab instance. To configure an API key, log into your Testlab as an administrator and go to Testlab > Manage company… > API keys and add a new key. Please, take note of your API key when you register one as the key is hash encoded to the database with no way of recovering it after saving your changes. An API key is basically a secret (password) the VCS system uses to authenticate to your Testlab.
For the integration to work, the VCS system needs to be set up with a hook script. A hook in VCS is a script that gets executed when some set operation in the repository occurs (such as push, commit, update, …). As your VCS is of distributed type and you are working as a team, you most likely are pushing your changes to a so-called central repository. For this, you should set up an “incoming” hook which gets triggered once for each changeset that is brought into the repository from elsewhere (pushed by your developers). For testing, you could also use a “commit” hook but keep in mind that then the hook gets executed once per your commit in your local repository only. You can read more about Mercurial’s hooks here.
To set up the hook script, download the pre-templated hook script hg_testlab_hook.zip. Unzip the archive (it is archived to make sure you can download the file) and you will end up with a bash-script capable of posting the results to Testlab.
At the start of the script file, edit the following values:
const REPOSITORY_ID = ''; const TESTLAB_COMPANY_ID = 'your company id'; const TESTLAB_APIKEY = 'your cryptical api key'; const TESTLAB_PROJECT = 'your Testlab project prefix'; // optional for on-premise Testlab installs: const TESTLAB_API_URL = '...'; //const __DEBUG_FILE = '/tmp/testlab_hg_hook_debug.log';
The script uses Node.js runtime for the call that is made to Testlab. For this, you should install Node.js runtime and needed Node.js components.
# npm install -g node-rest-client
Note: If you have problems with Node runtime not finding your (globally) installed modules by giving an error “Cannot find module: node-rest-client” or similar, you should make sure your NODE_PATH environment variable points to a correct directory. Node uses this directory to find installed modules.
[hooks] incoming = node .hg/hg_testlab_hook.sh
If you wish to be able to inspect your changesets via your Testlab project, you should have (or set up if missing) some kind of web access to your repository. This means that your repository should be browseable with a browser by your users (“HTTP/HTTPS mechanism”).
Installing such component is beyond the scope of this manual, but with Mercurial, it is easy to set up with “hg serve” or “hgweb”. You can read more about your options on publishing your repositories at
If you have a web browser browsable repository, you should configure the URL address of it to your Testlab project. To do this,
The integration should now be set up. You should read on for information on how to format the commit messages to actually link and store the changeset links to your Testlab project.
When a developer pushes a changeset to the repository, it holds commit messages which describe the changes included. When the integration is enabled, the commit messages are inspected for special keywords to indicate how to link the changesets to the assets in the Testlab project. The table below lists all variations for keywords supported.
|Keyword(s), with example(s)||Description|
|refs #ISSUEID, issue #ISSUEID
Partially fixes issue #TLABDEMO-6, refs #TLABDEMO-2
|Stores the changeset and links it to an issue with ID “ISSUEID”.
The example links the changeset to two issues, TLABDEMO-6 and TLABDEMO-2.
| fixes #ISSUEID, fix #ISSUEID
Fixes #TLABDEMO-5, also fix #TLABDEMO-4
|Stores the changeset and
The example links the changeset to two issues, TLABDEMO-5 and TLABDEMO-4, and marks them as resolved.
|closes #ISSUEID, close #ISSUEID
- closes #TLABDEMO-2 - also close #TLABDEMO-3
|Stores the changeset and
The example links the changeset to two issues, TLABDEMO-2 and TLABDEMO-3, and closes these issues.
|req #REQID, requirement #REQID, impl #REQID, implements #REQID
- impl #US2.1 - also implements #US2.2 - req #US3.1 needs clarifications
|Stores the changeset and links it to a requirement with ID “REQID”.
The example links the changeset to three requirements, US2.1, US2.2 and US3.1.
To inspect linked changesets in your Testlab project,
If you have configured web addresses for your repositories, the view also has appropriate controls in place to open up the specific revisions in your web-published repository.