r/gitlab

PS: github down

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.

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’m building a Git desktop app with a slightly different idea from normal Git GUIs.

When you do something like commit, stash, pull, reset, merge, etc., it doesn’t just say “success” — it shows:

• the actual Git command that ran
• what changed in your repo
• a simple explanation of what just happened
• clear warnings showing exactly what you’ll lose before destructive actions

There’s also an optional Learning Mode that explains buttons as you use them.

The app still has the normal stuff: visual commit graph, branches, partial/hunk staging, diffs, auto-refresh, push/pull/stash, etc.

I’m also planning a browser-based fake repo where you can learn Git by actually making commits, branches, merges, resets, etc. without touching a real project.

Basically, I want it to be a Git client you can use normally, but one that gradually teaches you Git instead of hiding it from you.

Would you use this? What would make you choose it over your current Git workflow?

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?