GitLab.com

Use GitLab.com as a source for your API definitions and developer portal projects.

Connect GitLab.com to Redocly

Select GitLab.com as source provider

Select the "GitLab.com" option from the list and select "Next".

Authorize Redocly

Sign in to GitLab.com and authorize the Redocly Workflows application.

Configure source details

You've connected GitLab to Redocly.

Select group

Select group from the list.

Repositories are grouped by the top-level group name or user profile name. In the list of GitLab groups you'll see:

• Name of the top-level group of your organization (in case you have developer access to at least one repository in the group or subgroup of this organization).
• The group with the name of any other GitLab user (in case you have developer access to at least one repository of this user)
• The group with your profile full name (this group holds all your own repositories if they are not in any group).

When you select the group, the list of repositories (projects in GitLab) will be populated with those available to you.

Select project repo

Select your project repository. Be sure that you have at least Maintainer (access_level=40) rights to the project. Maintainer level is required for the GitLab webhooks access.

Select branch

When you select the repository, the list of branches available will be populated.

Provide the path to your root file, e.g. swagger.yaml

If you are using a .redocly.yaml file, there will be options of to select your root file based on the apiDefinitions configuration within the file.

For a developer portal, it will detect it automatically and provide you with appropriate feedback.

Build other branches as previews

When you select to build other branches as previews, it will trigger a build when a new branch is pushed or a new commit is pushed to an existing non-default branch. If a commit is pushed to your default branch, it will trigger a production build.

If your API version has other usages, it will trigger subsequent cascading preview builds of other APIs, reference docs, and developer portals.

Build PRs as previews

When you select to build PRs as previews, it will trigger a build when:

• a new merge request (MR) is opened to your default branch (which you use for production build)
• a new commit is pushed to any open MR

If your API version has other usages, it will trigger subsequent cascading preview builds of other APIs, reference docs, and developer portals.