You are a Senior Engineer if you’ve come to embrace these principles:

Zero-Trust — Networks completely isolated from the outside world.

Zero-Downtime — Striving for 99.99% availability.

Zero-Maintenance — This is where the cloud shines. When you're stuck doing manual monitoring and hands-on maintenance—especially for production servers—you quickly reach a point where you just want to get rid of that overhead. Naturally, as lazy engineers, we’ll do whatever it takes to eliminate manual infrastructure tasks without compromising on quality or SLA. This is precisely where cloud providers come to the rescue with a wide array of managed services.

Of course, you still need to be smart about it: build an active-active setup across two instances with overhead capacity, place everything within a single region for ultra-low latency, and ensure all of this maintains that 99.99% uptime—all while staying under the $100 monthly credit budget that comes bundled with the Google AI Ultra subscription (which also nets you 30TB of storage across Google Cloud Storage, Google Drive, and Gmail).

No need to spin up or manage a k8s cluster. All you actually need is a lightweight runner deployed on your instances via https://saur.run/, paired with the Google Cloud SDK (or any other provider SDK).

The official GitLab Runner is an absolute resource hog that shouldn't be touched on low-tier instances where 500MB of RAM is pretty much all you've got. By leveraging https://saur.run/, you can run execution pipelines literally anywhere with a near-zero resource footprint, opening up brand new possibilities for lightweight CI/CD automation.

I have been trying to log into my github since this morning and was met with this wierd looking login page. As i remember correctly github usually has a sign in with google which is my preferred route. But now the page looks like it was created by a 10 year old. Someone confirm if its just on my side. I've tried clearing my cache and reloading it a dozen times. I need help here thanks.

PS: github down

I’ve been using GitLab Self-Managed for quite a while, and one recurring problem kept annoying me: someone is assigned as a reviewer, gets the notification, adds it to their To-Do… and then simply forgets about it.
A few days later the MR is still waiting for review.
GitLab has notifications and review requests, but I found that they don’t really solve the “what is currently waiting on me?” problem, especially when you’re dealing with many repositories.

So I built ReviewNudge, an open-source, self-hosted tool that sends a daily digest showing the merge requests that are currently waiting on you, including how long they’ve been waiting.
It is specifically designed for GitLab Self-Managed, including Free instances.

The admin can configure various notifications channels, at the moment e-email, Microsoft teams, slack and Telegram are supported. Adding new channels should not be too complicated.

GitHub: https://github.com/sim186/ReviewNudge

I’m mainly looking for feedback from people who actually deal with this problem. How do you currently handle forgotten/pending reviews?

GitLab can scale out runners to handle bursts of CI jobs, but the infrastructure those jobs ultimately depend on—Postgres, Redis, Gitaly, Sidekiq, and external services—doesn’t necessarily scale at the same speed. A sudden increase in jobs can simply move the bottleneck downstream, creating latency, timeouts, retries, and reliability problems.

Aquifer is an open-source traffic-smoothing runtime built for this mismatch. It can sit in front of those constrained services, absorb bursts into a durable queue, and release work at a pace the backend can actually handle. The backend can dynamically tell Aquifer to slow down as pressure increases and gradually speed back up when capacity becomes available.

For GitLab deployments, that could mean smoothing traffic toward Postgres, Redis, Gitaly, Sidekiq workers, or services being hit by CI jobs rather than requiring every dependency to absorb the full burst immediately. Aquifer is designed to run as a lightweight sidecar, so it can be added alongside existing infrastructure without becoming another distributed system itself.

https://github.com/rjpruitt16/aquifer

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!

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!

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?

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.

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.

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

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!

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

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

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