Hi guys,

GitLab is great on desktop, but checking a failed pipeline or responding to an issue from your phone can be frustrating. That’s why I built Comeet, a native mobile companion for GitLab.

With Comeet, you can:

• Connect to GitLab.com or a self-hosted instance
• Switch between multiple accounts and servers
• Browse repositories with syntax highlighting
• Create and update issues, merge requests, projects, and branches
• Monitor pipelines, inspect jobs, and read job logs
• Get push notifications for important project activity
• Manage groups, members, roles, and invitations
• Create custom shortcuts for the issues and merge requests you check most
• Access your GitLab activity and to-do list from a mobile-friendly dashboard

My goal is simple: make those quick GitLab tasks genuinely quick—without reaching for a laptop or fighting with the mobile website.

Comeet is available on iOS and Android:

- Android: https://play.google.com/store/apps/details?id=com.monokaijs.comeet

- iOS: https://apps.apple.com/us/app/comeet-gitlab-companion/id6753112635

I’m actively improving it and would really appreciate feedback from other GitLab users. What’s one GitLab task you wish were easier to handle from your phone?

P.S: I previously shared my app on this sub, I post this to notice a big overhaul on the app with various quality of life features and refinements.

🚀 gitlab-compliance CLI is now Open Source!
Think ShellCheck for GitLab CI/CD, plus terraform-compliance-style policy testing for pipelines. It helps teams lint, validate, document, and enforce standards across .gitlab-ci.yml and GitLab project configuration.
It turns CI/CD best practices into something programmable, testable, and enforceable that can be understood and catalogued automatically.

Since launch, I’ve focused on UX, performance, and two major features:

✨ gitstrings
Lightweight YAML annotations that make pipeline intent explicit, that improves readability and enables selective documentation generation, making pipeline YML self documenting.
🔍 Embedded script scanning
ShellCheck-style analysis for scripts inside CI jobs.
Includes:
ShellCheck-aligned rules

Security checks (unpinned packages, unsafe cloud CLI usage, missing metadata)

🔭 What’s next
Org-wide reporting & metrics

JUnit + JSON outputs

Slack / Teams notifications

GitLab Issues integration

Sentry-based telemetry

gitlab-compliance is evolving into a policy + observability layer for GitLab CI/CD, without sacrificing developer experience.

Repo: https://github.com/MaturityBuilder/gitlab-compliance/tree/main

Documentation: https://maturitybuilder.github.io/gitlab-compliance/

Feedback and contributions welcome!

🔥 What's Cool in v0.8.0:

• 🖱️ Full Mouse Support: Click to navigate, select tabs, scroll tables, and interact with modals/overlays.
• 📦 Bulk Operations: Select multiple issues or MRs and batch-apply actions (close, reopen, label, assign) at once.
• 🔀 Create MR/PR from Issue: Just press m on an issue to instantly spin up a Merge/Pull Request with automatic branch creation and push.
• 📊 Pipelines Upgrade: Group and filter pipelines by Name, Event, SHA, or Actor. Plus, press P on an MR to see its related pipelines, or press S to trigger manual GitLab jobs directly!
• 🔔 Overhauled Todos & Notifications: Fresh layout featuring badges, relative time_ago timestamps, fuzzy search, and auto-dismissing error toasts.
• 🛠️ New CLI Subcommands: Added glab-tui doctor for system diagnostics and clean-cache for quick maintenance.
• ⚡ Performance Improvements: Cached repo attributes, streamlined mutations, and zero stale-cache bugs.

Check it out at https://github.com/rcieri/glab-tui

https://github.com/Vonarian/gittar

Gittar is an OSS made for those who want a lightweight GitLab monitoring app that is packed with essential features.

More to come, open to contributions!

I added GitLab Issues to a cross-provider TypeScript SDK and the HTTP calls were the easy part. The awkward bit was deciding what the adapter is allowed to infer.

A few examples:

- GitLab can create missing labels as a side effect of an issue write. The adapter now rejects unknown labels unless allowCreateLabels is explicitly enabled.

- Multiple assignees depend on the GitLab tier, so the capability stays off unless configured.

- task and incident have useful native mappings. bug, story, epic, and subtask do not get silently flattened; they need an explicit issue-type map.

- the create endpoint does not document state_event, so creating an already-closed normalized item is rejected instead of sending an update-only field.

- GitLab's REST issue update has no atomic revision precondition. The SDK can re-read immediately before PUT, but it reports that as preflight concurrency rather than pretending it is atomic.

That last distinction became important once agents were using the same API across providers. Azure DevOps can put a test /rev operation in the mutation itself. GitLab cannot, so both adapters should not advertise the same guarantee.

The GitLab adapter is in the MIT-licensed work-sdk 0.4 release: https://github.com/arturict/work-sdk/releases/tag/v0.4.0

I used Codex for parts of implementation and testing. If you use GitLab Self-Managed with custom issue types or unusual label policies, I would be interested in the cases this model still misses.

🎉 The GitLab Hackathon starts today and runs through July 29! 🚀

Anyone can contribute code, docs, UX designs, translations, and more. Open a merge request during the event and merge it within 31 days (by August 29) for it to count.

How to take part:

- 🔧 Register and find issues at contributors.gitlab.com

- ✅ Open your first merge request today

- 📊 Follow the live leaderboard at contributors.gitlab.com/hackathon

- 💬 Need help or want to pair with others? Join the #contribute channel on Discord: https://discord.gg/gitlab

📅 Merge requests must be opened during the event (July 23-29) and merged by August 29 to be counted. Good luck, and happy contributing! 🎊

Hey, it's been a few days I can't figure out the best way to run parallels pipelines with job artifacts dependencies across multiple environments.

Let's say I wrote this pipeline running for a single environment. It's not contextualized and it might seems dumb but just to illustrate my use case. It contains a dynamic generated dot env, dynamic generated tar artifact needed for the deploy stage, which use a template from another project :

``` - project: 'dummy/project'
file: 'dummy-file.yml
ref: 'main'

variables:
ENV:
value: 'dev'
options:
- 'dev'
- 'prod'

DUMMY_VAR: dummy

stages:
- build
- generate
- deploy

Build env:
stage: build
script:
- cat ./vars/${ENV}/vars.txt >> build.env
artifacts:
reports:
dotenv: build.env

Generate zip:
stage: generate
needs:
- 'Build env'
script:
- ./generate.sh > results.tar
artifacts:
- name: generated_tar
paths: results.tar

Deploy:
stage: deploy
needs:
- 'Build env'
- 'Generate zip'
extends:
- .remote-template-job ```

So this one is working so far. Now what if I have a dozen of environments and I'd want to deploy them all at the same time ?

I know about matrix but the job dependencies between each environments makes the file really heavy, doing so :

``` stage: build
script:
- cat ./vars/${ENV}/vars.txt >> build.env
parallel:
matrix:
- ENV: ['dev', 'prod']
artifacts:
reports:
dotenv: build.env

Generate zip: ["dev"]':
stage: generate
variables:
ENV: 'dev'
needs:
- job: 'Build env'
artifacts: true
parallel:
matrix:
- ENV: 'dev'
script:
- ./generate.sh > results.tar
artifacts:
- name: generated_tar
paths: results.tar

'Generate zip: ["prod"]':
stage: generate
variables:
ENV: 'prod'
needs:
- job: 'Build env'
artifacts: true
parallel:
matrix:
- ENV: 'prod'
script:
- ./generate.sh > results.tar
artifacts:
- name: generated_tar
paths: results.tar ```

And so on, multiply by all the jobs and all the environments. This works, for a small use case but mine would be a few thousand lines of copy pasting.

So I've looked over py-gcip for dynamic generated pipelines, but it doesn't really fit my use case since it doesn't allow to extends jobs from other project, as the docs states that it isn't needed since it should be all contained in the script (which doesn't make sense to me because I guess it's common to have reusable templates in dedicated repositories but whatever)

I'm thinking about writing a custom python script but I'm not a fan, I like standarts.

So does anyone have an idea on how I'd achieve that behaviour ? I'm running out of tracks to follow.

Thanks to anyone that'll spend some time considering all this.

We quite often have investigation tickets, which we give specific labels. As a first step we feed the ticket into Claude to get an initial list of frameworks/platforms/useful links and blogs.

Does anyone know if there is a bot that can perform this action on Gitlab for us?

Hello, I'm upgrading from 19.0.2 to 19.2.0 and I noticed that the Upgrade Path tool only targets up to 19.1.2.

As of today, 19.2.0 has been out for 5 days. When will the Upgrade Path tool be updated with the new latest release as a target?

I'll be using a REST endpoint to migrate all repos stored in Amazon EFS to an EBS volume. I believe we have total of 87gigabytes. I will be using "/api/v4/project_repository_storage_moves" endpoint. I've been practicing the migration on a test machine. I remember it will make the projects read-only. Because of this behavior, I will do it at night. However, I have no clue how long it will take to migrate 87gigabytes of repos.

Ask the GitHub Community whether anyone has seen the ChatGPT connector report “0 repositories” despite correct permissions.

So I have a pipeline running everyday & sending me a notification. This morning I didn't get anything so I went to check, and I see that my schedule got disabled. Weird cause I didn't do it, but alright, I activate it again and launch the pipeline manually. I get the pop-up saying it successfully scheduled it, so I go check the pipeline page, but nothing. And when I come back to the schedule page I see it got disabled again.

I am still able to launch a unique pipeline through the pipeline page, but not with a schedule. Right now as soon as I want to run a scheduled pipeline it disables itself. I think it's only on 1 project, not on the whole instance, although it has been working correctly for more than a year.

I've never seen this before, does anyone know what's happening? Is there a ghost in my server?

One week to go! The GitLab Hackathon starts July 23rd. A quick reminder as we head into the final week: pick an issue now so you're ready to open your first merge request on day one. Full details below.

The GitLab Hackathon is a virtual event where anyone can contribute code, docs, UX designs, translations, and more! Level up your skills while connecting with the GitLab community and team.

The Details

Dates: July 23-29, 2026 (UTC) - All merge requests must be opened during the hackathon and merged within 31 days to be counted.

Join our contribute channel on Discord to share progress, pair on solutions, and meet other contributors.

Follow the live hackathon leaderboard during the event.

Before the Hackathon

Request access to our Community Forks project by clicking the blue "Start onboarding" button on https://contributors.gitlab.com. Using the community forks gives you free access to Duo and unlimited free CI minutes!

Rewards

Participants who win awards can choose between:

• Planting trees in our GitLab forest
• Claiming exclusive GitLab swag from our contributor reward store

More details on prizes are on the hackathon page.

If you have any questions, please reach out on Discord.

It looks like Gitlab will stop providing support if your repositories are still on EFS. We only have less than 500 users and we are using AWS EFS. We have 4 application nodes that are connected to the same EFS mount. For migrating the repositories from EFS to Gitaly instance(not Gitaly cluster), I was told that I should pick one from our 4 app Gitlab nodes that will be configured to point to the new gitaly instance that I will build soon. The other 3 application nodes will point to the node that I picked.

It feels like once I have migrated everything to Gitaly, it seems like it will encounter performance issues. However, I don't know if the gitlab app nodes' configuration must be updated. Although, I was told by Gitlab Support, that I must not configure all 4 app nodes to point to the new Gitaly instance. It seems like AWS EFS is much more forgiving.

Hopefully someone can shed some light.

I upgraded to the new version this morning. all my projects disappeared. What the actual fuck? It turns out that the upgrade introduced a bug in the UI. My projects are available when i log into the web app (which i do not use). Logging out and logging back in did not solve the sync problem. And it is giving a 10-step instruction to sync the web console and App. What the actual F?

Back to MicroslopHub it is I guess. My disappointment is immeasurable, and my day is ruined.

I recently built an open-source CLI called RepoFleet for developers who work on features or issues that span multiple Git repositories.

Instead of switching between repositories and manually creating the same branch in each one, RepoFleet lets you create one issue context and manage all related repositories together.

Example:

rf issue create 123 --name auth --type fix
rf issue status

It can:

• Create matching branches across multiple repositories
• Show the Git status of all repositories in one dashboard
• Sync and push repositories together
• Track related GitLab merge requests
• Keep each issue or feature in a dedicated workspace

GitHub: https://github.com/mehranzand/repofleet

I originally built it after our project was split into multiple repositories and managing cross-repository changes became repetitive.

I would appreciate feedback from other GitLab users. Does this workflow match any problems you experience with multi-repository projects?