Tuleap 12.5 February 2021

Integration with GitLab Merge Requests

Following last month introduction to the first stage of the Gitlab integration, we’re thrilled to announce Tuleap 12.5 comes with management of Merge Requests and bi-directional links.

You’ve made a bunch of commits (not too much, of course 🙄) and you are ready to face your peers in the gentle art of glorified code review. Not only will you please the Software Engineering gods; but you can now please the Process gods too by referencing your Task, User Story and Requirement in your Merge Request. By adding a reference like TULEAP-1234 you ensure the full traceability between the requirement and the code artifact (merge request). And no kittens get sacrificed.

Tuleap bot in GitLab

Even better, you will have the full traceability from GitLab back to Tuleap thanks to a bot 🤖. The bot will add a comment to reference the Tuleap artifact in the Merge Request discussion thread.

GitLab has two types of token, either personal access token or a project access token. Personal access token is always available. Project access token depends on your setup (OnPrem or Cloud) and your support plan. When possible, project token should be preferred because all actions will be done on the behalf of the project. Otherwise it will be done on the behalf of the individual who created the integration. That might be cumbersome.

More flexible artifact parent / child in trackers

Sometimes, doing import from another tool is an opportunity to improve yourself. And that’s what is happening with the « on going » work to import Jira projects. Long story short, we saw the opportunity to free all constraints on what can be a child for an artifact.

What was the Tracker Hierarchy ?

Until now, parent/child relationship between artifacts was driven by the « Tracker Hierarchy ». For instance you defined that « User Story » tracker is parent of « Task ». And then, auto-magically, all tasks linked to stories were children. It was possible for a parent to have several children. User Story parent of Task and Bug. But one child could only have one parent. For instance, it was not possible to break down a Bug in Tasks.

This limitation is gone 🥳

A world without Hierarchy

With Tuleap 12.5, any artifact can be a child of any other (except itself of course), without having to modify the Tracker Hierarchy. That’s great, but chances are that you won’t notice it in day to day.

Why? Because the Scrum Agile Dashboard & the Triggers still rely on the Tracker Hierarchy for its configuration. That means:

• The children that you can create on a backlog item (e.g. a User Story) is still driven by the hierarchy
• Planning configuration (release planning, sprint planning, etc) is also driven by the hierarchy

So, as long as you are using the Agile Dashboard (Planning, Cardwall, Taskboard) this doesn’t change a thing for you.

For those who play the artifact game

However, if you start playing with artifact & links themselves you can do anything you want. The most important thing to have in mind is that there is no longer a parent/child automatic linking.

For instance, before Tuleap 12.5, with User Stories parent of Tasks: you could go in a Task artifact in tracker service and add a link to a User Story. Under the hood, Tuleap was actually turning the link inside out. So the User Story (not the Task) was updated to link toward the Task as a child.

This behavior is no longer running on Tuleap. From now on, the rule of thumb is:

• whenever you want to add an artifact as a child of another one, you must update the Parent
• and the link must be of type « Child »