The moment it happens

Block merge requests that break a rule

When a merge request changes, it is checked against your rule and gets a failing commit status if it breaks it.

Runs: The moment it happens
Apps: GitLab
AI: Not needed
Access: api

Send this to your assistant

Create a ClickRuntime automation: when a merge request in my GitLab project is opened or updated, check the changed HTML files for images without alt text and set a failed commit status listing them.

Paste it into your assistant. It tells you what it will send or change before it runs live.

Add to ChatGPT Add to Claude

First time? Adding ClickRuntime to your assistant takes about two minutes.

Why use it

Why teams use this automation

Merge request rules written in a contributing guide only work if someone checks them. A branch named wrongly, a description left blank, a migration file added without a matching test or a change touching a protected folder: each of these slips through when reviewers are busy, and the cost shows up later as a broken release or an unplanned rollback.

When GitLab sends a merge request event, the changes are fetched and a set of checks is run, such as title format, description present or forbidden paths modified. The result is posted back as a commit status on the latest commit, so the merge request shows a green or red check right beside the pipeline.

It is especially useful for teams with house rules that are not covered by tests, and for platform teams that want to enforce them without writing a CI job.

What you get out of it

Rules are enforced consistently
A failing status appears for every merge request that breaks a rule, whoever opened it, so standards do not depend on which reviewer noticed or how tired they were. Consistency is what turns a guideline into a real standard.
Authors learn at once what to fix
The status explains which rule failed, giving the author instant feedback that spares a day of review back-and-forth for something as simple as a missing description. That saves reviewers from repeating the same comment dozens of times.
Protected areas stay protected
Changes to sensitive folders, like deployment configuration, can be flagged immediately, which reduces the chance that a risky edit is merged without the right approver. A second signal here is cheap insurance against an expensive mistake.
Reacts as soon as the event arrives
Because GitLab calls the webhook when a merge request is opened or updated, the status appears within seconds and is refreshed when new commits are pushed. Developers see the result before they have moved on to other work.
No extra CI minutes consumed
The checks run outside your pipelines, so enforcing a convention does not slow down builds or add configuration to every repository you manage. Platform teams can add or remove checks without touching project pipelines.

How it works

What happens, step by step

When a merge request is opened or updated in GitLab, GitLab tells ClickRuntime straight away.
ClickRuntime looks at the files the merge request changes.
It checks them against your rule, such as every image needing alt text.
It marks the commit as passed or failed in GitLab, listing the files that break the rule, so the merge can be blocked.

Before it runs live

Connect GitLab
Paste your automation's link into the other app's webhook settings

What you get

RunsThe moment it happens

Block merge requests that break a rulejust nowSucceeded

GitLab · Commit statusalt-text failed: Images without alt: public/index.html, public/pricing.html

Build your own

Need it to work differently?

This template is a starting point. Copy the prompt and change it, or describe a different automation from scratch, with your own conditions, more apps or an AI step. Your assistant writes it, tests it and runs it on ClickRuntime.

Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.

Changes you can ask for

Act only on the items that match your own rules, and skip the rest
Add an AI step, for example to summarize, sort or draft a reply
Add another app, for example also send it to Slack
Combine it with other GitLab steps into one automation

Under the hood

The code that runs this automation

This is the Python script that runs each time the automation starts. Your AI assistant writes it for you when you send the prompt, and you allow each step in your assistant. To change how the automation works, describe the change to your assistant and it updates the script for you. For every function it can use, see the script reference.

check_merge_requests_and_set_a_commit_status.pyexample

import re
from clickruntime import on_event, credentials, http

GITLAB = "https://gitlab.com/api/v4"

def gl_headers():
    return {"PRIVATE-TOKEN": credentials.secret("GITLAB_TOKEN")}

IMG_NO_ALT = re.compile(r"<img(?![^>]*\balt=)[^>]*>", re.I)

@on_event
def handle(event):
    body = event.json
    mr = body.get("object_attributes", {})
    if body.get("object_kind") != "merge_request" or mr.get("action") not in ("open", "update"):
        return {"skipped": True}
    project = body["project"]["id"]
    diffs = http.get(f"{GITLAB}/projects/{project}/merge_requests/{mr['iid']}/diffs", headers=gl_headers()).json()
    problems = [d["new_path"] for d in diffs if d["new_path"].endswith(".html")
                and any(IMG_NO_ALT.search(line) for line in d["diff"].splitlines() if line.startswith("+"))]
    status = {"state": "failed" if problems else "success", "name": "alt-text",
              "description": ("Images without alt: " + ", ".join(problems))[:255] if problems else "All images have alt text"}
    http.post(f"{GITLAB}/projects/{project}/statuses/{mr['last_commit']['id']}", headers=gl_headers(), json=status).raise_for_status()
    return {"problems": problems}

FAQ

Common questions

Can the status block merging?

Yes, if you configure the project to require external statuses to pass before merging. The failing status then prevents the merge button from being used until the author fixes the issue and a new status passes.

What kinds of rules can it check?

Anything that can be decided from the merge request and its diff, for example title format, a linked issue in the description, file paths touched or the size of the change. You describe the rule in plain words.

Does it need a webhook on every project?

Yes, each project that should be checked needs a webhook pointing to the generated URL, which you can also add at the group level on plans that support group webhooks. After that, nothing else needs to be configured.

What permissions does it need?

api. Nothing else in your accounts is used.

Does it need AI?

No. It runs without AI, so it doesn't use your plan's AI allowance.

How many runs does it use?

One run for each event the app sends.

Can I change how it works?

Yes. Describe the change to your AI assistant, for example a different schedule, channel or filter. It updates the automation, tests it and tells you what changed.

The moment it happens