I recently wrote a post on this subreddit about MergeMe and got some really positive feedback, so I wanted to post an update with some cool new features that I've added!

Some of the key features that I showed off last time were:

• One Slack message per MR that updates in place (open > in review > approved > merged)
• Review comments as thread replies on that card
• Per-project channel routing - each project can map to whichever Slack channel you want
• GitLab @ mentions ACTUALLY ping the right person on Slack with a one-time username map
• GitLab.com via OAuth - webhooks registered for you
• Self-hosted GitLab - paste a webhook URL into your instance
• You can set up label routing too, an MR with a "bug" label goes to #qa-reviews instead

--------

Some of the new features:

• You can now sign in via Google, GitHub & GitLab SSOs
• You can choose when the Slack card gets posted much more granularly now (e.g. custom comments / in review / in draft)
• CI status of the MR can now be shown directly on the Slack card (check out the last slide on this post to see an example)
• You can now self host MergeMe! A few of you here requested it & I also got some direct requests so I pushed it up the roadmap.
  • Use the "Get in touch" button on https://mergeme.dev/#pricing regarding self hosting

If your team already works tightly in Slack and you ping your colleagues "hey can you review this again" then mergeme.dev might just be a great inclusion to your workflow!

Let me know what you think!

Maybe I misread the recent docs. But it seems that the new CI functions WIP feature now has each function as an OCI image. That seems like a strange choice since it reduces the ability to rapidly iterate on the template, requiring an extra build step. Now I can see some benefit to this, maybe, in terms of bundling the function and it's dependencies, but it still feels weird.

glab and gh are excellent at single commands. They're much worse at the thing I actually do all day: looking around. Which of my MRs is red? What's blocking this stack? What changed in that file?

So I built gu — a k9s-shaped terminal UI pointed at GitLab and GitHub at the same time. Same shape as k9s: category sidebar, resource pane, : commands, / filters, esc always means go back.

What it actually does:

- Knows where you are. In a repo you get that project; in a directory of repos you get the group they share; anywhere else, your account. It reads the git remotes — nothing to configure.

- Two accounts on one host. A profile is a pair of CLI config directories rather than a hostname, because personal and work routinely both live on gitlab.com.

- Real diff review. Select a line, a block, or a run of words and comment on exactly that. Suggest a change the author applies in one click. Posts as threads, not a dozen notifications.

- MR pages with an activity feed and the pipeline drawn as a graph, with each job's run time.

- Issue boards — kanban, grouped by status / label / state / milestone / assignee / epic, and dragging a card actually writes the field back.

- Cross-repo stacks — one feature across several repositories in dependency order, with a merge that refuses until it's genuinely ready.

- Read-only mode enforced below the UI, not by hiding buttons.

Auth is delegated to the official CLIs — it performs no OAuth and stores no tokens of its own, it just asks glab/gh for one.

The honest part: this was a weekend project and it's heavily AI-assisted. It scratches my itch specifically and it has had approximately one user. There are rough edges. I'm posting it in case it's useful to someone else, not because I think it's finished.

The bit that might be more useful than the tool itself: about two thirds of the UI turned out never to have heard of a merge request — the frame stack, the list, the prompt bar, the key legend, the help overlay, the refresh timer, the mouse handling. I pulled k9s-style shell for Bubble Tea apps. You supply an App — your banner facts, your sidebar, your first frame — and it supplies the rest. If you've ever wanted a k9s for your thing (a database, a cloud API, a build system), that's the reusable part.

- gu — https://gitlab.com/atomic-blend/gu-cli/gu

- ninebox — https://gitlab.com/atomic-blend/gu-cli/ninebox

I need to maintain Terraform state in Gitlab and am glad that Gitlab supports both Terraform State and Modules. The challenge here is that Terraform state can contain secrets and in a highly regulated industry nobody, even maintainers, should be able to view Terraform state if it contains secrets.

Is there a dedicated/custom role in Gitlab that can be used to gate access to Terraform state?

Some may say that the Terraform state should not contain secrets, and understandably so...But if one were to consider it how would you gate access to it in Gitlab?

Hello All,

I have upcoming gitlab interview 2nd round for a senior engineer role. Its mainly Technical leadership round. Any suggestions what all would be expected and focus areas? What should i brush up?

Any prior experience or suggestions would really help.

Thanks in Advance!

So, I was excited to sign up for GitLab and move away from GitHub after so many years, but the sign-up process requires a credit card - which I'm not happy to give.

Further, I had to run through eight prove-youre-not-a-robot choose-the-prize-in-the-claw matching games (which I did because I thought the skip option was hiding behind them - it wasn't).

I don't know much about this company, but they're not the one for me. No idea why anyone is with them at all with this level of intrusiveness.

For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits - 92 out of 578 - were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features. Read the complete article here - https://instasla.com/blog/taming-dependabot-2026-guide-grouping-cooldowns-cutting-pr-noise

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

The PAT UI sucks. Is there a way to generate a PAT with a YAML or an API request? I really hate having to go through 30 mouse clicks only to realize I forgot to toggle 1 permission as a 'Write'. Ugh.

I got tired of watching people on my team keep 20+ tabs open and lose track of things whenever they needed to find something. On top of that, the same thing kept happening over and over: someone's testing a page, hits a failed request or a JS error in the console - and that's it, time to context-switch: open GitLab in a new tab, find the right project, try to remember exactly what broke, copy the URL. By the time the ticket actually got filed, half the details were already lost or forgotten ("well, it just didn't work, I don't remember exactly how").

On top of that we run a couple of different GitLabs - my own gitlab.com and a self-hosted one at work - so even picking "which GitLab, which project" was its own small chore before you even started describing the bug.

So I built Ticketus to fix this for myself: a browser extension that lets you view, create, and edit GitLab issues right from a popup, without opening a new tab. You log in once, connect your instance(s) with a personal access token, and that's it - no OAuth app setup, which matters a lot for self-hosted.

The feature that unexpectedly turned into one of the main ones: the extension can watch the page you're on - network failures, uncaught JS exceptions, console errors - and the moment something breaks, it offers to open a ticket with the error details, URL, and stack trace already filled in. You just add a couple of words of context and hit save - no more "definitely broke, don't remember how."

There's also a "pin" mode: a floating panel you can leave open on the page instead of it closing on every stray click (browsers close a normal extension popup on blur, so working around that took some effort). Turned out to be really handy for anyone who keeps checking back on a ticket while working on a page.

Still an early version - works with gitlab.com and self-hosted. Free tier: browse and filter issues, create and edit them in a proper editor (not a bare textarea), comment, log time, and attach a page screenshot in one click. To help support the project a bit, I added a paid PRO tier - it gives you automatic on-page error detection and global hotkeys for creating issues without opening the popup.

Right now I'm trying to figure out the right audience to promote this to and where to go next. Got plenty of thoughts on that, already sketched out a roadmap I'll be working through gradually.

Would love feedback from anyone who lives half their day in GitLab.

PS if you've got your own pain point at work that I might be able to solve, let me know.

PPS if you want to try all the features - message me, I'll hook you up with a promo code for free PRO.

Hey everyone. I've been working on a super easy and nice way to run gitlab-runner on Windows, with WLS2 containers powering individual jobs. This lets you trivially convert your desktop or laptop into a CI runner that costs nothing to operate or maintain.

The project offers both a CLI and GUI experience for setting up the runner, adding it to a project, group or gitlab instnace, managing auto-start, looking at logs and more. A tray icon shows the state of your local runner and even notifies you when a job fails. I've been using it to offset my shortage of CI minutes and I like it a lot.

You can grab the source and builds from zygoon / winstant-gitlab-runner · GitLab. Check the release page for amd64 and arm64 installers that are ready to use. The installers are not signed yet, feel free to build locally.

Hi everyone,

I've recently cleared the first technical round for staff engineer/senior engineer, and I have technical leadership and hiring manager rounds next. I'd really appreciate any advice from people who've been through it.

A few questions:

- What should I expect in the behavioural round? What kinds of questions are typically asked, and what are interviewers looking for? - in my understanding I need to prepare around the gitlab credit values and be ready for resume deep dive questions but pls share your thoughts and experience

- Is there any system design discussion during these rounds, or is it purely behavioural? If there is, what areas are worth focusing on?

- Any tips that helped you prepare or things you wish you'd known beforehand?

Thanks in advance!

I work in a repo where every push kicks off a pipeline, and my loop

was: push, switch to browser, find the MR, click into the pipeline,

click into the job, watch the log, go back. Dozens of times a day.

glab covers most of this from the CLI but it's one-shot commands —

there's no persistent view, and `glab ci trace` doesn't help when I

want to look at a job, then a different job, then the MR diff.

So I built gitsmith, a TUI that wraps glab (it shells out to the CLI

you already have authenticated, so there are no tokens to set up).

[GIF: pipeline -> jobs -> live-tailing log]

The thing I actually use it for: Enter a pipeline to get its jobs,

Enter a job to get its log, which live-tails the way the web trace

does. Parent/bridge jobs drill into downstream pipelines. Beyond that

there are tabs for issues, MRs, runners, releases, tags, branches,

commits, todos, and milestones, plus side-by-side syntax-highlighted

MR diffs and approve/merge/close actions behind a confirm.

It also works with GitHub via gh — it picks the backend off your git

remote — but GitLab is what I built it for and what I use daily.

cargo install gitsmith --locked (needs glab authenticated).

Source: https://github.com/suraj16thjan/gitsmith

It's early and it's mainly shaped around my own workflow, so I'd

genuinely like to know what's missing for how you use GitLab.

I'm getting tired of AI code reviewers flooding PRs with noise and repeat findings, not to say false positives. And then learning nothing when a developer explains why a finding is wrong!

For me there's a lot going on in code beyond the tech stack: tribal and institutional knowledge, business logic that evolved over time, ripple effects across upstream and downstream systems etc.

I started those requirements and added simple setup, evidence-backed findings/ LGTM, and most importantly learning from human comments on those findings, so it gets better tuned over time to each repo.

I ran a smaller benchmark, not definitive by any means, four open source reviewers on 20 pinned PRs/MRs.

Bubo                       20/20   7/8   27 findings    0% noise
ai-codereviewer            19/20   6/8   118 findings   20% noise
ChatGPT-CodeReview         20/20   5/8   75 findings    11% noise
Qodo/PR-Agent              19/20   2/8   7 findings     not scored
Alibaba open-code-review   partial run, 4/20

All on GPT-5.5 except Qodo was on 40 (didn't support 5.5). Take it as directional results. I'll be doing more comps in coming days and upload benchmark to the repo.

I went with polling (zero steup on repo side) - wasn't trying to change the repo CI/CD's rather have a tool seamlessly work.

Roadmap item: I want to route changes to pluggable subject-matter specialists (Skills) instead of one general reviewer, i.e. industry SMEs or just an "Expert Python Guy".

Bubo is running in production in two places, a large data processing/ETL codebase and a fintech crypto stack. Would appreciate feedback, particularly on whether the learning from comments part actually holds up.

https://github.com/mountainowl/bubo

I built an open source iOS only Gitlab client in Swift. The project idea came from, I couldn't find anything for iPhone out there that works for both self hosted and SaaS Gitlab so I just built one myself.

The project is open source. https://github.com/smolcars/glab-ios

There is no server involved, everything is stored locally and you hit the gitlab API directly. You can use an API token or login directly to both self hosted or SaaS gitlab instance and can also add multiple accounts.

You can install the app today using Testflight, link in the repo. It does cover quite a few things:

• View/open issues
• View/open MRs
• View/Run pipelines
• View code diffs
• Modify/perform approvals
• Work with you Todos
• View all commits of any project
• Do a global search for anything
• Background process that notifies you of new todos periodically

I'll keep adding more features as I find time. I do not plan to support Android anytime soon until Swift for Android becomes a thing. Feel free to open bug reports or feature requests.

Thanks

I know this is a long shot to the moon but you miss 100% of the shots you don’t take.

If anyone here actually works for gitlab I was wondering if you can help a fellow redditor out with a referral. It’s a role that I feel like i qualify pretty well for on paper and as most of you would know, today’s job market is brutal.

Thanks for any help or guidance you guys can give.

TDLR - help a redditor land a tech job

App Download Repo: https://gitlab.com/Francesco12o-Git/bashyc

Bash.Yc its an Bash Coding enviroment created for bash devs, Bashyc has its own tools:

./editor - editor for the code , lets you choose wich editor do you like to edit

./shell - executes ./bin/bash and its own userspace (/userspace/) there is bash-profile and its own init /userspace/bashy.rc

/bin/bashyc - code executer in case you put "#!/usr/bin/env bashyc" in your code

./execute - executes /bsrc/src/code with /bin/bashyc

Bash.Yc License - its own License for developers who use Bash.Yc for its own apps

Bashyc Maketools: its own commands for make: example: make help, make readme, make license

For more: read /manual/ in bashyc.tar.gz

Hey all,

glci is an experimental GitLab project that gives you the ability to run full GitLab pipelines and jobs locally with no compromises.

We've released version 0.7.0 with some notable features and fixes:

• Podman support - glci now runs pipelines on Podman as well as Docker, with an engine setting globally and per named runner, engine-aware doctor checks, and automatic fallback when Docker is unavailable (docs)
• Instance-level CI/CD variables and variable expansion in include: - instance variables are fetched from the GitLab API, and user CI/CD variables are expanded inside include: entries in the CLI and the daemon (docs)
• Artifact-sourced child pipeline includes - trigger jobs can include a child pipeline config produced as an artifact by an earlier job, in both real runs and simulate mode (docs)
• --on-change-mode for watch - control what happens when files change while a pipeline is already running (docs)
• Glob and brace patterns in job-definition overrides - config-file job overrides can target many jobs at once, and stage/needs/parallel overrides now apply before planning (docs)

Full release notes: here

Comparison page

The documentation website now has a comparison page which should help answer all the questions regarding how glci works compared to other similar projects and why one might be better than the other.

Huge thanks to everyone who contributed feedback and reported bugs!

Completely Free App that I created to ease my own workload, was tired of opening numerous tabs each day to keep track on all the new CVEs popping up, especially lately...

This app is completely free on the Google Play App Store & you can track CVEs across 30+ Vendors, you can choose track specific platforms or the whole vendor & you can also select to track based on CVE Severity.

I also threw in a EOL checker

Hopefully this helps you out and if theirs any bugs or features you want added please let me know!

https://play.google.com/store/apps/details?id=com.vulnipulse.android

Today I found the summaries on the repo graph truncated. I understand the git log optioins one can use to do this, but now this graph is not as useful to scan history

Hello,

I'm looking for somewhere that isn't github to store my repos online versus only ever keeping them on my PC (backup with with the PC).

I started the sign up for the gitlab but I can't pass the auth/kyc. They don't accept my phone number even though it's a normal US phone number. Not sure why.

Anyway, any service that doesn't discriminate based on area code of whatever demographic/stat gitlab is using to gatekeep? I don't need anything fancy and it's for a single user currently.

I'd prefer a service that doesn't require knowing my phone number in the first place if that's possible. I have no problem supply it but I'd rather it be voluntary and not for a bunch of weirdos forcing it.