Resources · Make integration

GitLab Make integrationAutomate GitLab with Make.

Every merge request, pipeline and issue can start work outside GitLab. The GitLab Make integration brings 105 modules, 10 of them triggers. It fits anyone who runs a repository and wants tickets, releases and alerts handled without code. You leave with an automation that runs on its own.

Try the GitLab integration on MakeSee the 105 modules

Verified Trustpilot reviews · AI, automation & growth agency

What you can automate

What does the GitLab Make integration actually do?

It links your GitLab account to Make, the no-code automation tool, so events in your repositories can drive actions elsewhere. You build a scenario, which is the automation itself: a chain of modules, each module being one brick that watches, acts or searches. One connection, meaning your GitLab account linked to Make once, is reused by every GitLab module you add.

Three shapes come back again and again. The release that documents itself: Watch Tags sees the version arrive, Create a Release attaches the notes, and the announcement leaves for wherever your team reads it. The ticket nobody retypes: Watch Issues catches a new issue and Create a Todo puts it on someone's list.

The pipeline that reports on itself: Watch Pipelines fires on a pipeline event, Get a Job picks up the job that failed, and Create an Issue Note writes the detail under the ticket. None of the three needs a line of code, and Make training exists for teams who would rather build in house.

What the 105 modules cover is wide without being infinite: projects, issues, merge requests, pipelines, jobs, branches, tags, releases, milestones, labels, variables, snippets and todos. Past that list, Make an API Call and Execute a GraphQL Query reach GitLab's API directly with the same connection. One honest warning: Make's GitLab documentation is generated from GitLab's own docs and can carry mistakes, so check anything critical with GitLab before a scenario goes live.

GitLab also exists as a node in n8n, and the choice deserves a real look. The GitLab n8n integration page covers that side, and the n8n vs Make comparison lines up the criteria.

Connect

How do you connect GitLab to Make?

  1. 01

    Add a GitLab module

    You need an active GitLab account and an access token, and that is the whole prerequisite list. Inside Make, drop any GitLab module into your scenario and click Create a connection. That button is the only place where Make asks for credentials.

  2. 02

    Name the connection

    The Connection name field is optional, and it still deserves thirty seconds. Anyone juggling a client GitLab and an internal one is glad of a clear name later, when a module asks which account it should run on.

  3. 03

    Paste your credentials

    Enter the authentication credentials you copied from GitLab, or follow the instructions on screen. For OAuth2, GitLab issues them from your avatar: Edit profile, Applications, Add new application, with the callback URI https://www.integromat.com/oauth/cb/gitlab3.

First scenario

Your first scenario: the merge request that files its own ticket

GoalWhen a merge request is opened in GitLab, Make creates the issue that tracks the review.

  1. 01

    Create the scenario

    From the Scenarios page in Make, create a new scenario and click the + to place the first module. An empty circle appears, waiting for an app. Everything starts from that circle.

  2. 02

    Pick Watch Merge Requests

    Search GitLab by name, choose Watch Merge Requests, then click Create a webhook and Create a connection. The module gets a lightning badge: instant, so GitLab calls Make the moment something happens.

  3. 03

    Point it at a project

    Fill the module fields. Once the connection exists, Make can read your account and offer the projects it finds, so you pick yours from a list instead of hunting for an identifier.

  4. 04

    Add Create an Issue

    Click the + on the right of the trigger and add Create an Issue. Carry the merge request title from the first module into the issue title: that is mapping, one module's output feeding the next.

  5. 05

    Test with Run once

    Click Run once, the button that executes the scenario a single time, then open a merge request in GitLab. Each module shows the bundles it received, a bundle being one item passing through.

  6. 06

    Schedule it and switch it on

    Open the scheduling on the first module. A scheduled trigger, one Make polls itself, runs on that clock, every 15 minutes by default. Yours is instant and waits for GitLab's call. Either way, switch the scenario on or nothing runs.

Triggers

What starts a GitLab scenario

10 modules start a scenario when something happens in GitLab. A scheduled trigger is checked by Make on the scenario's schedule; an instant one is called by GitLab as soon as it happens.

GitLab1Watch Issue Notes

Watch Issue Notes

Instant trigger

In Make“Triggers on note events.”

Notes are the comments people leave on issues, merge requests, commits and snippets. This one starts your scenario on note events, so a comment becomes something your other tools can act on.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
a public repository where a comment containing a keyword should open a task for someone on support.
Watch out
every note is an operation, meaning one module running on one item, so a chatty repository eats a plan faster than a quiet one.
GitLab2Watch Issues

Watch Issues

Instant trigger

In Make“Triggers when a new issue is created or an existing issue was updated/closed/reopened.”

One trigger covers the whole life of an issue: created, updated, closed, reopened. The issue reaches the scenario as a bundle, ready for the next module.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
a product team that wants every new bug on the sprint board without anyone copying it across.
Watch out
the four events arrive through the same door, so check which one came in before you act, or a reopened ticket gets treated as brand new.
GitLab3Watch Jobs

Watch Jobs

Instant trigger

In Make“Triggers on status change of a job.”

A job is one unit of work inside a pipeline, and this trigger follows its status changes. Your scenario learns the moment a build starts, passes or falls over.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
an agency that wants a failed build announced where the developers actually look, not in an inbox nobody opens.
Watch out
status changes come one after another, so the same job can wake the scenario several times as it moves along.
GitLab4Watch Merge Requests

Watch Merge Requests

Instant trigger

In Make“Triggers when a new merge request is created, an existing merge request was updated/merged/closed or a commit is added in the source branch.”

Everything that happens to a merge request lands here: created, updated, merged, closed, and a commit added on the source branch. One trigger, the whole review cycle.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
a tech lead who wants the review board current without reading notifications all day.
Watch out
a commit pushed to the source branch counts as well, so an active branch fires this one often.
GitLab5Watch Pipelines

Watch Pipelines

Instant trigger

In Make“Triggers on pipeline events.”

Pipeline events, the runs that build and ship a project, wake the scenario. The bundle carries the pipeline, so the next module can read what happened.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
whoever owns releases and wants the deployment log written each time a pipeline moves.
Watch out
you get the pipeline, not the detail of each job inside it, which is a separate module away.
GitLab6Watch Projects

Watch Projects

Scheduled trigger

In Make“Triggers when a new project is added of which the authenticated user is a member.”

The module looks out for a new project where the account behind your connection is a member. Handy for keeping an honest inventory of what the team works on.

How it fires
scheduled, Make checks GitLab on the scenario's schedule.
When to use it
an IT manager who wants every new project to arrive with the same labels and the same milestone.
Watch out
membership drives it, so a project created without your account on it stays invisible to the scenario.
GitLab7Watch Push Events

Watch Push Events

Instant trigger

In Make“Triggers on push events.”

Every push to the repository reaches Make. Commits arrive as they land, which makes this the rawest of the GitLab triggers.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
a documentation site that should rebuild whenever someone pushes to the main branch.
Watch out
pushes are the busiest event in most repositories, so this is the fastest way to burn operations when the scenario does heavy work afterwards.
GitLab8Watch Tags

Watch Tags

Instant trigger

In Make“Triggers on tag push events.”

A tag pushed to the repository sets this trigger off. A tag usually marks a version, so the scenario knows a release exists before anyone announces it.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
shipping a version and wanting the changelog, the announcement and the ticket cleanup to follow on their own.
Watch out
it sees the tag, not what changed inside it, so pair it with a module that reads commits when you need the detail.
GitLab9Watch Todos

Watch Todos

Scheduled trigger

In Make“Triggers when a new todo is added. When no filter is applied, the trigger is run when a new pending todo is added.”

Todos are GitLab's own reminder list, and a new one starts the scenario. With no filter applied, it runs on every new pending todo for the account.

How it fires
scheduled, Make checks GitLab on the scenario's schedule.
When to use it
someone who wants review requests mirrored into a personal task manager instead of living in two places.
Watch out
todos belong to the account behind the connection, so the scenario sees your list, never the team's.
GitLab10Watch Wiki Pages

Watch Wiki Pages

Instant trigger

In Make“Triggers when a wiki page is created or edited.”

Wiki pages count too: creating one and editing one both fire this trigger. The wiki holds the knowledge that never fits in a README, and changes to it stop being invisible.

How it fires
instant, GitLab calls Make through a webhook as soon as it happens.
When to use it
a support team that wants the help centre updated when the internal wiki moves.
Watch out
creation and edit arrive through the same trigger, so a page corrected twice sends two bundles.
Modules

What GitLab can do inside a scenario

GitLab gives you 95 modules. For each one: what it does for you, when to reach for it, and what to watch out for.

GitLab1

Accept a Merge Request

Action

In Make“Merges changes submitted with merge request.”

Merges the changes carried by a merge request, the same click a reviewer would make, done by the scenario instead.

When to use it
a release flow where the merge goes ahead once the checks have passed and the approvals are in.
Watch out
a merge changes the branch for everyone, so put this at the end of a scenario you have already tested with Run once.
GitLab2

Cancel a Job

Action

In Make“Cancels a single build of a project.”

Stops a single build of a project before it reaches the end.

When to use it
a fix pushed straight after, which makes the build started two commits earlier pointless.
Watch out
the job keeps its cancelled state in GitLab, so the history shows exactly what the scenario decided.
GitLab3

Cancel a Pipeline's Jobs

Action

In Make“Cancels a pipeline's builds.”

One call, and every build in the pipeline stops. Broader than cancelling a single job, and quicker than clicking through them.

When to use it
a branch abandoned mid-run, where nothing left in the pipeline is worth finishing.
Watch out
this hits the whole pipeline, so a scenario pointed at the wrong project identifier costs another team a run.
GitLab4

Cancel Merge When Pipeline Succeeds

Action

In Make“Cancels a merge request when the pipeline succeeds.”

Calls off the merge GitLab was going to perform once the pipeline turns green. The merge request stays in human hands.

When to use it
a reviewer spots something after approving, and the pipeline is about to merge anyway.
Watch out
the scenario has to get there before the pipeline finishes, otherwise the merge has already happened.
GitLab5

Cherry Pick a Commit

Action

In Make“Cherry picks a commit to a given branch.”

Copies one commit onto another branch without dragging the history behind it.

When to use it
a hotfix validated on the main branch that has to reach the maintenance branch as well.
Watch out
the commit lands as a new commit on the target branch, so the two branches end up holding the same change twice.
GitLab6

Create a File in a Repository

Action

In Make“Creates a file in a repository.”

Writes a new file into the repository, commit included. Your scenario produces content instead of only reading it.

When to use it
a report built elsewhere that belongs next to the code, or a config file created for every new project.
Watch out
the file arrives as a commit like any other, so it travels through your pipelines.
GitLab7

Create a Group

Action

In Make“Creates a group.”

Sets up a new GitLab group, the container that holds projects and the people allowed on them.

When to use it
an agency that opens a group per client and would rather not repeat the setup by hand every time.
Watch out
the module makes the group and nothing else, so members, labels and the first project still need later modules.
GitLab8

Create a Label

Action

In Make“Creates a new label for the given repository with the given name and color.”

Adds a label to the repository with the name and the colour you give it. Labels are how GitLab sorts issues and merge requests.

When to use it
standardising the same set of labels across every project a team opens.
Watch out
the colour is part of the call, so decide your palette once and reuse it everywhere.
GitLab9

Create a Merge Request

Action

In Make“Creates a new merge request.”

Opens a merge request from the scenario, source branch and target branch included.

When to use it
a translation branch pushed by a tool, where the merge request should exist before anyone notices the branch.
Watch out
the review stays human, and automating the opening does not automate the approval.
GitLab10

Create a Merge Request Note

Action

In Make“Creates a new note for a single merge request.”

Posts a comment on a merge request. The simplest way for a scenario to speak where the discussion already lives.

When to use it
a checklist published automatically when the merge request touches the billing code.
Watch out
a comment notifies everyone watching, so keep what the scenario says short and rare.
GitLab11

Create a Milestone

Action

In Make“Creates a project milestone.”

Builds a project milestone, the bucket GitLab uses to group issues around a date or a version.

When to use it
a new sprint that should exist in every repository the team touches, without opening each one.
Watch out
a milestone lives inside one project, so a scenario covering several repositories needs one call per project.
GitLab12

Create an Issue

Action

In Make“Creates a new project issue.”

Files a ticket in the project you choose, with the title and the description your scenario built. Plenty of first scenarios end right here.

When to use it
a form answer or an alert that has to become a tracked ticket rather than a note in someone's head.
Watch out
nothing checks for duplicates, so a trigger that fires twice files two tickets.
GitLab13

Create an Issue Note

Action

In Make“Creates a new note to a single project issue.”

Drops a comment under an existing issue. The thread stays in one place and gains what the scenario found.

When to use it
a deployment finished, and the ticket that asked for it should say so without anyone typing.
Watch out
the issue identifier is required, so a module that reads or creates the issue comes earlier in the flow.
GitLab14

Create a Pipeline

Action

In Make“Creates a new pipeline for a given project.”

Launches a pipeline on a project, the same run you would start from the CI page.

When to use it
content published in a headless CMS that should rebuild the site on its own.
Watch out
the pipeline runs as if a person had launched it, so a scenario starting one on every push stacks runs on top of each other.
GitLab15

Create a Release

Action

In Make“Adds release notes to the existing git tag.”

Attaches release notes to a git tag that already exists. The tag becomes a page people can read instead of a name in a list.

When to use it
the moment a version gets tagged and the changelog is ready to go out.
Watch out
the tag has to exist first, so the tag module or a real push comes before this one.
GitLab16

Create a Repository Branch

Action

In Make“Creates a single project repository branch.”

Cuts a new branch in the project from the reference you give it.

When to use it
a ticket accepted for development, where the branch should already be waiting under the right name.
Watch out
branch names are how a team finds its way around, so build the name from the ticket data rather than from a counter.
GitLab17

Create a Snippet Note

Action

In Make“Creates a new note for a single snippet.”

Comments on a snippet, the standalone piece of code GitLab stores outside a repository.

When to use it
a shared query that everyone keeps editing, where the scenario records who changed what.
Watch out
snippets drop out of sight quickly, so a note posted there reaches fewer people than a note on an issue.
GitLab18

Create a Tag

Action

In Make“Creates a new tag in the repository that points to the supplied ref.”

Places a tag on the reference you supply, which is how a version gets its name.

When to use it
a release scenario that tags the commit once the pipeline has gone green.
Watch out
a tag is a public marker in the repository, so a typo stays visible until somebody deletes it.
GitLab19

Create a Todo

Action

In Make“Manually creates a todo for the current user on an issue.”

Puts an issue on the todo list of the account behind your connection. GitLab's own reminder, created by the scenario.

When to use it
a ticket matching a keyword that should not wait for the next backlog review.
Watch out
the todo lands on your account only, so treat it as a personal reminder, not a way to assign work.
GitLab20

Create a Todo on Merge Request

Action

In Make“Manually creates a todo for the current user on a merge request.”

Same reminder, aimed at a merge request instead of an issue. The review shows up in your GitLab todos.

When to use it
a merge request touching a sensitive folder that should never slip past you.
Watch out
it reminds, it does not assign, so the merge request still needs a reviewer named in GitLab.
GitLab21

Create a Variable

Action

In Make“Creates a build variable.”

Adds a build variable to the project, the value pipelines read while they run.

When to use it
a new project that needs the same keys as the others before its first pipeline starts.
Watch out
variables often hold secrets, so think about who can open the Make scenario that writes them.
GitLab22

Delete a File in a Repository

Action

In Make“Deletes an existing file in a repository.”

Removes an existing file from the repository, and like the creation module it goes through a commit.

When to use it
a generated file that should disappear once its source is retired.
Watch out
there is no draft and no undo module, so test with Run once on a branch nobody depends on.
GitLab23

Delete a Label

Action

In Make“Deletes a project label.”

Takes a label out of the project for good.

When to use it
a naming convention that changed, where the old labels should stop showing up in the list.
Watch out
the label goes for the whole project, so agree on the convention before automating the cleanup.
GitLab24

Delete a Merge Request

Action

In Make“Only for admins and project owners. Soft deletes the merge request.”

A merge request can be soft deleted here, and only admins and project owners are allowed to do it.

When to use it
merge requests opened by a bot that filled the list with noise.
Watch out
the permission is checked on the account behind your connection, so a scenario built on a regular account simply fails at this step.
GitLab25

Delete a Milestone

Action

In Make“Deletes a project milestone.”

Clears a project milestone once its sprint or its version is behind you.

When to use it
a housekeeping scenario that removes the milestones a team stopped using.
Watch out
the grouping leaves with the milestone, so decide what happens to the issues it held before the scenario runs.
GitLab26

Delete an Issue

Action

In Make“Deletes an issue.”

Erases an issue instead of closing it. Closing hides a ticket, deleting removes it.

When to use it
spam opened on a public repository, where closing is not enough.
Watch out
no module brings it back, so a deletion driven by a trigger deserves a human check first.
GitLab27

Delete a Repository Branch

Action

In Make“Deletes a single project repository branch.”

Drops a single branch from the project.

When to use it
the branch cleanup that follows a merge, so the list stays readable.
Watch out
point it at the branch the merge request used, never at a name the scenario guessed, or you delete work that was still open.
GitLab28

Delete a Tag

Action

In Make“Deletes a tag.”

Pulls a tag back out of the repository.

When to use it
a version tagged by mistake, before anyone builds anything on top of it.
Watch out
tags and releases are linked, so look at what depends on the tag before the scenario removes it.
GitLab29

Delete a Variable

Action

In Make“Removes a project's build variable.”

Retires a build variable from the project settings.

When to use it
a service you stopped using, whose key has no reason to sit there any longer.
Watch out
a pipeline expecting that variable fails on its next run, so retire the pipeline step at the same time.
GitLab30

Erase a Job

Action

In Make“Erases a single build of a project (remove build artifacts and a build trace).”

Erasing a job removes its artifacts and its trace. The record of the run goes, the storage comes back.

When to use it
a job that logged something it should never have logged.
Watch out
the trace is what you read to understand a failure, so erase after the investigation, not before.
GitLab31

Execute a GraphQL Query

Action

In Make“Performs an arbitrary authorized GraphQL query.”

Runs an authorized GraphQL query against GitLab with the connection already in place. The escape hatch for data the other modules do not expose.

When to use it
a report that needs fields from several objects in a single request.
Watch out
you write the query yourself, so this is the one module on the page that expects someone comfortable with GitLab's API.
GitLab32

Get a Commit

Action

In Make“Returns a specific commit identified by the commit hash or name of a branch or tag.”

One commit comes back, found from a hash, a branch name or a tag name.

When to use it
a tag push, when the scenario has to show what actually sits behind the version before anyone announces it.
Watch out
it hands over the commit, not the files it changed. That is another module.
GitLab33

Get a Deployment

Action

In Make“Returns a specific deployment of a project.”

Fetches one deployment of a project, so the scenario knows what went out and where it went.

When to use it
an incident timeline that has to line deployments up against the moment things broke.
Watch out
the deployment identifier is needed, so something earlier in the flow has to supply it.
GitLab34

Get a File from Repository

Action

In Make“Allows you to receive information about a file in the repository like name, size, content.”

Reads a file in the repository and reports on it, name, size and content included.

When to use it
a version file or a manifest the rest of the scenario has to read before deciding anything.
Watch out
this is the descriptive version, and the raw file module suits you better when only the content matters.
GitLab35

Get a Job

Action

In Make“Retrieves a single build of a project.”

Retrieves one build of a project with its status and its details.

When to use it
a pipeline trigger saying something happened, when you still need to know which job and how it ended.
Watch out
one job is one part of a pipeline, so a busy run means many calls, and each call is an operation.
GitLab36

Get a Label

Action

In Make“Returns details about a label.”

Answers with the details of a single label. A small module, useful when a scenario has to decide from a label rather than guess.

When to use it
a routing step where the label on the ticket names the team to warn.
Watch out
labels are named by people, so a rename upstream quietly breaks the scenario looking for the old one.
GitLab37

Get a Merge Request

Action

In Make“Shows information about a single merge request.”

Shows one merge request in full: title, state, branches and the rest.

When to use it
a note event that gives you a comment, when the scenario needs the merge request around it before reacting.
Watch out
identifiers belong to a project, so carry the project through your mapping and not just the number.
GitLab38

Get a Merge Request Note

Action

In Make“Returns a single note for a given merge request.”

Pulls back a single comment on a merge request, by its identifier.

When to use it
a scenario that kept the note it posted and wants to read it again before changing it.
Watch out
one note at a time, so reach for the listing module when the whole discussion is what you need.
GitLab39

Get a Milestone

Action

In Make“Returns a single project milestone.”

Hands over one project milestone with its dates and its state.

When to use it
a report that checks whether the current milestone is still open before adding anything to it.
Watch out
it answers about the milestone itself, never about the issues sitting inside it.
GitLab40

Get an Issue

Action

In Make“Returns a single project issue.”

Reads one ticket from the project, which is how a scenario gets the details of an issue it did not create.

When to use it
a note posted on an issue, when the scenario needs its state and its assignee before deciding anything.
Watch out
read the issue at the moment you need it, because a value fetched early in a long scenario may already be stale.
GitLab41

Get an Issue Note

Action

In Make“Returns a single note for a specific project issue.”

Pulls back one comment posted on an issue, text and author, ready for the module that comes next.

When to use it
a bug report where the steps to reproduce sit in a single comment your on-call message has to carry.
Watch out
it reads one comment that you identify in advance, so a whole thread needs the list module instead.
GitLab42

Get a Pipeline

Action

In Make“Returns a single pipeline for a given project.”

Reads the state of one pipeline in a project so the scenario can decide what to do about it.

When to use it
right after a deploy, to check the pipeline before anyone announces that the release is out.
Watch out
the answer is a snapshot taken the second the module runs, and a pipeline still working will look unfinished.
GitLab43

Get a Project

Action

In Make“Retrieves a specific project owned by the user and identified by name, ID or namespace.”

Fetches the details of one project. You point at it by name, by ID or by namespace, whichever your scenario already holds.

When to use it
a scenario fed by a form, where a project name typed by a human has to become something GitLab recognizes.
Watch out
it looks among the projects the connected account owns, so a project that belongs to someone else can come back empty.
GitLab44

Get a Raw File from Repository

Action

In Make“Returns content from a repository.”

Hands over the content of a file exactly as the repository stores it, with nothing wrapped around it.

When to use it
a settings file kept in Git that another app has to read at every run.
Watch out
content is all you get here, so when the name or the size of the file also matters, the other file module answers better.
GitLab45

Get a Repository Branch

Action

In Make“Returns a single project repository branch.”

Asks GitLab about one branch of a project and brings its details into the scenario.

When to use it
before an automation opens a merge request, to confirm the branch it expects is really there.
Watch out
it answers for the single branch you name; to see everything that lives in the project, the branch search is the module to reach for.
GitLab46

Get a Snippet Note

Action

In Make“Returns a single note for a given snippet.”

Picks out one comment left under a snippet and carries its text into the scenario.

When to use it
a reviewer remark on a shared snippet that has to reach the team channel without anyone copying it by hand.
Watch out
snippet comments and issue comments are separate things in GitLab, and this module only reads the snippet side.
GitLab47

Get a Tag

Action

In Make“Returns a specific repository tag determined by its name.”

Looks up one repository tag by its name and returns what GitLab holds about it.

When to use it
a release scenario that reads the tag it just produced before it writes the announcement.
Watch out
the name has to match character for character, so a version written another way somewhere in the scenario finds nothing.
GitLab48

Get a User

Action

In Make“Returns a single user.”

Takes the user an earlier module passed along and brings back that person's details, name included.

When to use it
a chat notification where the person assigned to a merge request should read as a name, not as an identifier.
Watch out
it answers for one user you already know; hunting for somebody from a fragment of text is the search module's job.
GitLab49

Get a Variable

Action

In Make“Retrieves the details of a project's specific build variable.”

Opens one build variable of a project and reports what it currently holds.

When to use it
a check run before a release, to confirm a variable still points where the team thinks it points.
Watch out
build variables often carry secrets, so think twice about the module you place behind this one.
GitLab50

Get My Info

Action

In Make“Returns details about an account.”

Shows which GitLab account sits behind the connection, without touching anything in a project.

When to use it
as the very first module after Create a connection, tested with Run once, to see the account answer before any real work is built on top of it.
GitLab51

Keep Artifacts

Action

In Make“Prevents artifacts from being deleted when expiration is set.”

Tells GitLab to hold on to the artifacts of a job instead of letting the expiry sweep them away.

When to use it
a nightly build whose report has to survive the week when the tests come back red.
Watch out
it works on one job at a time, so place it straight after whatever hands you that job.
GitLab52

Make an API Call

Action

In Make“Performs an arbitrary authorized API call.”

This one is the escape hatch. It reaches any endpoint of the GitLab API through the connection you already created, so a scenario is never stuck at the edge of the module list.

When to use it
something GitLab can do that no module on this page covers.
Watch out
nothing is prepared for you here, you write the call and read the raw answer, which is why the ready-made modules are worth trying first.
GitLab53

Mark a Todo as Done

Action

In Make“Marks a single pending todo given by its ID for the current user as done.”

Ticks off one pending todo on the connected account's list, the way a click in GitLab would.

When to use it
a review request the scenario has already forwarded elsewhere, cleared so the list stays honest.
Watch out
it only reaches the list of the account behind the connection, never a colleague's.
GitLab54

Play a Job

Action

In Make“Triggers a manual action to start a build.”

Starts a job that is sitting there waiting for someone to press play, and lets the pipeline carry on.

When to use it
a deployment step left manual on purpose, launched the moment an approval lands in the tool where approvals are handled.
GitLab55

Post a Comment to Commit

Action

In Make“Adds a comment to a commit.”

Writes a comment straight onto a commit, where anyone reading the history will find it.

When to use it
the verdict of a check that runs outside GitLab and belongs next to the commit that caused it.
Watch out
every run adds another comment, so a scenario that fires twice on the same commit leaves two.
GitLab56

Retry Failed Jobs in a Pipeline

Action

In Make“Retries failed builds in a pipeline.”

Relaunches the jobs that failed inside a pipeline and leaves the ones that passed alone.

When to use it
a step that trips on a passing glitch, given one more chance before anybody gets woken up.
Watch out
a job that failed for a real reason will fail again, so a scenario that retries without a limit keeps going round.
GitLab57

Update a Label

Action

In Make“Updates a label.”

Renames a label the project already has, or gives it another color, from the scenario rather than by hand.

When to use it
the day a team reworks its priority scheme and the same change has to land in several projects.
Watch out
the label has to exist first, since bringing a new one into a project is the creation module's job.
GitLab58

Update a Merge Request

Action

In Make“Updates an existing merge request. You can change the target branch, title, or even close the merge request.”

Edits an open merge request: its title, the branch it targets, and closing it counts as an edit too.

When to use it
a release train where the target branch moves for everyone once the freeze starts.
Watch out
closing runs through this same module, so a mapping mistake can shut down work nobody wanted shut down.
GitLab59

Update a Merge Request Note

Action

In Make“Modifies an existing note of a merge request.”

Rewrites a comment already posted on a merge request, so the thread keeps one message instead of a pile of them.

When to use it
a status line kept fresh by a scenario that runs several times a day on the same merge request.
Watch out
the scenario needs the reference of that comment, from the module that created it or from the list of notes, before it can change anything.
GitLab60

Update a Milestone

Action

In Make“Updates an existing project milestone.”

Keeps a milestone in step with a plan that moved somewhere else.

When to use it
a quarter that changes shape after a planning meeting held outside GitLab.
Watch out
a milestone belongs to one project, so a scenario that walks through several has to pick the right one at each pass.
GitLab61

Update an Issue

Action

In Make“Updates an existing project issue. This call is also used to mark an issue as closed.”

Modifies an issue that already exists, and this is also the module that closes one.

When to use it
a support ticket that closes in GitLab the moment the help desk marks it solved on its own side.
Watch out
since closing lives here, try the scenario with Run once on a throwaway issue before you switch it on.
GitLab62

Update an Issue Note

Action

In Make“Modifies an existing note of an issue.”

Replaces the text of a comment already sitting on an issue.

When to use it
a message a scenario published too early, corrected as soon as the real figure comes in.
Watch out
the new text takes the place of the old one and Make keeps no copy, so store the original somewhere when it matters.
GitLab63

Update a Release

Action

In Make“Updates the release notes of a given release.”

Fills in the notes of a release after the fact, so an announcement is not stuck with its first draft.

When to use it
a changelog written in another tool and poured into the release once it reads well.
Watch out
the release has to exist already, and what changes here is the text, not the tag underneath it.
GitLab64

Update a Snippet Note

Action

In Make“Modifies an existing note of a snippet.”

Corrects a comment left on a snippet in place, rather than answering it with another one.

When to use it
a remark about a shared snippet that stopped being true when the code behind it changed.
Watch out
three separate modules rewrite comments, one per object, and only the snippet one will be accepted for a snippet.
GitLab65

Update a Variable

Action

In Make“Updates a project's build variable.”

Overwrites a project's build variable with the value your scenario carries.

When to use it
a token rotated every quarter and pushed into the project by the scenario that generates it.
Watch out
the old value is gone the moment the module runs, so read the variable first when you might need it back.
GitLab66

Get a Diff of a Commit

Search

In Make“Returns the diff of a commit in a project.”

Unpacks one commit and brings the change itself into the scenario, not just a reference to it.

When to use it
a digest sent to a review channel, for people who want to see what moved without opening GitLab.
Watch out
a commit that touches plenty of files comes back heavy, so keep the module you place behind it simple.
GitLab67

Get a Merge Request Commits

Search

In Make“Get a list of merge request commits.”

Collects the commits a merge request carries, each one arriving on its own, which is what lets a scenario write one line per commit.

When to use it
release notes built from what the merge request really contains instead of from its title.
Watch out
a long merge request sends plenty of items down the scenario, and every item a module handles counts as an operation on your plan.
GitLab68

List a Project's Users

Search

In Make“Retrieves the repository contributors list.”

Produces the contributor list of one project, name by name.

When to use it
an access review that starts from who actually shows up in the project rather than from a spreadsheet.
Watch out
what comes back is the contributor list of the repository, which is not the same thing as the people who hold access today.
GitLab69

List Commit Comments

Search

In Make“Returns the comments of a commit in a project.”

Gathers the comments left under one commit and passes them on, one after the other.

When to use it
a review trail copied into the ticket that asked for the change, so the discussion does not stay buried in the history.
Watch out
a commit nobody commented on gives back nothing at all, and the modules placed behind it simply do not run.
GitLab70

List Deployments

Search

In Make“Returns a list of deployments in a project.”

Lists what a project has deployed, so the record lives somewhere other than in the memory of whoever pressed the button.

When to use it
a weekly recap of what went out, put together on the morning of the team meeting.
GitLab71

List Issue Notes

Search

In Make“Returns a list of all notes for a single issue.”

Carries back the whole conversation of one issue, comment after comment, rather than a single message.

When to use it
an issue that closes and whose exchange has to be filed in the customer record.
Watch out
the module works issue by issue, so the issue has to be identified before it runs.
GitLab72

List Issues that close on Merge

Search

In Make“Get issues that would be closed by merging the provided merge request.”

Looks ahead and tells you which issues would close if a given merge request were merged.

When to use it
a message to the review channel so the people who opened those issues hear about it first.
Watch out
this is an intention, not a fact, and nothing closes until somebody actually merges.
GitLab73

List Jobs

Search

In Make“Returns a list of builds in a project.”

Walks through the jobs of a project and sends them into the scenario.

When to use it
a morning digest of what ran overnight, for a team that would rather not open the pipeline view.
Watch out
it covers the whole project, so when only the latest run matters, reading the pipeline is the lighter move.
GitLab74

List Labels

Search

In Make“Returns all labels for a given project.”

Checks which labels a project holds, which is how a scenario knows what it is allowed to apply.

When to use it
as a step placed before the module that labels an issue, to be sure the label is there.
Watch out
labels belong to a project, so a name that exists here can be missing from the project next door.
GitLab75

List Merge Request Changes

Search

In Make“Retrieves the list of changes for a specified merge request.”

Sizes up a merge request by listing the changes it brings, without anyone opening it.

When to use it
picking a reviewer, since a small change and a heavy one do not go to the same person.
Watch out
this module answers with the changes themselves, while the commits module answers with the history that produced them.
GitLab76

List Merge Request Notes

Search

In Make“Returns a list of all notes for a single merge request.”

Sweeps up the comments of one merge request and lets the scenario do something with the discussion.

When to use it
a review archived outside GitLab on the day the merge request is merged.
Watch out
your own scenarios can post here through the note modules, so read the author before you forward anything as a human remark.
GitLab77

List Merge Requests closing an Issue

Search

In Make“Retrieves all merge requests that will close a specified issue when merged.”

Answers, from the issue side, whether a merge request is on its way to close it.

When to use it
before an issue gets assigned, to see whether somebody already has work in flight on it.
Watch out
nothing comes back when no merge request is linked, and that silence is the answer; the mirror module reads the same link starting from the merge request.
GitLab78

List Milestone Issues

Search

In Make“Retrieves all issues assigned to a single project milestone.”

Groups the issues attached to one milestone so its state can be read outside GitLab.

When to use it
a sprint report built on the morning of the review, with nobody counting cards by hand.
Watch out
one milestone at a time, identified beforehand, which is exactly what the milestone list is for.
GitLab79

List Milestones

Search

In Make“Returns a list of project milestones.”

Runs down the milestones of a project with what GitLab knows about each of them.

When to use it
finding the milestone in progress before a new issue is filed into it.
Watch out
several milestones can be open at once, so the scenario needs a rule for choosing instead of taking the first one it meets.
GitLab80

List Owned Projects

Search

In Make“Returns the user's list of projects.”

Draws up the list of projects the connected account holds, which is a sound way to start a scenario meant to work across all of them.

When to use it
an inventory pulled into a sheet once a month, so nobody argues about what exists.
Watch out
the answer depends on the connection behind the module, so two connections give two different lists.
GitLab81

List Project Issues

Search

In Make“Returns a list of a project's issues.”

This module pulls the issues of one project into your scenario, one ticket per bundle, a bundle being one item passed from a module to the next.

When to use it
a Monday digest that drops the open tickets of your main repository into the team chat.
Watch out
each ticket that comes back runs the modules behind it once, and every run counts an operation on your plan.
GitLab82

List Repository Contributors

Search

In Make“Retrieves repository contributors list.”

List Repository Contributors gives you the contributor list of a project, ready to feed a report or one row per person in a sheet.

When to use it
an open source maintainer who publishes a credits page every month without opening GitLab.
Watch out
List a Project's Users returns that same contributor list, so keep one of the two in your scenarios and leave the other alone.
GitLab83

List Repository Tags

Search

In Make“Returns a list of repository tags from a project, sorted by name in reverse alphabetical order.”

Tags mark the points of a repository you come back to, and this module returns all of them, sorted by name in reverse alphabetical order.

When to use it
a release bot that reads the tags of a project before it drafts the notes to publish.
Watch out
reverse alphabetical is not newest first, so v9 sits above v10 in what you get.
GitLab84

List Repository Tree

Search

In Make“Returns a list of repository files and directories in a project.”

A scenario can inspect a repository without cloning it: List Repository Tree returns the files and folders of a project, one entry per bundle.

When to use it
a compliance check that makes sure every service still ships a license file.
Watch out
you get the map, not the contents, so send each entry to Get a Raw File from Repository to read what is inside.
GitLab85

List Snippet Notes

Search

In Make“Returns a list of all notes for a single snippet. Snippet notes are comments users can post to a snippet.”

Snippet notes are the comments people leave on a snippet, and this module collects all of them for a single snippet in one pass.

When to use it
a support team that keeps reusable SQL in snippets and archives every remark before an edit.
Watch out
it handles one snippet per run, so name the snippet first and start again for the next one.
GitLab86

List Todos

Search

In Make“Returns a list of todos. When no filter is applied, it returns all pending todos for the current user.”

Your GitLab to-do list can be read from inside a scenario: List Todos returns the todos of the connected account, and with no filter set it brings back the ones still pending.

When to use it
an end of day message that shows what is still waiting on you before you close the laptop.
Watch out
the todos follow the account behind the connection, not the whole team, so a shared connection changes what comes back.
GitLab87

List Variables

Search

In Make“Returns a list of a project's build variables.”

List Variables returns the build variables set on a project, which lets a scenario read them instead of someone checking each one by hand.

When to use it
a migration check that compares the variables of two projects before anyone touches a pipeline.
Watch out
the module looks at one project at a time, so put Search Projects in front of it to sweep a whole group.
GitLab88

Search Groups

Search

In Make“Returns a list of groups.”

Search Groups returns the groups one per bundle, and a scenario that covers a whole organization usually starts there, before it reaches any repository.

When to use it
a governance review that walks the groups one after the other before it looks at what sits under each of them.
GitLab89

Search Issues

Search

In Make“Returns all issues created by the authenticated user.”

Search Issues steps outside a single project: it returns the issues created by the account behind your connection, wherever they live.

When to use it
a weekly recap for a solo developer who juggles several client repositories.
Watch out
the filter is on who created the issue, so a ticket someone else opened and handed over stays out of the results.
GitLab90

Search Merge Requests

Search

In Make“Retrieves all merge requests for a project.”

A whole project's merge requests come back in one shot here, one merge request per bundle.

When to use it
a report that fills a spreadsheet with the merge requests of the week for the team standup.
Watch out
when you already know which merge request you want, Get a Merge Request is the module for that, this one sweeps the project.
GitLab91

Search Pipelines

Search

In Make“Retrieves all pipelines for a given project.”

Pipelines pile up fast. Search Pipelines returns the ones of a given project, so a scenario reads the history instead of a person scrolling it.

When to use it
a monthly build quality snapshot sent to the engineering lead.
Watch out
this reads what already ran, and starting a new one is the job of Create a Pipeline.
GitLab92

Search Projects

Search

In Make“Returns a list of projects of which the authenticated user is a member.”

Search Projects hands back the projects the connected account belongs to, one per bundle.

When to use it
a nightly sweep that applies the same check to every repository of the company.
Watch out
membership decides the list, so a repository nobody added that account to never shows up.
GitLab93

Search Repository Branches

Search

In Make“Returns a list of repository branches from a project.”

Branch cleanup starts with knowing what is there. Search Repository Branches returns the branches of a project, one per bundle.

When to use it
a routine that reviews the branches left behind after a release.
Watch out
deleting is another step, Delete a Repository Branch does it, and a branch removed by a scenario does not come back.
GitLab94

Search Repository Commits

Search

In Make“Returns a list of repository commits in a project.”

Search Repository Commits reads the commit history of a project and sends each commit into the scenario on its own.

When to use it
a weekly digest for a client who follows progress without a GitLab seat.
Watch out
what changed inside a commit is not part of the result, Get a Diff of a Commit brings that.
GitLab95

Search Users

Search

In Make“Searches for users or lists them all.”

Search Users finds the account behind a name, and when you give it nothing to match on, it hands over everyone.

When to use it
matching an email from a form to the GitLab account that should own the ticket you are about to create.
Watch out
an empty search walks every user, which is a lot of bundles for one lookup, so always give it something to filter on.
Need help

Need help automating GitLab with Make?

A person reads every message.

FAQ

Questions that come up next

01Is the GitLab Make integration free?
Yes. GitLab is a standard app, available from the Free plan. That plan gives you 2 active scenarios, a minimum of 15 minutes between two scheduled runs, 5 minutes of execution per run, files up to 5 MB and 512 MB of transfer. Paid plans bring the interval down to 1 minute, lift the cap on active scenarios and raise execution time to 40 minutes. Usage is counted in credits, meaning operations, each one being a single module running on a single item. What GitLab itself costs is settled on GitLab's side, not here.
02What do you need to connect GitLab to Make?
An active GitLab account and an access token. That is the whole prerequisite list in the documentation. Without an account you create one on GitLab first, which is also where the subscription question gets settled. In Make you add a GitLab module, click Create a connection, optionally name it in the Connection name field, then enter the credentials you copied from GitLab or follow the instructions on screen. For OAuth2, GitLab issues a Client ID and a Client secret from the Applications section of your profile, using the callback URI Make expects.
03Do the GitLab triggers react in real time?
Most of them do. Eight of the ten triggers are instant, which means GitLab calls Make through a webhook as soon as something happens: notes, issues, jobs, merge requests, pipelines, pushes, tags and wiki pages. Two are scheduled, Watch Projects and Watch Todos, where Make checks GitLab on the scenario's schedule instead of being called. A new scenario is set to 15 minutes by default and the Free plan cannot go below that interval, while paid plans go down to 1 minute. Instant modules also ask you to click Create a webhook before Create a connection.
04What if a GitLab module is missing in Make?
Use Make an API Call. GitLab ships that module, so any endpoint of the GitLab API can be called from the scenario with the connection you already made. Execute a GraphQL Query does the same job through GraphQL when several objects are needed in one request. One caveat worth knowing: Make's GitLab documentation is generated from GitLab's own documentation and can contain mistakes, so verify anything important with GitLab directly before building a production scenario on top of it.
05Make or n8n for GitLab?
It depends on who maintains the automation. Make draws the scenario as modules chained on a canvas, offers what your account can read once the connection exists, and counts operations against your plan, which suits a team that wants to build without writing code. n8n covers the same app by another route, closer to code and possible to host yourself. Neither wins on paper. The honest test is who will be fixing the automation six months from now, and which editor that person is comfortable in.
Hack'celeration Lab

Get our weekly automation tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations