GitLab.com

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

Connecting the source

Choose GitLab.com as source provider

Select the "GitLab.com" option from the list and click the "Next" button.

Connect GitLab

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

Authorize GitLab app

Complete this process once for your user in organization.

Configure source details

Select group from the list.

Groups 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.

GitLab select repo

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

GitLab select branch

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

GitLab root file path

For an API definition, 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.

Select path to root file

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

Developer portal detected

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 other branches as previews

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.

Build PRs as previews