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.
Sign in to GitLab.com and authorize the Redocly Workflows application.
Complete this process once for your user in organization.
Configure source details
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.
When you select the repository, the list of branches available will be populated.
Provide the path to your root file, e.g. swagger.yaml
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.
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.
