Actions66
- Branch Actions
- File Actions
- Group Actions
- Issue Actions
- Merge Request Actions
- Pipeline Actions
- Project Actions
- Raw API Actions
- Release Actions
- Tag Actions
Overview
This node operation performs a rebase on a GitLab merge request. Rebasing a merge request updates its source branch by applying its changes on top of the target branch, which helps keep the history clean and up to date with the latest commits from the target branch.
Typical use cases include:
- Keeping feature branches current with the main development branch before merging.
- Resolving conflicts early by rebasing instead of merging.
- Automating repository workflows where continuous integration (CI) should be optionally skipped during rebase operations.
For example, you might use this node to automatically rebase a feature branch's merge request onto the main branch whenever new commits are pushed to main, optionally skipping CI runs to save resources.
Properties
| Name | Meaning |
|---|---|
| Authentication | Choose between using saved credentials or custom fields for API authentication. |
| GitLab Server | Base URL of your GitLab instance, e.g., https://gitlab.com. Used only if "Custom" auth is selected. |
| Access Token | Personal access token with API permissions. Used only if "Custom" auth is selected. |
| Project Owner | Namespace or owner of the project. Ignored if Project ID is set. Used only if "Custom" auth is selected. |
| Project Name | Project slug or name. Ignored if Project ID is set. Used only if "Custom" auth is selected. |
| Project ID | Numeric project ID. Takes precedence over owner and name if provided. Used only if "Custom" auth is selected. |
| Skip CI | Boolean flag indicating whether to skip running CI pipelines when performing the rebase. Defaults to false. |
Output
The node outputs JSON data representing the result of the rebase operation on the merge request. This typically includes details about the merge request's updated state after rebasing.
The output structure corresponds to the GitLab API response for the rebase action on a merge request, which may contain fields such as:
- Merge request ID and IID
- Source and target branch names
- Rebase status
- Commit SHAs
- Any error messages if the rebase failed
No binary data is produced by this operation.
Dependencies
- Requires access to a GitLab instance via its REST API.
- Needs an API authentication token with sufficient permissions to perform merge request operations, including rebasing.
- If using saved credentials, the node expects them to be configured in n8n.
- If using custom authentication, the user must provide the GitLab server URL and a personal access token.
Troubleshooting
- Invalid or missing project identification: The node requires either a valid numeric project ID or both project owner and project name to identify the project. Ensure these are correctly set.
- Insufficient permissions: The access token must have API rights to manage merge requests and perform rebases. Lack of permissions will cause errors.
- Rebase conflicts: If the rebase cannot be performed due to conflicts, the API will return an error. Manual intervention may be required.
- Skipping CI flag ignored: Ensure the
Skip CIproperty is set correctly; otherwise, CI pipelines will run after the rebase. - API rate limits or connectivity issues: Network problems or GitLab API rate limiting can cause failures. Check network connectivity and token usage limits.
Common error messages:
"404 Not Found": Project or merge request not found. Verify project ID and merge request IID."401 Unauthorized": Invalid or expired access token."409 Conflict": Rebase conflict detected; manual resolution needed.