Canonical page: https://tellenze.com/help/gitlab

Connect GitLab to delivery work

Link repositories and work, inspect merge requests and pipelines, and troubleshoot event delivery.

Connect delivery evidence to work

The GitLab integration shows repository activity inside projects and links relevant development evidence to work items. Members view this information through projects they can access. Administrators manage the shared connection and repository links in Admin → Integrations → GitLab.

The connection supports one GitLab.com group or subgroup for the workspace. Choose your organization’s group path during setup; repository discovery and delivery reads stay within that group and its subgroups. Self-managed GitLab hosts are not supported yet.

The Integrations catalogue groups tools by purpose and supports search and availability filters. GitLab, Gmail sending and SMTP setup are available; configured publishing integrations may also appear for your workspace. See email setup for the reviewed conversation powerups. Providers marked Coming soon, including GitHub, Bitbucket, Google Drive, Notion, Slack, calendars, meetings, automation and monitoring tools, cannot be connected yet.

Authorize the workspace connection

  1. Open Admin → Integrations → GitLab and read the access requirements beside Connect your organization.
  2. Use the supplied GitLab link to create a dedicated personal token, or obtain a suitable group token. The connection accepts only the read_api scope. A personal token needs direct membership of the configured group with Reporter-or-higher access; a group token requires exactly the Reporter role.
  3. Enter GitLab.com group path (for example, your-organization or your-organization/team, without the domain). Paste the secret into GitLab access token, then choose Validate & connect.
  4. Review the connected identity, validation time, and token expiry shown on the page.

The saved token is encrypted and is not displayed again. Keep it out of work descriptions and documents. To replace it, enter a new token and choose Validate & rotate. If validation fails, the previously validated token remains active; read the reported error before assuming rotation succeeded.

Link the correct repositories

After connecting, review Repository links. Projects can be matched from their repository URLs. For a project without the correct match, select a discovered repository and choose Link or Replace. Use Unlink to remove an incorrect association.

Choose Revalidate & discover after adding a repository or changing access. Discovery lists repositories available within the configured boundary. If a project is missing, check that it is active and has the intended repository URL. If the remote repository is missing, check token access and the discovery error.

Read project and work-item activity

Open a linked project’s Delivery section to inspect its latest default-branch pipeline and merge requests. Where available, use the Open, Merged, and Closed filters, browse branches, and select a branch to inspect commits. Follow a pipeline, commit, or merge-request link to examine the full record in GitLab.

The work item’s Development section finds recent commits and merge requests that mention its exact identifier. Include the complete identifier in the commit message or merge-request text. A similar number or an unrelated repository does not establish the intended link. Results are limited to recent activity; an empty result is not a full-history audit.

Read freshness labels before using delivery status as evidence. Cached means a previous response is being shown; partial or unavailable states may affect only one source. Use the panel’s Refresh action and inspect any error messages. A successful pipeline or merged request does not by itself prove that the work’s acceptance criteria are satisfied.

Keep event automation separate from visibility

Configured GitLab webhook events can feed merge-request and pipeline triggers into workspace automations. That requires deployment-side webhook setup and an applicable enabled automation. Connecting the read-only token does not configure event delivery or create a workflow rule. Use the Automations guide to inspect trigger behavior and run results, and ask the workspace operator about webhook delivery when events are missing.

To change organizations, enter another group path and a suitable token, then choose Change organization & connect. After successful validation, the new group replaces the old connection and all repository links, including manual links; matching repositories are linked automatically. If validation fails, the previous group, token and links remain saved. Rotating a token without changing the group preserves manual links.

An administrator can use Disconnect to remove the shared GitLab connection. Consider which projects rely on its delivery visibility before confirming.