Documentation

Introduction

CheckoutAndBuild keeps any number of solutions and projects up to date with one click: it pulls the latest changes, restores packages, builds and tests — out of process, in parallel, before you even open the code. Think of it as a small CI server that lives inside your IDE and works on your local working copies.

It ships as two products built on the same idea:

• Visual Studio extension — the full experience for .NET (and Delphi) teams: pipeline, git cockpit with worktrees, dependency-based build order, Error List integration, MEF plugin API and Azure DevOps tools. Requires Visual Studio 2022 or 2026 (amd64).
• JetBrains plugin — one plugin for Rider, IntelliJ IDEA, PhpStorm, WebStorm, GoLand, CLion & co. It detects .NET, Gradle, Maven, npm, Composer, Cargo and Go projects and runs the same pull → install → build → test pipeline.

Installation

Visual Studio VS

1. Install from the Visual Studio Marketplace, or download the latest .vsix and double-click it.
2. Restart Visual Studio.
3. Open the main window via View → Other Windows → CheckoutAndBuild. The git cockpit lives in its own window: View → Other Windows → CheckoutAndBuild Git.

JetBrains IDEs JetBrains

1. Download the latest plugin .zip.
2. In the IDE: Settings → Plugins → ⚙ → Install Plugin from Disk…, pick the zip, restart.
3. Open the CheckoutAndBuild tool window at the bottom of the IDE. It has four tabs: Pipeline, Git, Worktrees and Work Items, sharing one console.

Quick start

1. Add working folders. Point CheckoutAndBuild at the directories that contain your repositories. Solutions and projects are discovered automatically (the JetBrains plugin starts with the folder of the open project).
2. Review the list. Every discovered solution/project appears as a row. Untick what you don't want, set priorities if build order matters.
3. Pick the steps. Toggle the pipeline steps you want (e.g. Pull, Restore/Install, Build, Test).
4. Press CheckoutAndBuild. Watch the progress, elapsed time and ETA. Failures turn red; use Retry failed to re-run only what broke.

Running a pipeline

A run executes the enabled steps for every included project. Pull runs once per distinct git repository (not per project), then the remaining steps run per project, grouped by priority. All output is streamed live into the console/output pane, and every process runs outside the IDE — a hanging build can always be cancelled and never freezes the IDE.

• Live status & ETA — each row shows a spinner and its current step; the progress bar estimates remaining time from recorded durations of previous runs. Progress also appears on the taskbar icon.
• Fail fast — optionally stop scheduling further priority groups as soon as something fails.
• Retry failed — after a run with failures, one click re-runs only the failed projects.
• Filter — the filter box narrows the list live (regex allowed); the context menu of a row can run single steps for just that project.
• Notifications — when the IDE is in the background you get a toast/balloon when the run finishes.
• Changed only — after the pull, skip install/build/test for projects whose repository received no new commits. One changed repo out of ten means one rebuild, not ten.
• Watch mode — fetch all repositories on a configurable interval and run the pipeline automatically when one is behind. Combined with “changed only” this turns CheckoutAndBuild into a quiet background CI.
• Auto-stash — uncommitted changes are stashed automatically around pull and branch checkout and restored afterwards; a conflicting restore keeps them safely in stash@{0}.

In Visual Studio the pipeline additionally offers Clean, NuGet restore modes, a merged build (build several solutions as one), Delphi projects and MEF plugin services. Build errors and test failures land in the Error List; double-click jumps to the code.

Profiles

Profiles capture a complete working setup: which projects are included, their priorities, step toggles and per-project command overrides. Switch profiles from the toolbar; create, rename and delete them from the Tools menu. Typical use: a “Frontend” profile with npm projects only, a “Full” profile with everything, a “Hotfix” profile with one solution.

In Visual Studio, settings can also follow the current branch, and profiles can be exported, imported and copied (JSON under %AppData%\COAB). The JetBrains plugin stores its state in the IDE configuration and offers settings export/import as JSON via the Tools menu (the Azure DevOps token is never exported).

Priorities & parallelism

Every project has a numeric priority. Lower priorities build first; projects with the same priority build in parallel (the degree of parallelism is configurable). This models dependencies: put base libraries at priority 0, dependents at 1, and so on.

Suggest priorities scans .NET solutions and projects for project and package references and proposes a correct build order automatically (cycle-safe — reference depth becomes the priority).

Per-project settings

Right-click a row → Project Settings… to override the command line of each step (install/build/test) for that project — per profile. Empty fields fall back to the defaults of the project type (shown as tooltip). The context menu also offers:

• Run a single step for one project (e.g. only Build).
• Start/Stop application — launches the newest built executable of the project, stops it again including child processes.
• Open project in a new IDE window, open the folder in the file manager, copy the full path.
• Include/exclude and priority editing; custom projects added via Add Project… can be removed again.

Visual Studio additionally supports per-solution build properties/targets, thread priority, log level and “kill dependent processes before build”.

Project types JetBrains

The JetBrains plugin scans working folders (configurable depth; node_modules, bin, target etc. are skipped). The first match wins per directory — a folder with a solution file is treated as .NET and not descended further. Default commands per step:

Wrapper scripts (gradlew, mvnw) are preferred automatically when present. Every command can be overridden per project (see per-project settings). The Visual Studio extension builds solutions with msbuild, runs tests via vstest and also supports Delphi projects.

Scheduled run & script export

Scheduled run (morning build)

Enable the scheduled run and set a time (e.g. 07:30). If the IDE is open at that time, CheckoutAndBuild starts the full pipeline once per day automatically — your codebase is built and tested before you grab your coffee.

Export as script

Export the current pipeline (included projects, priorities, effective commands) as a PowerShell (.ps1) or batch (.bat) script — useful for running the identical sequence on a machine without the IDE, or as a starting point for a real CI job.

Git cockpit

The git area shows all repositories found beneath your working folders with branch, ahead/behind state and dirty count. From there:

• Changes — inspect uncommitted changes; in Visual Studio with real IDE diff against HEAD, stage/unstage/discard per file and file history.
• Commit & push — commit all changes with a message and push in one go; an upstream is set automatically when missing.
• Stashes — create, apply, pop and drop stashes; view the stash diff.
• History — the latest commits, filterable by author (“only mine”), message text and, in Visual Studio, by file path and age.
• Patches & zip — export uncommitted work as a .patch file or as a zip of all changed files (with folder structure); apply patches with 3-way merge.
• Create pull request — opens the PR creation page of GitHub or Azure DevOps for the current branch, derived from the remote URL.
• Branch suggestion — type an Azure DevOps work item ID and get a branch name like feature/1234-fix-login-crash, created and checked out on confirm.
• Commit message from work item — prefill the commit message as AB#1234: title (the id is guessed from the branch name); the AB# syntax links the commit to the work item in Azure DevOps.

Multi-repo sync

Working across many repositories at once:

• Fetch / Pull / Push all — one click for every repository; per-row actions are available too, including force push (with lease, after confirmation).
• Checkout everywhere — check out the same branch in all repositories, optionally creating it where it doesn't exist.
• Cleanup merged branches — lists local branches already merged into the default branch and deletes them after confirmation.

Worktrees

Git worktrees give you several working copies of one repository — one folder per branch, no stashing or branch switching needed. CheckoutAndBuild manages them per repository. New worktrees follow the sibling convention <repo>-<branch> next to the repository (the path is editable in the dialog).

The worktree list

Every worktree shows its branch, commit, a sync badge (✓ up to date, ↑n ahead / ↓n behind its upstream, or “no upstream”), a dirty badge (● n uncommitted changes) and flags: main, locked, prunable, detached.

Actions

• Add — pick an existing branch (checked out into the new folder) or type a new name (created with -b). Branches already used by another worktree are hidden. Optionally run install + build right after creation, so the new worktree is ready to work in.
• Pull / Push — sync a single worktree; push sets the upstream automatically when missing.
• Update from base — fetches and merges origin/<default branch> into the worktree, keeping feature worktrees current without leaving your main checkout.
• Switch branch — check out a different (or new) branch inside the worktree.
• Remove — deletes the worktree folder; optional force (with uncommitted changes) and “also delete branch”. The main worktree is protected.
• Prune — drops stale bookkeeping for folders deleted outside of git.
• Find orphans — detects sibling folders whose .git file points to worktree metadata that no longer exists (broken leftovers) and deletes them after confirmation.
• Open — open the worktree's solution in a new Visual Studio instance VS, open it as a project in the IDE JetBrains, open the folder, or add the worktree as a working folder so it takes part in the pipeline.

Azure DevOps work items

The Work Items area talks directly to the Azure DevOps REST API. Enter your organization, project and a Personal Access Token (scope: Work Items Read & Write). The token is stored securely — DPAPI-encrypted in Visual Studio, in the IDE PasswordSafe in JetBrains — never in plain text.

• Query — run a WIQL query (a sensible default is provided) and browse the results; double-click opens the work item in the browser.
• Search & replace — search a text across work item fields (title, description, repro steps, acceptance criteria), preview the matches per field, then replace across all matched work items in one operation.
• New work item — jump straight to the creation page in the browser.

Visual Studio vs. JetBrains

Both products share the pipeline, git tools, worktree manager and work item tools. Differences come from what each IDE platform offers:

FAQ & troubleshooting

Nothing is discovered in my working folder

Check the scan depth (default is a few levels) and note that ignored folders (bin, obj, node_modules, target, …) are never descended. A folder that matches a project type is not searched further — nested projects inside a solution folder are intentional. You can always add a project manually via Add Project….

The sync column says “no upstream”

The branch has no tracking branch on the remote yet. Push once — CheckoutAndBuild pushes with -u origin <branch> automatically, after which ahead/behind is shown.

Git commands fail although git works in my terminal

The IDE process must see git on its PATH. If you installed git after starting the IDE, restart it. On Windows, check that git.exe is in the system PATH, not only in a shell profile.

Where are my settings stored?

Visual Studio: JSON under %AppData%\COAB (portable, export/import in the UI). JetBrains: in the IDE's configuration directory. Azure DevOps tokens are stored encrypted in both cases and are never part of exported settings.

Which versions are supported?

Visual Studio 2022 and 2026 (amd64). JetBrains IDEs from 2024.2 in every product (Rider, IntelliJ IDEA, PhpStorm, WebStorm, GoLand, CLion, …). The classic extensions for VS 2013/2015/2017 remain available on the marketplace unchanged.

Something is broken / I have an idea

Please open an issue on GitHub — ideally with the console output of the failing run.