GITLAB n8n INTEGRATION: AUTOMATE GITLAB WITH N8N

This action retrieves all repositories owned by a specific user or group from GitLab, making it perfect for building dashboards, generating reports, or synchronizing repository lists across multiple systems.

Key parameters: Credential to connect with (required dropdown for authentication), Resource set to "User" for user-level data, Operation configured as "Get Repositories", and Project Owner (required text field) to specify the username or group name whose repositories you want to retrieve.

Use cases: Build an automated inventory of all repositories in your organization, create a workflow that checks for new repositories and notifies your team via Slack, or generate weekly reports of repository activity across multiple GitLab groups.

This action retrieves issues from a specific GitLab repository, giving you powerful capabilities to sync issue data with external systems, generate reports, or trigger workflows based on issue states.

Key parameters: Credential to connect with (required), Resource set to "Repository", Operation configured as "Get Issues", Project Owner and Project Name (both required text fields), Return All toggle to retrieve all issues or limit the response, Limit (numeric input, default 20) controlling how many issues to fetch, and Filters (expandable section to filter issues by state, labels, or other criteria).

Use cases: Sync open GitLab issues to a project management tool like ClickUp or Asana, create daily digest emails summarizing new issues across multiple projects, or build a custom dashboard pulling issue metrics from several repositories.

This action fetches detailed information about a specific GitLab repository, including metadata like description, visibility, default branch, and various settings.

Key parameters: Credential to connect with (required), Resource set to "Repository", Operation configured as "Get" to retrieve repository details, Project Owner and Project Name (both required text fields).

Use cases: Verify repository configuration before running deployment workflows, build automated compliance checks that validate repository settings, or create documentation workflows that pull repository metadata automatically.

This action updates an existing release in a GitLab project, allowing you to modify release notes, names, or other properties programmatically.

Key parameters: Credential to connect with (required), Resource set to "Release", Operation configured as "Update", Project Owner and Project Name (required), Project ID (optional numeric identifier), Tag Name (required text field specifying which release tag to update), and Additional Fields (expandable section for optional properties like description or name changes).

Use cases: Automatically update release notes when documentation changes, sync release information from external changelog tools, or build workflows that enrich releases with deployment status or metrics.

This action retrieves multiple releases from a GitLab project with pagination support, perfect for building release history views or synchronizing release data across systems.

Key parameters: Credential to connect with (required), Resource set to "Release", Operation configured as "Get Many", Project Owner and Project Name (required), Return All toggle to fetch all releases or use pagination, Limit (number of releases to return, default 20), and Additional Fields for optional filtering parameters.

Use cases: Generate comprehensive release history reports, build changelog aggregation workflows across multiple projects, or create automated release comparison tools.

This action retrieves detailed information about a specific release identified by its tag name, providing access to release notes, assets, and metadata.

Key parameters: Credential to connect with (required), Resource set to "Release", Operation configured as "Get", Project Owner and Project Name (required), Project ID (optional alternative identifier), and Tag Name (optional—may default to latest).

Use cases: Fetch release details to include in deployment notifications, build workflows that validate release content before promotion, or sync specific release information to documentation platforms.

This action permanently removes a release from a GitLab project. Use with caution as this operation cannot be undone.

Key parameters: Credential to connect with (required), Resource set to "Release", Operation configured as "Delete", Project Owner and Project Name (required), and Tag Name (required text field for the release tag to delete).

Use cases: Clean up test or draft releases automatically, build release management workflows with approval gates, or automate removal of deprecated releases based on age or criteria.

This action creates a new release in a GitLab project, allowing you to automate release publishing as part of your CI/CD pipeline or deployment workflows.

Key parameters: Credential to connect with (required), Resource set to "Release", Operation configured as "Create", Project Owner and Project Name (required), Tag (optional text field for the release tag), and Additional Fields for options like description, name, and release assets.

Use cases: Automatically create releases when tags are pushed via webhook workflows, build release automation that generates notes from commit history, or create cross-platform release workflows that publish to GitLab and other registries.

This action locks a GitLab issue to prevent further comments, useful for resolved discussions or issues that have become unproductive.

Key parameters: Credential to connect with (required), Resource set to "Issue", Operation configured as "Lock", Project Owner and Project Name (required), Issue Number (required numeric identifier), and Lock Reason (dropdown with options like "Resolved", "Off-topic", or "Spam").

Use cases: Automatically lock issues after they've been closed for a certain period, build moderation workflows that lock issues matching specific criteria, or create scheduled workflows that lock resolved issues weekly.

This action retrieves detailed information about a specific GitLab issue, including its description, labels, assignees, and current state.

Key parameters: Credential to connect with (required), Resource set to "Issue", Operation configured as "Get", Project Owner and Project Name (required), and Issue Number (required numeric identifier of the specific issue to fetch).

Use cases: Fetch issue details to include in notification messages, build workflows that check issue status before proceeding with actions, or sync individual issue data to external tracking systems.

This action updates an existing GitLab issue, allowing you to modify title, description, labels, assignees, due dates, and other properties programmatically.

Key parameters: Credential to connect with (required), Resource set to "Issue", Operation configured as "Edit", Project Owner and Project Name (required), Issue Number (required), and Edit Fields (selectable properties including title, description, labels, assignees, state, and more).

Use cases: Automatically update issue labels based on external triggers, build triage workflows that assign issues based on content analysis, or create SLA workflows that update due dates based on priority.

This action adds a comment to an existing GitLab issue, enabling automated responses, status updates, or cross-system notifications directly within issue threads.

Key parameters: Credential to connect with (required), Resource set to "Issue", Operation configured as "Create Comment", Project Owner and Project Name (required), Issue Number (required), and Body (required text content of the comment).

Use cases: Post automated status updates when deployments complete, add cross-reference comments linking to related tickets in other systems, or build notification workflows that comment when external events occur.

This action creates a new issue in a GitLab project, making it the foundation for many automation workflows that need to generate issues from external triggers.

Key parameters: Credential to connect with (required), Resource set to "Issue", Operation configured as "Create", Project Owner and Project Name (required), Title (optional but typically provided), Body (issue description content), Due Date (date-time picker for setting deadlines), and Labels (text field for categorizing the issue).

Use cases: Automatically create issues from customer support tickets via Zendesk integration, build monitoring workflows that create issues when alerts fire, or generate issues from form submissions or external webhook events.

This action lists files within a specific directory of a GitLab repository, useful for exploring repository contents or building file-based automation workflows.

Key parameters: Credential to connect with (required), Resource set to "File", Operation configured as "List", Project Owner and Project Name (required), Path (directory path to list, e.g., "docs/"), Return All and Limit (pagination controls), and Page (specific page number for paginated results).

Use cases: Build documentation indexes by listing all markdown files, create file monitoring workflows that track directory changes, or generate reports of repository structure and contents.

This action retrieves the contents of a specific file from a GitLab repository, supporting both text and binary files with flexible output options.

Key parameters: Credential to connect with (required), Resource set to "File", Operation configured as "Get", Project Owner and Project Name (required), File Path (required, e.g., "docs/README.md"), As Binary Property (toggle for binary file handling), and Put Output File in Field (names the output field for binary data).

Use cases: Fetch configuration files to use in deployment workflows, build backup workflows that archive critical repository files to Dropbox or AWS S3, or sync documentation files to external publishing platforms.

This action modifies an existing file in a GitLab repository, enabling automated content updates, configuration changes, or documentation maintenance.

Key parameters: Credential to connect with (required), Resource set to "File", Operation configured as "Edit", Project Owner and Project Name (required), File Path (required path to the file to edit), and Binary File (toggle indicating whether content is binary).

Use cases: Automatically update version numbers in configuration files, build workflows that modify documentation based on external data, or create scheduled updates to repository metadata files.

This action removes a file from a GitLab repository, creating a commit that records the deletion. Use with appropriate caution in production workflows.

Key parameters: Credential to connect with (required), Resource set to "File", Operation configured as "Delete", Project Owner and Project Name (required), File Path (required path to the file to delete), Commit Message (optional message for the deletion commit), and Branch (optional branch specification, defaults to main/master).

Use cases: Clean up temporary files created by automation workflows, build file lifecycle management workflows, or automate removal of deprecated configuration files.

This action creates a new file in a GitLab repository, committing it to the specified branch with the provided content and commit message.

Key parameters: Credential to connect with (required), Resource set to "File", Operation configured as "Create", Project Owner and Project Name (required), File Path (required path and filename for the new file), Binary File (toggle for binary content), File Content (required text content for the file unless binary), Commit Message (message describing the file creation), and Branch (target branch for the commit).

Use cases: Generate configuration files from templates dynamically, create documentation files from external data sources, or build workflows that scaffold new project files automatically. For complex automation needs, our n8n agency can help design custom solutions.