OAuth · GitLab source
Your GitLab docs on the page people read, self-hosted included
With the GitLab source you paste a file's URL - branch or tag included - into a macro, and the Confluence page and the repository cannot disagree: there is only one file, and the page is a view of it. Your documentation gets updated because it lives beside the code.
Your self-hosted GitLab works like gitlab.com
Plenty of GitLab installations run on infrastructure the vendor never sees. An administrator registers an OAuth client of their own - with client-secret JWT or private-key JWT where a stricter policy requires it - and points the connection at your instance's base and API URLs rather than gitlab.com.
Your readers need nothing
One person connects GitLab when they add the macro. Everyone else just opens the page: no account, no group membership, no access request for a project they have no business being in.
Your CI output lands on the page, not in an artefact browser
The spec, the coverage summary, the generated diagram your pipeline commits - point a macro at the file on the branch and your page shows whatever the pipeline last committed, rather than a link into a job.
One connection, twenty-nine macros
The same connection serves 29 of the 31 macros, so Markdown, AsciiDoc, Mermaid, PlantUML, OpenAPI, CSV and JSON from the repository all arrive the same way, and your team learns it once.
GitLab is one of 13 places Macro Pack reads from
One app, one licence, one connection your admin sets up - and 12 more places a page can pull content from, whether that is a page attachment, a Git repository, an S3 bucket or your database.
See every source compared