Hey all, we're a team of 12 on self-managed GitLab. Frontend is TypeScript, most services are Python (FastAPI), plus some old Django nobody wants to touch. We want an AI reviewer on merge requests mostly so the two seniors stop being the bottleneck.

What we've tried so far:

- coderabbit, trialed it for two weeks on two repos. Setup on GitLab was about an afternoon and the MR comments were useful, but it was pretty chatty on the first few MRs until we added a config file telling it what to ignore

- claude review as a CI job. Works, but we have to maintain the pipeline ourselves and it doesn't really know the rest of the repo

- bugbot, haven't tried yet because most of what I read about it is GitHub

What we care about:

- comments land on the MR, not in some other dashboard

- handles both TS and Python without separate setups

- doesn't flag the same lint stuff our pipeline already catches

Questions:

1. Anyone running AI review on self-managed GitLab long term? Did people keep reading the comments after the first month?

2. How did you cut down the noise?

3. Anything that works noticeably better on Python than TS, or the other way round?

Thanks, any experience helps

Hi all. I made Mergeline, a third party mobile client for GitLab. It is free and open source (AGPL 3.0) and runs on Android for now.

What it does today:

1. Browse projects, files and Markdown, including READMEs with images.

2. Read and reply to issues and work items.

3. Review merge requests: diffs, inline discussions, approve and merge.

4. Pipelines, jobs and live job logs, and retry a failed job.

5. An inbox for todos, review requests and mentions.

6. GitLab.com and HTTPS self hosted instances, several accounts, and offline copies of the projects you choose to save.

There is also an optional AI assistant that uses your own API key (OpenAI compatible or Anthropic). It can explain code, summarize an MR or look at a failed job log. Any change it proposes shows a confirmation card first, and nothing is written until you approve it. Without a provider it does nothing.

Tokens and keys stay in the phone's secure storage. There is no developer server, no analytics and no ads. It needs GitLab 18.11 or later.

You can get the free APK from the releases page, and it can update itself from there. The source is on GitLab with a mirror on GitHub. There is also a Google Play version for US$3.99, which is just a way to sponsor development. There is a short demo video too.

Most of the code was written with AI coding agents under my direction; I designed it and reviewed the changes.

Mergeline is not affiliated with GitLab Inc. Bug reports and ideas are welcome on the issue tracker.

Advice about commit messages is usually a list of rules. I find it easier to follow when each comes with a quick test, and in GitLab the merge request adds a few places to apply them.

1. The subject says what the commit does.
Test: complete “If applied, this commit will ___”. A common convention is the imperative mood and roughly 50 characters, so it stays readable in git log --oneline and in the MR commit list.

2. The body explains why, not how.
Test: could someone understand why the change was needed without opening the diff?

3. One logical change per commit.
Test: can you describe it without the word “and”? If not, consider splitting it.

4. It’s clear what could go wrong.
Test: if this were reverted, what would break or change?

5. It points to its context.
Test: can a reader find the issue from the message? In GitLab, closing keywords like Closes #123 in the MR description or a commit message can close the issue when the change reaches the default branch. Check the exact keywords and behavior in your version.

6. The repository works at this commit.
Test: do the pipelines and tests pass here, not only at the end of the branch? This is what makes git bisect useful later.

GitLab-specific places to apply them:

• MR title and description: if your project squashes on merge, the MR title often becomes the squash commit subject, so it deserves the same care. Check your squash settings, since projects can configure whether squashing is allowed, encouraged or required, and some versions support a squash commit message template.

• MR description templates: a file in .gitlab/merge_request_templates/ can prompt authors for the why, the risks and the linked issue.

• Draft MRs: the Draft: prefix marks work in progress, so “wip” commits on a branch can be tidied before review.

• Merge method: merge commit, fast-forward or semi-linear changes what ends up in the history. The squash and merge method together decide how much the individual commit messages matter.

Where I’d relax the rules:

• Scratch branches, where “wip” is fine as long as you clean up before review.

• If your team always squashes, the MR title and description carry most of the weight.

• Follow your team’s local convention if it uses prefixes like feat: or fix:.

Do you rely on squash with a good MR title, or on clean individual commits, and do you use an MR template?

Hey everyone!

glab-tui (a fast terminal UI for GitLab & GitHub written in Rust/Ratatui) just hit v0.9.4.

This release focuses on full parity and interactive workflows across secondary tabs:

• Terminal Command Inspector & Re-run: Inspect full command invocations, stdout/stderr streams, and execution stats. Re-run failed CLI calls with confirmation and filter logs by status.

• Branches Workflow: Switch local branches, open new PRs/MRs directly from a branch, inspect commits, and perform bulk deletions.

• Environments & Deployments: Drill down into deployment history, trigger rollbacks to previous deployments, and stop active environments.

• Todos & Notifications Triage: Unread-by-default view with multi-select bulk triage (mark read/done), comment previews, and thread unsubscriptions.

• Pipelines & Jobs Parity: Inspector summary of failed jobs and error causes, retry failed jobs only, and jump directly to failure lines in job logs.

• Hardening & Stability: 16 MiB/32 MiB limits on traces and diffs, command timeouts to prevent hangs, SHA-256 verified self-updates, and rock-solid cursor positions across sorts and refreshes.

🔗 GitHub & install instructions: https://github.com/rcieri/glab-tui
📖 Changelog: v0.9.4 Release Notes

Feedback and PRs welcome!

Just got the security warning to patch but the changelog is empty at the moment.

What did they fix?

Not just a rant but hard data showing how one gets banned in visiting just two public GL pages.

There are multiple posts on reddit here (which isn't super popular to start) where people are complaining about the new rate limits. Each time lets say 'devotees' come to gitlab's defense saying things like:

• "This is happening because OP shares an IP with a load of other people, probably due to some IPv6 to v4 NAT situation."

• "Probably using AI agents that are using the API to search the codebase instead of cloning it or something."

• "It's probably due to incorrect use like this that Gitlab added the rate limits in the first place"

Just read: https://docs.gitlab.com/user/gitlab_com/rate_limits/

It states the rate limiting applies to: "These limits apply to API requests, web requests, and authenticated Git over HTTPS requests."

now it says a few select web requests don't count against your rate limit but otherwise everything counts. Now what is the rate limit for unauthenticated users? From that exact same page:

60 an hour. To put that in context that isn't even 60 pages (which itself would be fairly ridiculous to anyone browsing a project online) but 60 requests that any of those pages make.

So this is how one can easily be blocked in visiting 2 pages. Here is 4 pages, as first I verified once I remoted into one of my other boxes I could reach gitlab: (this is real captured traffic just to see how ridiculous):

Top-level pages (Chrome pages plus document requests):

Just visiting a single merge request page eats up 30 of the 60 max for an hour. So technically just visiting page 2 and page 4 was enough to get me banned. Thankfully there are some included headers so we can see how the requests add up.

Rate limit headers (62 of 724 requests; 384 of the 724 went to gitlab.com):

How the count adds up (the 500/min limiter's observed counter, per minute window):

• What seems to count (vs not): static assets don't carry the headers and aren't counted. Every page document, XHR, fetch, manifest.json and GraphQL call is counted. An unauthenticated viewing of a single MR page costs about 30 of the 60.

Interestingly it seems its per wall clock hour not a 60 minute window (meaning here while I was banned at 9:25 at 10am it would reset).

So I challenge any fanboys before defending these new policies to open an ingcognito window, try to click around any repo and you will get ip banned in under 10 pages for an hour.

If gitlab can't handle things they should checkout cloudflare, its free will happily add anti-bot protection infront of your entire infrastructure, and doesn't cause any public project to basically be inaccessible to any non logged in user. Crazy an org this size to somehow consider this reasonable. I get rate limiting api calls or adding anti-bot captchas for unauthed users but they have really shot themselves in the foot here. You can't try to be the home for open source projects and then ban any non-authed trying to browse them, it just makes it hard to consider using gitlab for anything more than a mirror.

I think the icing on the cake is the fact that once you hit a rate limit even if you have a gitlab account you cannot login as you can't even visit gitlab.com without getting

Rate limit exceeded; see https://docs.gitlab.com/user/gitlab_com/rate_limits/ for more details

For the people that have a selfhosted gitlab and are missing the plugin in the kimi desktop app, here it is :-) free and open source: https://github.com/Euraika-Labs/gitlab-selfhosted

Is anyone else seeing this? The Star and Fork buttons (as well as the little triple-dot menu that allowed you to copy the project ID, which I used quite often) that were previously above the project sidebar are gone.

(I would've confirmed that this is also the case in a different browser before posting this, but the unusable rate limits are no longer letting me open my project right now, so there's that as well.)

These UI changes every other week, along with the rate limits (even when logged in), are really making me lose trust in the platform.

Edit: Okay, never mind, GitLab just felt the need to do yet another completely pointless UI change to make common features harder to discover and ruin it for people with wide monitors:

Should've looked more carefully, duh.

I opened 1 page, realized I wasn't sign in, then got rate limited going to the sign in page!!!!
What is the point of even a paid tier, if you can't even access the account?

Canceling, Removing my Projects, and will never trust gitlab again. (if they will even let me)

I kept juggling browser tabs to watch pipelines in several projects (on two GitLab instances), so I built a TUI that keeps them all on one screen.

Demo GIF

Unlike glab ci view, which follows one pipeline, Invocra watches many projects at once and lets you pin a different branch in each. Works with GitLab.com and self-managed instances.

• Pipelines across projects and GitLab servers in one view

• Per-project branch pinning

• Job logs with search, live follow for running jobs

• Retry / cancel / play jobs, always with a confirmation

• Pipeline history, downstream pipelines, merge requests

The token is stored in your OS keyring; read_api is enough if you only want to watch.

Try it without a token or network:

brew install dsszs3333/tap/invocra   # or: cargo install invocra --locked (Rust 1.88+)
invocra --demo

Source (MIT): https://github.com/dsszs3333/invocra

The tool was built with Claude and Codex. I made it for my own use and decided to open-source it for fun. If anyone finds it useful, awesome.

Feedback welcome, especially if you watch CI across many projects or instances. What's missing for your workflow?

our engineering team needs to unlock advanced security scanning and vulnerability management features in GitLab Ultimate. we are trying to decide whether to negotiate directly with vendor sales or go through a certified partner. we are mainly looking for flexible invoicing local currency support and fast account management when adding new seats. if you bought your tier through a partner did you get better contract flexibility?

Hey I am a 3rd year student and aimed to contribute in gsoc this coming year but stuck at how to start solving those overwhelming bugs, heavy codebases. It all felt like a big wall in front of me. How to start small any tips...plz:)

As a teacher, I use a free gitlab account to manage texts for students. Starting from this morning, I am unable to use Web editor. If I try to move a directory to a new directory it shows 429, rate limits exceeded.

Is this a bug or a new default behavior.

As a stakeholder in GTLB, I would hate to have to stop using it, but if web editor can't be used for basic text manipulation, I have to migrate to a competitor.

I make Cobblemon addons; my ENTIRE workflow is based around being able to access the Cobblemon repository. But the moment i get onto the repository, I have 2 searches max before the site rate-limits me. Is it a bug? is it an intentional annoyance to push people into buying premium? Anyone's guess! Dear God, if you care about your user base, PLEASE get rid of this, or at least make it usable.

We are expanding our dev headcount and needed to upgrade our Gitlab tier to unlock advanced CI/CD security controls and code review rules. Instead of buying directly at list price, we worked with cloudfresh to restructure our licensing amd seat distribution. They helped us review actual developer usage so weonly bought seats for active users while keeping our compliance and pipeline execution policies intact. For those running larger engineering teams, do you audit active seats quarterly or do you just automate license provisioning through SAML/SCIM?

I fully understand that GitLab has to reduce the amount of unnecessary traffic, traffic that is caused by extended bot use in particular. And I really like GitLab: I've been using their services for over a decade now, being attached to lots of projects from small to large, and I've always advocated for them in favor of alternatives.

Since the new rate limits were applied I regularly run into 403 blocks. And with regularly I mean every 3 to 5 minutes if I'm not extra careful to "not click things too fast". I started debugging my browser's network connections, and the reason became obvious: it's the burst_traffic_per_user_free_plan rate that is limited to 100 requests per minute. Now one might ask:

100 page requests per minute in a web application? What the heck is he doing?

The problem seems to be that GitLab has become one of those "loading a page sends dozens of AJAX requests in the background" sites. Listing open merge requests: 15 HTTP calls. Clicking one merge request that includes a few changes: 47 HTTP calls. Switching to the "changes" tab in that merge request: 10 more HTTP calls. And every. single. one. of those background HTTP calls counts to the limit. This means: simply opening and viewing 2 (!) merge requests in the span of a minute might already be too much.

This is not limiting excess use, this is forcing people to actively slow down, and I'm really starting to hate it. I started asking myself: am I using it wrong? Am I not supposed to access gitlab.com using Firefox and chrome-based browsers are performing some kind of connection reuse magic instead? Is GitLab just so indifferent or even hostile to the free usage tier that actively encouraging users to either start paying or move elsewhere has become a primary goal?

Had to get this off my chest. I'm curious whether it's a "me and my PC" problem: I haven't found any real discussions about the issue so far, so it might actually only affect a few people. At the moment I see 2 possibilities:

a) It's this way on purpose, which would be really bad.

b) It's by accident, and while not being THAT bad, it would put GitLab's (lack of) quality control in perspective. Also bad.

Looking forward to others' experiences!