Speeding up Checkmk development with the VS Code extension

Checkmk Dev&Exchange
1

If you’re hacking on the Checkmk source (plugins, GUI, agents, the works), you’ve probably hit the same wall everyone does: Checkmk builds with Bazel, and some packages (cmk-shared-typing, cmk-frontend, the Python venv) are generated at build time and simply aren’t on disk until you build them. That breaks the things you rely on in an editor — import resolution, type checking, test discovery — out of the box.

The repo ships a VS Code extension that bridges that gap. It lives right in the tree at .ide/vscode/, so it’s versioned alongside the code and stays in sync with the branch you’re on. (You’ll need a recent checkout — it’s on master and the 2.4.0 branch, not older releases.) Here’s what it does and how to get going.

What it gives you

  • Language profiles — one-click enable/disable of Python, UI, Rust and C++ tooling so you’re not paying for language servers you don’t need

  • Bazel build commands in the command palette and status bar (build the venv, shared-typing, frontend, etc.)

  • Stale-target detection — it watches the generated artifacts and tells you when something needs rebuilding (e.g. after a branch switch)

  • One-shot IDE setup — installs the right extensions and applies the right settings per language family

  • A sidebar dashboard — at-a-glance health (builds, settings, git, OMD sites) plus a Test Explorer that runs Bazel tests directly

  • OMD site management — start/stop/inspect your local dev sites without leaving the editor

  • Snippets & file templates for common Checkmk patterns (check plugins, special agents, rulesets)

Prerequisites

The extension drives the repo’s real toolchain — it doesn’t replace it. Before installing, make sure you have a working Checkmk dev environment:

  • A supported OS — Checkmk is developed on Ubuntu Linux (current or previous LTS). On Windows, use WSL2 (see below). macOS works but Linux is the primary target.

  • The repo — fork and clone it, then run make setup from the project root to pull in the development dependencies (this is optimized for Ubuntu).

  • Bazelisk — Checkmk builds with Bazel, and the version is pinned in .bazelversion (currently 8.5.0). Install Bazelisk rather than a fixed Bazel — it reads .bazelversion and grabs the right version automatically. Make sure it’s on your PATH (as bazel and bazelisk); all the build commands depend on it.

  • Docker — used by parts of the build/test flow; the extension’s Environment panel reports its version.

  • A C/C++ toolchain (gcc) — needed for the C++ bits and surfaced in the Environment panel.

  • pre-commit — pip3 install pre-commit then pre-commit install --allow-missing-config in the repo so your commits are checked the same way CI checks them.

  • VS Code itself, obviously. :slightly_smiling_face:

The sidebar’s Environment section gives you a live readiness check for most of these (Python, Node.js, Bazelisk, Docker, gcc) — a quick way to confirm your machine is ready.

Optional, for specific features

  • A local OMD site (omd + sudo) — needed only if you want the OMD Sites section to manage running dev sites.

  • cmk-dev-site (install via pipx) — enables the + Create Site button in the OMD Sites section.

  • socat — only needed if you use the OMD Socket Proxy (exposing livestatus/Redis/etc. as TCP ports).

  • libjemalloc2 — optional; powers the mypy-allocator memory optimization (sudo apt install -y libjemalloc2).

Getting started

1. Install the extension

From the repo root:


bazel build //.ide/vscode:vsix

code --install-extension bazel-bin/.ide/vscode/cmk-vscode.vsix --force

Then reload VS Code: Ctrl+Shift+P → Developer: Reload Window.

The extension also notices when the version on disk is newer than what you have installed and offers a one-click Rebuild & Install — handy after you pull.

2. Run IDE Setup

F1 → CMK ▸ IDE: Setup (Install + Configure) and pick the families that match your work (Python, UI, Rust, C++, …). The required Bazel and General families come along automatically. This installs the matching VS Code extensions and writes the workspace/user settings (Ruff, Pylance, mypy, Prettier, ESLint, clangd, etc.) so your editor matches what CI uses.

3. Build what you need

Check the status bar — a ✓ CMK means everything’s up to date, ⚠ CMK (2) means two targets are stale. Click it to build them. At a minimum:

  • Python work → Build venv

  • UI work → Build shared-typing + Build cmk-frontend

  • C++ work → Refresh C++ compile_commands.json

4. Verify

Open the Checkmk sidebar (activity-bar icon). The Environment section shows tool versions and build status; IDE Health confirms your settings and extensions are correctly configured.

A few things worth knowing

  • Language profiles save real memory. On the monorepo, Pylance and the mypy daemon happily grow into multiple GiB. Flip off the profiles you’re not using (the Py / UI / Rs / C++ buttons in the status bar), and the extension can even suggest toggling them based on which files you’re editing.

  • Tests run through Bazel straight from the Test Explorer — Python, Vitest, Rust and C++ — using the same hermetic versions as CI. No per-language test extension required.

  • It adapts to a community checkout automatically. The extension detects when you’re working in the open-source repo and adjusts itself: the CMK Tests runner is clamped to the community edition (and the commercial editions are dropped from the edition pickers), so bazel test never tries to reference enterprise targets that aren’t in your checkout. Internal-only workflow buttons (Gerrit push, the custom branch-checkout button) are hidden too, since community contributions go through GitHub pull requests. Nothing to configure.

  • Branch switches are handled — configs are loaded workspace-first, so switching branches updates them without rebuilding the VSIX, and stale build targets are re-detected automatically.

  • mypy memory tuning — there are opt-in features for running dmypy under jemalloc and for a dynamic-targets mode that roughly halves resident memory. Worth a look if dmypy is eating your RAM.

Windows users

The extension shells out to bazel, git, sudo, omd and socat, so it targets Linux (and macOS). On Windows, use WSL2 with the Remote – WSL extension: clone the repo inside the WSL2 filesystem (not under /mnt/c/...), open the folder with WSL: Open Folder in WSL…, and install the VSIX from a WSL shell. Everything — OMD management, the socket proxy, Bazel builds — then works in the real Linux environment.

The extension’s own README has the full feature reference if you want to go deeper. If you try it, I’d love to hear what works and what’s rough — feedback shapes where it goes next. :slightly_smiling_face:

4 Likes