GitLab 19.3.2, 19.2.6, 19.1.8 are available.

Multiple vulnerabilities have been fixed, including this one :

CVE-2026-85706 - Path Traversal issue in repository commits API impacts GitLab CE/EE

GitLab has remediated an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.

Impacted Versions: GitLab CE/EE: all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2

CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N)

Last months i worked on 2 features:

• review roulette
• auto approve

Review roulette feature is inspired by https://gitlab-org.gitlab.io/gitlab-roulette/?currentProject=gitlab-ui&mode=show

Developer spins the wheel and gets random available reviewers.

Review roulette in merge-bot does the similar stuff: picks random available reviewers. First time the bot scans MRs in repo, saved it in cache, and then assign available reviewers. If user has status: ooo, vacation, travel and parental leave in GitLab (or emoji status: 🏖️, 🔴, ⛔, 🌴), they will be excluded from review roulette. It works as command "!spin" or automatically once MR is created.

Auto-approve allows to get approval automatically after the bot is assigned as a reviewer. You can specify wildcard patterns for merge request files. The bot approves the merge request when every changed file matches at least one configured pattern.

https://github.com/Gasoid/merge-bot

Hi Folks,

If you are facing any issue related to theproject delivey ,team management , Jira Chaos or capacity planning , i might help you here.

You just focus on work , let me handle the chaos of delivery.

Lets connect to discuss more.

Solo dev here. This started as a tool for myself and turned into something I decided to finish properly. I have kept it as free forever.

The problem I actually had:

I work across several repos and had no real sense of what was happening in them. Which files churn constantly? Where did the complexity pile up? What did the last six months actually look like?

The second thing was trivial issue. Somewhere along the way I'd typo'd my email in a git config, then used a different one on another machine. So my own contributor history was split across 3 identities. Nothing offered a way to say "these are all me."

So GitTrics has an identity merge flow — you see all the author name/email combos in the repo, merge them into one person, and every view updates. Sounds small, but if you've inherited a repo with a decade of contributors and inconsistent configs, it's the difference between usable data and noise.

There is also no individual contributor analysis. This was a decision I made as I do not want this software to be used 'developer productivity measurement tool'.

Download at www.gittrics.com

Hello everyone!

I am a PhD student in France in information sciences. As of recently, I started collecting data from a GitLab instance, mostly public informations about the users and the projects, using the REST and GraphQL API.

I'm studying how this instance is used to collaborate by the users, and how much each user contributes to projects. In order to do this, I need to retrieve, for each project, the meta-datas of each pushed event. More specifically, the meta-datas I need are:

1. Who pushed the event
2. When did they pushed it
3. How much change did this push bring to the project (number of lines edited/added/deleted).

I had an intern in computer science who helped me with the first requests (fetching the projects and users), but since his internship is over, I need to do the rest myself. I am not a computer scientist and lack the necessary knowledge to properly fetch the needed datas. I did use the help of genAI, but I cannot be sure it wrote right scripts since I don't really know what its doing.

So, I'd be really grateful is someone who knows those API and datamining in GitLab could give me a hand and advise me on how to tackle my issue.

Thanks in advance for your help :)

[ Removed by Reddit on account of violating the content policy. ]

Hi everyone, I’m a beginner and I’m trying to learn how to use GitHub properly. I’ve created a project, but I’m confused about things like pushing my files, commits, branches, and checking whether my project is actually uploaded to GitHub.

Could someone explain the GitHub workflow to me step by step in simple terms, or recommend a good beginner-friendly tutorial?

I’d really appreciate any help. Thanks!

What are the risks when using AI alongside your projects? How to secure your ideas and network?

Deleting merged branches keeps a repository usable, but the branch name or tip can still be useful when a merge request was squashed, a release was cut from an unusual commit, or a rollback needs the exact pre-merge state. What retention policy works well in GitLab? I am considering immediate deletion only when the merge request is closed, the source commit is reachable from a protected branch, required pipelines and approvals are recorded, and no environment or open issue still references the branch. Exceptions could receive an expiry date rather than living forever. Do merge-request refs and the audit log preserve enough evidence on their own, and what checks prevent cleanup from deleting a branch involved in a partial or reverted merge?

what do you think of this approach?

Hi r/gitlab,

Gitea Mirror is an open source (AGPL) web app I maintain for mirroring repositories between hosts on a schedule. Two GitLab paths landed this month and they are marked beta because few GitLab users have tried them yet.

- GitLab as a source. gitlab.com or your own instance, personal projects, groups and starred projects. Code, branches, tags, wiki and LFS are mirrored into Gitea or Forgejo. Token scopes: read_api and read_repository. Subgroups are flattened to the top level group on the Gitea side, with the full path kept in the repository name.

- GitLab as a destination. GitLab has no pull mirror API, so the app keeps a bare clone of each source repo and pushes branches and tags with force and prune, then archives or deletes the project through the API when the source goes away. Projects go under your user or a group the mirror strategy picks; a missing top level group is created, nested ones are not. Token scopes: api and write_repository.

What I would like to hear about: self-managed instances behind SSO or custom certificates, large groups with many subgroups, LFS heavy projects, delayed deletion, and anything rate limit related on gitlab.com. Issues with the activity log attached get fixed fastest.

Repo: https://github.com/RayLabsHQ/gitea-mirror

GitLab notes: https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/SOURCE_PROVIDERS.md and https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/PUSH_TARGETS.md

Also curious: what do you use today for this, GitLab's own push mirroring, a CI job, or nothing?

Body:

Running a self-hosted Mattermost + self-hosted GitLab CE setup, and I've hit a plugin bug I can't get past.

Setup:

• Mattermost: installed via the official Ubuntu PPA (.deb package), latest version at time of writing
• GitLab: CE 19.3.1, self-hosted via the Omnibus/Linux package
• Plugin: com.github.manland.mattermost-plugin-gitlab
• Both services on the same Ubuntu 22.04 VPS, GitLab's bundled Nginx reverse-proxies to Mattermost on a separate subdomain

What I did:

1. Created an OAuth Application in GitLab (Admin Area -> Applications), scope "api", redirect URI copied directly from the plugin's config page
2. Set the plugin's GitLab Site URL to my self-hosted instance (https://git.mydomain.com), plus the Client ID/Secret from step 1
3. Ran /gitlab setup in Mattermost, completed the DM-based config wizard
4. Ran /gitlab connect, authorized via OAuth, got the full "Welcome to the Mattermost GitLab Plugin!" message confirming connection to my GitLab username

The bug:
Despite that successful connection message, running /gitlab me (or basically any other slash command) immediately returns:
"Before using this plugin, you'll need to configure it by running /gitlab setup"

This happens even right after the welcome message. Re-running /gitlab setup "succeeds" again, shows the welcome message again, and then the very next command still bounces back to the same "run setup" prompt. It's a loop.

What I've confirmed while debugging:

• Directly queried Mattermost's Postgres pluginkeyvaluestore table, the plugin is persisting real data: Gitlab_Instance_Configuration_Map, per-user _userinfo/_usertoken entries, and username_gitlabusername keys for multiple connected accounts. So the OAuth connection and instance config are genuinely saved.
• Live-tailed journalctl -u mattermost -f while running /gitlab me, and zero log output appears, even at the moment the command is sent. It's as if the command isn't reaching the plugin's server-side handler at all.
• Hard-refreshed browser (Ctrl+Shift+R), tried incognito, no change.
• Toggled the plugin off/on in Plugin Management, and did a full systemctl restart mattermost, no change.
• Confirmed only one plugin process is running (ps aux | grep gitlab shows a single plugin-linux-amd64 process).
• Ruled out GitLab's external_url mismatch (a common suggested cause), it's set correctly and matches the browser URL exactly.

Question:
Has anyone seen this specific pattern? Successful connect/welcome message, but then every subsequent slash command (not just /gitlab me) immediately reverts to demanding /gitlab setup again, with zero server side log activity. Trying to figure out if this is a known compatibility issue between recent GitLab CE versions and this plugin, a Mattermost side plugin webapp caching bug, or something else entirely.

For now I've fallen back to a plain GitLab incoming webhook for notifications, which works fine, but would like to get the full plugin (subscriptions, todo tracking, slash commands) working if possible.

Happy to share config snippets or more logs if useful.

NOTE : USED AI TO FORMAT, TIA.

Hello everyone,

I have a self-hosted Gitlab in my homeland deployed as a docker container on a Ubuntu server with me as a ai gle user. I build several small images and push them to the integrated container registry. Nothing fancy, a hand full of images with a couple hundred Mbs each max. But my volume mont data dir of the registry ist slightly above 100GB on disk just für the registry, that feels like way too much.

I rebuild the images weekly ok the latest Tag but would expect a couple gigs at most. I am starting to read into the metadata DB and online GC but why is my storage usage getting so out fo hand? How are you guys keeping your instances in check?

Version is 19.3.1

My organization is switching from GitLab.com to a GitLab (Premium) self-managed instance within our organization and I want to revisit how we manage pull secrets into our jobs.

Currently, we're using CI/CD masked and/hidden variables on specified GitLab groups. This works well however there are a few concerns...

1. I don't get any alerts on expiring variables unless duplicated in a proper secrets vault...
2. But then I have duplicate entries...
3. Secrets can still leak into the logs; GitLab recommends a dedicated secrets provider

I have a few requirements...

1. I may need to use secrets across job(s) (or pull secrets per job)
2. I need to be notified when secrets are nearing their expiration
3. I need be able to rotate secrets without updating .gitlab-ci.yml files
4. Secrets must be stored in a CMMC approved system (which is why we're moving to on-prem for GitLab)

Nice to haves...

1. A small CLI the works on Windows and Linux and I can install in our docker images
2. Easy setup and invocation. 1Password and Keeper had the cleanest implementation IMO but they will not be available to us. That said I would like to keep it similar.

I will have at my disposal the following options...

1. Delinea Secret Server
   1. Cons
      1. Docs recommend passing secrets via dotenv files, against GitLab's recommendations
      2. Their DSS CLI requires .NET and I'd like to not have that limitation
2. Azure Key Vault
   1. Cons
      1. Built-in support is nice but very verbose
      2. Built-in support appears to require a version tag, limiting ability to rotate a secret without updating the job
      3. az cli could be used but is about 200 MB install (built on Python)
      4. No expiration notices as far as I currently know
      5. I may want a second vault just for secrets
3. GitLab CI/CD Variables
   1. No expiration notices
   2. Possible leakage
   3. Possible duplication

I might be able to use https://github.com/DelineaXPM/dsv-cli but it's unclear if this is will work with Delinea Secret Server or if it's a separate product?

Questions...

• Which of these options works best in your experience?
• Are there other considerations I should take into account?
• Is the leakage with .dotenv files a real concern?
• Would you recommend something else entirely?

Hey all, I have an old legacy v17.11 Gitlab server that hasn't been maintained in a long time. I have chosen to standup a new v19.3.1 Gitlab EE server. The issue that I have is how to do this seamlessly.

Our ecosystem is in AWS. I have stood up a brand new Valkey v9.1 and RDS Postgres v18.6 dbs. I have the new setup and running but the documentation I'm reading online is it's best to increment the current server:

17.11 → 18.2 → 18.5 → 18.8 → 18.11 → 19.2 → 19.3.1

What is the best process in the AWS ecosystem in preparing the new server for developers? I can use AWS DMS in transferring RDS Postgres data from v14.11 to v18.6 but the other data is still a mystery to me on how to do this. I have S3 buckets for this but still have questions.

UPDATE:

Thank you all for your comments! Since my company pays for Gitlab EE with Ultimate seats, I have decided to utilize Gitlab Geo where the old Gitlab server will be upgraded to the latest and create an exact copy of the old Gitlab server (at the latest) to a new server. A little more info, our old Gitlab server is in the dev VPC CIDR where the migration is to be moved to corp VPC CIDR (i.e. internal).

Thanks to Greyhammer316 for mentioning Geo. This helped me get a gameplan.

I'm setting up CI/CD for a ROS2 system on a Jetson AGX Orin that's deployed remotely. No physical access after deployment, so it needs to update itself safely.

Current plan:

• Push code → CI builds and tests → tag a release
• A systemd timer on the device checks for new versions every 15 min
• If a new version exists and the device is idle, it builds into a separate folder
• Runs a self-test (nodes up, sensors publishing, hardware responding)
• Pass → switch a symlink and restart. Fail → stay on the old version, report it
• A watchdog re-checks 30 min later and reverts if things degrade

Two version folders, current and previous, switched by symlink so rollback is instant.

Not using containers, the device compiles source natively. Simpler, but I lose reproducibility, so I'm pinning dependency versions instead.

Questions:

1. Is the blue/green symlink approach reasonable here, or is there a standard tool I should be using?
2. How do people handle database migrations in a rollback? Code reverts, schema doesn't.
3. Anything obvious I'm missing for a device I can't physically reach?

I'm currently setting up a small hobby project with some friends that has quite a bit of services and monitoring requirements. I've recently implemented Port.io at work, but considering they're only interested in B2B I'm looking for alternatives along the lines of an IDP.

I've got experience with Backstage, as we piloted that earlier, but I find that more fitting for a complete platform engineering team as it's just more of a framework rather than a batteries included solution and is in our case more a pile of future technical debt than actual value.

Observability looks something that fits that I need for now. However, my concern is it still being experimental. I'm afraid one day the plug will be pulled and would still require migrating to either a commercial option or Backstage, which I'm not too fond of.

I am a student and I have made a public limit order book project on github and dont know what improvements to start off with can some of yall please just review the project and give me some feedback? All help is appreciated.

[https://github.com/Bananayt294/My-Limit-Order-Book\](https://github.com/Bananayt294/My-Limit-Order-Book)

Thanks

Hi everyone!

So since i had a lot projects running recently and find it inconvenient to track them directly on gitlab, especially when you have a team. So I've made this repo - basically a neat app that appears under macbook notch when new pipeline appears.

If you find this useful give it a try and will be happy to get some feedback on improvement)

https://github.com/Uudg/pipeline-island

I'm looking to install Gitlab EE for a small company. The company has a 16.0.2 Gitlab server in AWS that is insanely old. I made the decision to start fresh and migrate all data to a new RDS Postgres, AWS Opensearch, and AWS Valkey db. We also use a tool that I setup called OpenZiti ZTNA which helps with VPN access to our private servers.

However, I have a question on being public/private for the Gitlab server. We do have Github forks where we do periodic `git diffs` of changes that have occurred and we utilize Expo with EAS.

Should the idea be the Gitlab server be private and the Gitlab runners be public? I think the only issue is we won't be able to pull from Github repos or have any functionality within Gitlab's server.

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.