gitlab-simulation
gitlab-simulation is a Claude Code plugin under GitLab.com’s Public Sector group, written for GitLab team members. One skill carries two lanes: Contribute files an issue or opens a merge request against a GitLab project with no GitLab Development Kit on the laptop; Reproduce stands up self-managed GitLab on a throwaway Google Compute Engine VM, so a change runs on a customer’s install before it is filed. The contribute lane is the no-GDK contribution skill plus GitLab’s own gitlab-org/ai/skills vendored at a pinned commit.
just contrib dupchecksearches issues before a word is drafted; inconclusive fails closed.- Every
contribrecipe that would post writes a draft file and exits without a network call. - Only
publishposts, from a file no pre-approved recipe can name, after a yes to the exact text. - A docs-only change goes through the API with no clone; a code change uses a worktree of one canonical clone.
- A rig run is the evidence a report or merge request carries.
just lab uproutes throughlab.justintogce/simulation.sh, which shells out to gcloud to create, configure and destroy the VM.- caproni (k3s and Helm, the cloud-native chart) and omnibus (the Linux package, the only base that pins a version, and what Geo pairs) both run airgap and Duo Agent Platform flows; dev runs gitlab-org/gitlab source for RSpec, with no Gitaly.
- An airgap is denied at the GCP firewall and judged against a pre-seal baseline: one probe succeeds before the seal and fails after it, with GitLab still serving from the mirror.
multiplexer.pybridges to playwright-mcp inside the VM, so browser checks run headless on the cluster network.- Every run ends with
just lab down; GCE deletes the VM at its max run regardless, two hours by default and eight for a Geo pair.
The vendored skills, commit messages, merge request descriptions, pipeline watching and review among them, are declared in include.yml at one pinned commit that just vendor-check verifies; the commit, description, pipeline and review phases of a contribution hand off to them.
No base is both a running instance and a source checkout, as a GDK is; work that needs both goes to CI. A rig reproduces a customer install unless the run names the development lane.