Watching a GitLab Project the Same Way You'd Watch a GitHub Repo
GitLab teams get the same real integration GitHub teams already had — kept as its own parallel path, and keyed on the id that doesn't move.
If your team runs on GitLab instead of GitHub, you've probably learned to read "integrates with your repo" in developer-tool marketing as a synonym for "integrates with GitHub, and maybe you too, eventually." It's a reasonable assumption — GitHub-first tooling silently excludes a large, real segment of teams often enough that GitLab shops have learned to check before they believe a generic "Git integration" claim. Piskes's answer here is a real, working GitLab install path, not a maybe.
A parallel table, not a bolted-on afterthought
The GitLab integration isn't implemented as a special case squeezed into the existing GitHub install logic. It's a parallel table, structured deliberately to mirror the GitHub one, with a single writer responsible for it — a pattern the platform follows on purpose whenever two integrations look similar on the surface but are genuinely different systems underneath. Treating them as the same table with a "provider" column would have been the easier build and the worse one.
One detail is worth calling out specifically: the GitLab install is keyed on GitLab's own numeric project id, not the project's path. That's not an arbitrary implementation choice — a GitLab project's path can change when the project is renamed or moved to a different group, but its numeric id doesn't. Keying on the id means a rename or a group move doesn't quietly break the connection between your GitLab project and the agent watching it. Keying on the path would have looked identical in a demo and broken the first time a real team reorganized their GitLab namespace.
Why this is a real parity announcement, not a headline feature
This isn't a splashy new capability — it's closing a gap that GitLab-only teams had real reason to assume existed. If you evaluated Piskes before and dismissed agent-repo integration because your team is on GitLab, it's worth another look. And if you're currently choosing between platforms specifically because one of them plausibly ignores your Git host, that's no longer a reason to rule this one out.