Content
View differences
Updated by Christophe Bliard about 16 hours ago
I set up and used the GitLab integration in a demo, and it was a bit complicated or felt outdated. I'm creating this work package to keep track of my feedback. We can later turn it into epic, bugs of features.
The GitLab integration feels like it's lagging behind the features available in GitLab and would need an update.
Here are some areas which would need an update:
* GitLab "issues" are now named "work items"
* In openproject, the GitLab tab shows a "Issues" section. In GitLab, they are now part of a larger "[work items](https://docs.gitlab.com/user/work_items/)" group. work items can include issues, incidents, tasks, OKRs, test cases, etc.
* texts should be updated to use "work item(s)" everywhere "issue(s)" is used
Here are some areas which could be improved:
* In GitLab webhook settings, secret token is not recommended. [Signing tokens](https://docs.gitlab.com/user/project/integrations/webhooks/#signing-tokens) are recommended instead.
* Yet in OpenProject "secret token" is the only option available. It does not guarantee message integrity.
* OpenProject should offer a "Signing token" option
* This is actually registered here: ##74749
* Webhook events
* In GitLab webhook events, [we recommend checking some of them in our documentation](https://www.openproject.org/docs/system-admin-guide/integrations/gitlab-integration/#:~:text=events%20that%20should%20be%20triggered%20by%20the%20webhook): Push events (all branches), Comments, Issues events, Merge request events, Pipeline events
* What about the "confidential comments"? And maybe other events?
* Untranslated comments
* the comments in the activity when a merge request or a work item is updated or a commit is added seem to be fixed and not translatable.
* Configuration of the webhook is not that easy. Here are some ideas:
* The GitLab integration settings page (`/gitlab_integration/admin/settings`) should link to the [GitLab integration documentation](https://www.openproject.org/docs/system-admin-guide/integrations/gitlab-integration).
* The webhook url should be copyable from somewhere. Opening the documentation to get that url [`https://some-op-server.example.com/webhooks/gitlab`](https://some-op-server.example.com/webhooks/gitlab) should not be needed.
* Bonus points if the api key is automatically appended to it. Maybe in ##75233 ? (In that case, it should support having 2 or more GitLab installations and thus not invalidate previously created secrets)
* The OpenProject GitLab integration page could indicate when it last received a payload, so that we can click the "Test" button from GitLab side and see something on OpenProject side.
* Creating the "GitLab integration" user, create a role with restricted permissions just for it, assigning it to some projects to give it the role so that the integration can be used in that project, logging in to have it generate an API token to be used in the webhook url. This all feels complex. I hope this will be handled in <mention class="mention" data-id="75233" data-type="work_package" data-text="##75233" data-display-id="75233">##75233</mention>.
* webhook secret is visible in settings
* It should use a hidden field that can be shown when clicking on a button, so it does not lack the secret when doing screen sharing.
The GitLab integration feels like it's lagging behind the features available in GitLab and would need an update.
Here are some areas which would need an update:
* GitLab "issues" are now named "work items"
* In openproject, the GitLab tab shows a "Issues" section. In GitLab, they are now part of a larger "[work items](https://docs.gitlab.com/user/work_items/)" group. work items can include issues, incidents, tasks, OKRs, test cases, etc.
* texts should be updated to use "work item(s)" everywhere "issue(s)" is used
Here are some areas which could be improved:
* In GitLab webhook settings, secret token is not recommended. [Signing tokens](https://docs.gitlab.com/user/project/integrations/webhooks/#signing-tokens) are recommended instead.
* Yet in OpenProject "secret token" is the only option available. It does not guarantee message integrity.
* OpenProject should offer a "Signing token" option
* This is actually registered here: ##74749
* Webhook events
* In GitLab webhook events, [we recommend checking some of them in our documentation](https://www.openproject.org/docs/system-admin-guide/integrations/gitlab-integration/#:~:text=events%20that%20should%20be%20triggered%20by%20the%20webhook): Push events (all branches), Comments, Issues events, Merge request events, Pipeline events
* What about the "confidential comments"? And maybe other events?
* Untranslated comments
* the comments in the activity when a merge request or a work item is updated or a commit is added seem to be fixed and not translatable.
* Configuration of the webhook is not that easy. Here are some ideas:
* The GitLab integration settings page (`/gitlab_integration/admin/settings`) should link to the [GitLab integration documentation](https://www.openproject.org/docs/system-admin-guide/integrations/gitlab-integration).
* The webhook url should be copyable from somewhere. Opening the documentation to get that url [`https://some-op-server.example.com/webhooks/gitlab`](https://some-op-server.example.com/webhooks/gitlab) should not be needed.
* Bonus points if the api key is automatically appended to it. Maybe in ##75233 ? (In that case, it should support having 2 or more GitLab installations and thus not invalidate previously created secrets)
* The OpenProject GitLab integration page could indicate when it last received a payload, so that we can click the "Test" button from GitLab side and see something on OpenProject side.
* Creating the "GitLab integration" user, create a role with restricted permissions just for it, assigning it to some projects to give it the role so that the integration can be used in that project, logging in to have it generate an API token to be used in the webhook url. This all feels complex. I hope this will be handled in <mention class="mention" data-id="75233" data-type="work_package" data-text="##75233" data-display-id="75233">##75233</mention>.
* webhook secret is visible in settings
* It should use a hidden field that can be shown when clicking on a button, so it does not lack the secret when doing screen sharing.