Feature
Connect GitLab to your Zuuna board (self-hosted included)
GitLab.com or your own instance behind the firewall: an address, a project path and a token that is never stored. How the connection works.
The GitLab integration links a project to a group in Zuuna — on GitLab.com just as on a self-hosted instance. You give the address of your instance, the project path and a personal access token; Zuuna uses it to set up the webhook.
Setting it up
On the group's Code page you need three things: the address of your instance (gitlab.com or your own), the project path in the form namespace/project — subgroups are fine — and a personal access token. Zuuna registers the webhook with it and then discards it. It is not stored.
When the instance is not reachable from outside
That is the normal case behind a corporate firewall, and it is accounted for. If Zuuna cannot register the webhook itself, it shows you the URL and the secret and you add the hook in GitLab by hand. The connection is then made from your side — Zuuna never has to reach your instance.
After that
Commits, branches, merge requests and pipeline status appear on the card whose ID is in the commit or the branch. Do not confuse this with signing in through GitLab: that is a separate feature and has nothing to do with the board.
Plan
Git on the board is part of the Developer plan, together with releases, the code graph, the REST API and webhooks.
FAQ
Is my access token stored?
No. It is used once to set up the webhook and then discarded. What is kept is the mapping from project to group and the webhook secret, which is stored encrypted.
What scope does the token need?
Enough to create a webhook on the project. If it is not enough, only the automatic setup fails — you are then given the URL and secret to add by hand and can still connect.
Do subgroups work?
Yes. The project path may have several levels, so group/subgroup/project is fine.