1. Track commits as comments in a corresponding Kanban card. (Only commit and push events are tracked.)
2. Track GitLab project issues as cards in a Kanbanize board
The integration is in one direction only – from GitLab to Kanbanize.
For example, when an issue is closed, the corresponding Kanbanize card is moved to Done but moving a card to Done in Kanbanize will not get the issue closed in GitLab.
1. In Kanbanize, go to administration-> integrations and enable Gitlab integration
2. Go to your GitLab project page -> Settings.
3. Click on Integrations.
4. Set up a Webhook:
URL – https://mycompany.kanbanize.com/index.php/api/kanbanize/git_lab_event
Secret Token – The API key of any of your Kanbanize users.
We recommend using a dedicated Administrator user or a standard user (e.g. GitLab_user) with permissions to access, comment and modify cards on the desired boards.
Push events – If enabled, all branches and all commits of the project are inspected for Kanbanize card IDs.
Comments and Issues events – If enabled, GitLab project issues will be tracked in a Kanbanize board.
An additional URL parameter is required – issuesboardid – The ID of the board that must keep the project issue cards.
Optional URL parameters:
lastcommit – If set to true, only the last commit of each push will be inspected for task IDs. Defaults to false.
And you are good to go! From now on, every commit message will be processed in Kanbanize and your changes will be reflected on the corresponding Kanban card. When a local branch is pushed to a repository all local commits will also be processed one by one.
Kanbanize supports the following commands in the GitLab commit message:
#taskid / #id – this is a required parameter for the integration to work. You can provide it in one of these three formats:
- #id 1234 (can be anywhere in the commit message and takes priority if present)
- #taskid 1234 (can be anywhere in the commit message and takes priority if present)
- 1234 (must always be the first thing in your commit message)
Change in the logging module. #id 1234
Change in the logging module. #taskid 1234
1234 Change in the logging module.
GitLab allows Automatic issue closing
If issue tracking is enabled and your commit message is related to a GitLab issue, you don’t have to provide a task id parameter.
#title, #description, #priority, #assignee (with alias @<username>), #color, #size, #tags, #deadline, #extlink, #type
All these parameters can be changed via the commit message using our API functions.
Change in the logging module. #taskid 1234 #priority high #color ffaaff #deadline 2014-12-12 @Peter
1234 Change in the logging module. @Peter
You can also move a task via the commit message. The supported parameters are:
#column – The name of the column you want to move the task into.
#lane – The name of the lane you want to move the task into.
#boardid – If you want to move a task to another board, specify the board id.
#position – The position to which you want to move the task.
#exceedingreason – If you are to exceed the WIP limit, provide a reason with this parameter.
1234 #column Done
1234 #column Done #lane bugs #boardid 12 #position 1
Example 3: If the column is a sub-column, you must specify it as “columnname1.columnname2.columnname3”:
1234 #column “Done.Ready for Deployment” #lane bugs #boardid 12 #position 1
We also support a bunch of move shortcuts that make it all easier
#move “Ready for testing/Platform Team” – Move the task to the “Ready for testing” column and the “Platform Team” swimlane
#move Development/ – Move the task to the Development column
#move “/Platform Team” – Move the task to the Platform Team swimlane
#requested – Move a task to the first column in the Requested section
#inprogress – Move a task to the first column in the In Progress section
#done – Move a task to the first column in the Done section
#<section> first – Move a task to the first column in the section
#<section> 2 – Move a task to the second column in the section
#<section> last – Move a task to the last column in the section
<section> can be any of the following: requested, progress, done
To log time via the commit message use the following parameter:
#loggedtime – The number of hours you want to log to the task.
1234 #loggedtime 2
You could also block or unblock a task via the commit message. The supported commands are:
#block – the reason for which you block the task
#editblock – specify this parameter if the task is currently blocked and you want to change the block reason
#unblock – unblock the task
1234 #block “Not enough resources.”