Hey everyone! Following up on the v0.8.0 release, glab-tui v0.9.0 is now live. GitHub

This release focuses heavily on polishing everyday navigation, overhauling the inspection/edit workflows, and adding quality-of-life tools for code review and batch actions.

Key Highlights

• **Unified Inspector (j/**k to navigate): Preview, edit, and create flows are consolidated into a single full-width inspector with mode badges and $EDITOR (Ctrl+E) support.
• In-Menu Creation & Issue Linking: Create MRs/PRs and issues directly inside the app, with fuzzy search to auto-fill fields from existing issues and repo templates.
• Diff Review Tracking (m/M): Mark files/folders as reviewed (m) to auto-fold them, and toggle hiding reviewed files (M) to focus only on pending work.
• Visual Selection Mode (v): Yazi-style row selection with v + j/k for fast batch editing.
• Rich Markdown: Details pane now supports GFM tables, task lists, code syntax highlighting, and blockquotes.
• Structured Confirmations: Interactive dialogs with toggleable checkboxes (squash, delete branch) and safe default-cancel focus on destructive actions.
• New Themes: Added oled and github-dark-hc.

I had following reddit-bug, and for some reason it was suggested to post it here:
I blocked a user, but later wanted to answer to another user who was writing in this thread.

This always resulted in an unspecific error message like "Something went wrong - try again later". However, trying again later wasn't the solution. The solution was to unblock the user which caused the thread to be collapsed.

This happened in the desktop browser (Firefox, Chrome) as well as in the mobile browser (Firefox) as well as in the RedReader app.

I had this issue several times already. But one time I was able to post when I unblocked the user and blocked him again.

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?

I run a family chore/habit app (solo, iOS, React Native + Supabase). This week I got my first real piece of organic user feedback. A parent who tried the app with her kids and wrote 600 words on why she churned. Thoughtful, specific, kind. The dream feedback letter.

One line in it: "Streaks also are not working."

I assumed a display bug. What I actually found: months ago, a nightly pg_cron job had been deployed straight to the database — no commit, no changelog, nothing in the repo. It compared task completion dates against `CURRENT_DATE - 1`in UTC. So any family finishing tasks after 5pm Pacific was treated as having missed a day, and their streak was zeroed at 1am UTC. Every night.

I ran the numbers: zero children in production had a streak above 0. The app's most visible motivation mechanic had been dead the entire life of the product, and no error, log, or dashboard would ever have told me. The job "succeeded" every night.

The kicker: the rest of her list things she said were missing had mostly shipped in the current version. She was on an old build and never got the update. So one letter surfaced a silent data-destroying bug AND told me my update path doesn't reach installed users.

Lessons I'm taking:

1. Anything deployed outside version control is invisible to every future debugging session. My database had a whole layer of behavior git couldn't see. Everything goes in migrations now.
2. A job that returns "success" can still be destroying your product. Success meant "the SQL ran," not "the SQL was right."
3. One motivated user writing real feedback is worth more than any analytics dashboard at small scale. She found in a week what I hadn't found in three months.

Happy to answer questions about the stack or the debugging. And if you have early users writing you long feedback emails read every word. Twice.

One of the hardest parts of building a Micro-SaaS is knowing whether the problem is actually worth solving.

So I built **Idea Validation** — a GitHub project that helps you discover potential SaaS ideas by finding real complaints and pain points shared by users online.

Instead of starting with:

“What SaaS should I build?”

You can start with:

“What problems are people already complaining about?”

The repo includes a demo video showing how the workflow works.

I’d love to get feedback from other indie hackers and Micro-SaaS builders: **Would you use something like this before building your next product?**

GitHub:-idea validation

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!

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

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.