GitLab for Confluence

Technical Documentation with GitLab Merge Request Context

A development team uses GitLab for source control and Confluence for documentation. When writing design documents and runbooks, they reference GitLab merge requests, issues, and code files to provide context for their decisions and procedures.

The challenge: Documentation includes plain GitLab URLs that give readers no context. To understand what a merge request is about, the reader must click through to GitLab, wait for it to load, and then navigate back. For a runbook with 10 GitLab references, this constant switching makes the document frustrating to read.

How GitLab for Confluence helps:

• Rich merge request previews: Paste a GitLab MR URL into Confluence and it renders as a card showing the title, status, assignee, and pipeline results. Readers understand the context without leaving the page.
• Issue cards: GitLab issue links render with the title, labels, milestone, and current status. Documentation stays informative even months after the issues are closed.
• Code file embeds: Link to specific files in a GitLab repository and see the source code rendered with syntax highlighting directly in Confluence.

The result: Documentation is more useful because every GitLab reference carries its context inline. Readers spend less time switching between tools and more time understanding the content.

Sprint Retrospective Pages with Pipeline Data

A Scrum team runs retrospectives in Confluence and wants to include data about their development process - pipeline success rates, merge request turnaround time, and deployment frequency. This data lives in GitLab.

The challenge: The Scrum Master manually looks up pipeline statistics in GitLab and types them into the Confluence retrospective page. The numbers are only accurate at the moment they are captured, and creating the report takes 20 minutes before each retro meeting.

How GitLab for Confluence helps:

• Pipeline status embeds: Embed links to GitLab pipeline runs on the retrospective page. The team sees which pipelines succeeded, failed, or are pending for the sprint.
• MR activity tracking: Link to key merge requests from the sprint. The cards show review duration, number of discussions, and whether the MR was merged or abandoned.
• Deployment references: Link to GitLab deployments to show what was shipped during the sprint, with the environment and status visible directly in Confluence.

The result: Retrospective preparation drops from 20 minutes to 5 minutes. The team discusses data-driven improvements because the sprint's GitLab activity is visible directly on the Confluence page.

Onboarding Guides with Repository Access

New developers join a team and follow an onboarding guide in Confluence. The guide references GitLab repositories they need to clone, pipelines they need to understand, and issues they can work on as starter tasks.

The challenge: The onboarding guide contains URLs to GitLab resources, but new developers do not know what each URL leads to until they click through. Repository names change, pipelines are reorganized, and starter issues get completed. The guide becomes outdated without constant manual maintenance.

How GitLab for Confluence helps:

• Repository cards: Each GitLab repository link renders with a description, primary language, and last activity date. New developers see what each repo is for before navigating to it.
• Live issue lists: Link to GitLab issues tagged as "good first issue." The cards show which issues are still open and available for the new developer to claim.
• Pipeline status context: New developers see whether the team's main pipelines are healthy before running their first build, reducing confusion when a build fails due to a pre-existing issue.

The result: New developers orient faster because the onboarding guide shows live GitLab context. The guide requires less maintenance because GitLab cards update automatically when repository details change.