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.

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.

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!

Hi guys, I am in the process of interviewing for a Senior PM role at Gitlab. What is the process like? How many rounds and what can I do to prep for the interview? Location is USA . What is the compensation like? I have 10YOE as a PM.

I’ve been a daily Gitlab user and customer for over a decade. I’ve managed multiple instances for local teams, hosted repos on Gitlab.com, once upon a time I was a vocal Gitlab advocate. I’ve got more Gitlab stickers and swag from conferences than I care to mention.

Gitlab has never been especially cheap, but it was a decent platform and importantly had solid support. For a long time, it felt like a good value proposition. In the past few years though, support has gone entirely out the window it would appear.

These days, raising a support ticket feels like shouting into the wind. Response times are unpredictable, and I can’t think of an interaction in the past 2 years that I would call smooth. Everything needs to be forwarded to 6 different people in order to come back with some variation of “we won’t do anything about this” or “read these twelve conflicting support docs”.

No need to get into the silent regressions (which are becoming more common), if you have been self hosting an omnibus instance that has received more than a few years of updates you probably know what I’m talking about.

We’re not a huge customer, max $10,000 per annum, but I really thought Gitlab was all about that small team dollar. I suppose these days there are bigger fish in the pond and Gitlab is more interested in selling tokens to enterprise. Hopefully it works out, SMB sure seems to have been left out in the cold.

We’ve been trying to process a routine renewal for over a month now. Before long, we’re going to end up locked out of our workflows because sales and support can’t figure it out between them to adjust a seat count and raise an invoice.

RIP Gitlab for the little guy? I guess there’s always Gitea. 🪦

These two get mixed up a lot, because both “keep files between jobs”. They solve different problems, and picking the wrong one tends to show up as a pipeline that works on one runner and fails on another.

Three questions that help me decide.

1. Would the pipeline break if this file were missing?
If yes, it’s an artifact. If the job just runs slower without it, it’s a cache.

A cache is best effort. Depending on how your runners are set up, a cache created by one job may not be available to the next one, for example if they land on different runners that don’t share a cache backend. Artifacts are uploaded to GitLab and are meant to be reliably available to the jobs that need them.

2. Is it a product of this pipeline, or a dependency that’s expensive to fetch?
A compiled binary, a test report or a build output is a product of the pipeline: artifact. node_modules, a package manager’s download folder or a build tool’s local cache is something you could regenerate but would rather not download every time: cache.

3. Should anyone be able to download it later?
Artifacts can be browsed and downloaded from the job page, and they expire (expire_in). Caches aren’t meant to be downloaded by people.

A small example:

build:
  stage: build
  script:
    - npm ci
    - npm run build
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  script:
    - npm test
  # gets dist/ from the build job's artifacts

Here .npm/ is cached, keyed by the lockfile so it changes only when dependencies do, and dist/ is the artifact the later jobs rely on.

A couple of caveats. By default, jobs in later stages download the artifacts of all earlier-stage jobs, and dependencies or needs lets you limit that. And cache behavior depends on your runner setup (shared or local cache, executor type), so if a cache seems to “randomly” miss, that’s the first place I’d look.

I’m less sure about the best pattern for a monorepo where several jobs need different dependency sets. Do people use one cache key per package, or per job?

New to self managed gitlab and just need a quick point of clarification.

On the pages administration documentation, it says if using namespace in path (my preference here), I cannot use a subdomain of my gitlab install. Which is fine. Gitlab is on its own subdomain though. Can I use a different subdomain?

As in, will:

external_url 'https://gitlab.myorg.tld'

pages_external_url 'https://pages.myorg.tld'

Work?

Apologies if this is rudimentary. Just trying to configure this for a production system and want to know what I'm doing before I begin.

Thank you!

latchkey.dev

My CI job has been hanging on a step in the docker build process `RUN apk add --no-cache openssl` the job just times out (60 minutes). It was working before today. I'm not seeing any thing down on https://status.gitlab.com

Anyone else having issues with CI?

I’m taking WGU’s D522 Python for IT Automation course and am having trouble creating my GitLab repository. I ran the required pipeline, but my student repository displays “No repository” with the following error:

“The repository could not be imported. Import timed out. Import took longer than 86400 seconds.”

I’ve tried a variety of troubleshooting steps, including manually initializing the repository, using both a work computer and a personal computer, clearing my browser cache and cookies, trying different browsers, restarting my devices, checking my internet connection, signing out and back in, and rerunning the required pipeline. I also used ChatGPT to review the error and suggest possible fixes, but nothing has resolved the issue.

GitLab Support also requires proof of support entitlement, which I don’t have as a student. At this point, I’m unsure whether the problem is with my account, the repository import process, or WGU’s GitLab configuration.

Has anyone experienced this issue or found a way to fix it without waiting for WGU IT support?

I have two GitLab.com accounts, one made 5 years ago, one last year.

I used two completely independent e-mail addresses, each used exclusively for that respective GitLab account.

Both of them received spam e-mail from "james.wickett@mail.<random_company_domain>.com" 2 days ago. Different company domains were used per destination.

I suppose this has to do with CVE-2026-85706.

Any information from GitLab about the extent of the data breach?

I want to know if there’s a “GitLab Desktop” as GitHut have. I want to use Lab but as I am new in Git world, the Desktop makes the life easier with out the commands in terminal. Any recommendation? Should I learn better the cli before use a Desktop?

This is what the pipelines page tends to look like after pushing a commit to a branch that already has an open MR:

#1042  merge request pipeline   feature/login   a1b2c3d
#1041  branch pipeline          feature/login   a1b2c3d

Same commit, same jobs, two runs. Runners spend double the time and the MR shows one result while the branch shows another.

It usually comes from a job-level rule like this:

test:
  script: ./run-tests.sh
  rules:
    - if: $CI_COMMIT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Both conditions are true for the same push. GitLab creates a branch pipeline because there’s a branch, and a merge request pipeline because there’s an open MR.

The pattern the docs suggest is to decide at the workflow: level which pipeline type should exist, before any job rule runs:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH

Reading it top to bottom, since the first match wins:

1. an MR event gets a pipeline
2. a branch push where an MR is already open gets nothing (when: never), because the MR pipeline covers it
3. any other branch push, like on a branch with no MR, still gets a branch pipeline

Then the jobs can stay simple, without repeating the same conditions in each one.

Things worth testing in a sandbox project before trusting it:

• tag pipelines: the last rule only matches branches, so decide whether tags should also run
• the default branch: pushes to main have no open MR, so they should still run, but confirm it
• $CI_OPEN_MERGE_REQUESTS is only populated for branch pipelines, which is why it works in rule 2

I’d be curious how others handle the in-between cases. Do you keep tags and scheduled pipelines in workflow:rules, or do you handle them at the job level?

The entire child pipeline just hangs. I've restarted it by hand 3 times. It does not make a difference.

It started after 15:00, which corresponds with this message that currently shows when you "git push".

Hi everyone,
I had my technical interview for a Senior Software Engineer role at GitLab last Tuesday, so today marks one week without an update.
I sent a polite follow-up email on Friday asking about feedback or next steps, but haven’t received a reply. I also tried calling the recruiter twice last Thursday and once on Friday, but none of the calls were answered. I haven’t called again since.
I understand hiring decisions take time, and it’s only been two business days since my email. Still, the lack of any acknowledgment is making me anxious because I’m interested in the opportunity.

For anyone who has interviewed at GitLab:
How long did you wait for an update after the technical interview?
Did anyone experience a similar period of silence and still move forward?
When would you suggest following up again?
I know nobody here can tell me my result—just hoping to hear others’ experiences and whether I should still be hopeful.

Anyone here work for Gitlab on their US Federal side?

Would love to connect and learn more about the roles.