Apps › Developer Tools

GitLab automation with Bizomate

Your GitLab projects know when a merge request lands or a pipeline fails; the rest of the company finds out later, if at all. Bizomate starts a workflow the moment it happens and tells the right people, and it opens issues, commits files, creates releases and runs pipelines when another app says so. It works with GitLab.com or a GitLab of your own on the internet, and every run leaves a record you can read.

Start free

On every plan, Free included.

At a glance

Label	Value
Plans	Every plan
Connect	A personal or project access token
Starts runs	Instantly
Kind	Connected app · Developer Tools

What can start a workflow

New issue
When an issue is opened

New merge request
When a merge request is opened

Merge request merged
When a merge request is merged

Push to a branch
When commits are pushed

Fill in Only this branch to hear one branch; empty takes every branch.

Pipeline finished
When a CI/CD pipeline finishes

Under When it, choose Finishes, Succeeds or Fails.

What a workflow can do with it

Create an issue
Opens an issue in a project

Update an issue
Closes or reopens an issue, or changes its title, description or labels

Closes or reopens it, or changes its title, description or labels. Labels, when given, replace the ones it has.

Add a note
Comments on an issue or merge request

A comment on an issue or a merge request, by its number.

Create a merge request
Asks to merge one branch into another

Accept a merge request
Merges a merge request

Merges it, squashing the commits if you choose.

Create or update a file
Commits a file to a branch

Commits text you write, or a file from an earlier step, to a branch.

Create a release
A release for a tag, with notes

For a tag, with notes. A tag that does not exist yet is made from the branch you choose.

Run a pipeline
Starts a CI/CD pipeline on a branch

On a branch, with variables as the project's .gitlab-ci.yml names them.

How you connect it

Make a personal access token or a project access token in GitLab with the api scope, and paste it into Bizomate under Access token. Leave GitLab address empty for GitLab.com, or type the https address of your own GitLab. Bizomate asks GitLab who the token belongs to before saving it, and Test answers with the user and the GitLab it reached — "Reached @{your username} · GitLab.com", or your own GitLab's address.

A GitLab of your own must be on the public internet: Bizomate refuses addresses on private networks, so one inside an office network or behind a VPN cannot be reached. For triggers it must also be able to reach Bizomate, since it sends each event to Bizomate. GitLab triggers add a webhook to the project when you publish, which needs the token's user, or the project token's role, to be Maintainer or Owner.

The token is encrypted before it is saved, used only when a step runs, a trigger is set up or a test calls GitLab, and never shown again — not to you, your colleagues or Bizomate support. It belongs to one workspace, the Code step cannot read it, and revoking the connection wipes it at once.

In the help centre: Connect GitLab, Start a workflow from GitLab events, Create or update a GitLab issue, or add a note, Create or accept a GitLab merge request, Create or update a file in GitLab, Create a GitLab release, Run a GitLab pipeline and How instant triggers work.

Questions about GitLab

Does it work with a GitLab of our own?

Yes, when it is on the public internet with an https address. Type that address under GitLab address when you connect. A GitLab on a private network, or behind a VPN, cannot be reached.

Which token should I make?

A personal access token acts as you in every project you belong to; a project access token acts as a bot user in one project. Either needs the api scope — with read_api the test passes but every change fails. For triggers, the user or the token's role must be Maintainer or Owner.

Do I need to set up a webhook in GitLab?

No. Publishing a workflow with a GitLab trigger adds the webhook to the project for you, and every publish sets it up again. Changing the trigger or deleting the workflow takes it away.

Can a pipeline run on a schedule?

Yes. Start the workflow with a schedule — every weekday at 22:00, say — and add Run a pipeline on the branch you want, with any variables the pipeline reads.