Frequently Asked Questions

This FAQ answers common practical questions. For a thorough, implementation-level reference — how the runners are built, how the worker containers launch headless LabVIEW, how VIPM dependencies are baked in, the report data contracts, the catalog model, the security boundaries, and how to extend or adapt the stack — read the full Documentation.

It is written for expert LabVIEW developers who need to evaluate, extend, or adapt the pipeline.

LabVIEW CI is a portable, repository-agnostic CI/CD pipeline for LabVIEW projects. It provides:

• Mass Compile — build all VIs and check for compilation errors
• VI Analyzer — static analysis for code quality
• VIDiff — compare versions of VIs
• VI Browser — browse and search VIs by commit history
• Status Dashboard — unified view of all pipeline results

It's driven entirely by a catalog so the configurator UI and installer stay in sync — new capabilities are just a one-entry change.

Click ➕ Apply to New Repo from the dashboard. This will:

1. Ask which LabVIEW version and platforms your repo uses
2. Let you select which capabilities you want (Mass Compile, VI Analyzer, etc.)
3. Generate an install command to run in your repository
4. Create a pull request with all the necessary workflows and configuration

You review and merge the PR to activate the pipeline.

Yes! Click ⚙ Configure Workers from the dashboard to change:

• LabVIEW version
• Target platforms (Windows, Linux, or both)
• Which capabilities run (enable/disable Mass Compile, VI Analyzer, etc.)
• Maximum concurrent runners
• VIPM package dependencies and container settings

Configure opens a pull request with your changes — review and merge to apply.

Worker containers are Docker images that bundle your project's dependencies (VIPM packages, etc.) with LabVIEW. They ensure that every CI run uses exactly the same environment.

From Configure, you can:

• Select which prebuilt container image to use (Latest for always-current, or pin a specific build)
• List VIPC dependency files baked into the container
• Enable "Monitor" on a VIPC so the container rebuilds automatically when that file changes

VI Analyzer, Mass Compile, and VIDiff run inside the container you select.

Short answer: a fresh container is created for each action, each revision, and each platform — started when that action begins and destroyed the moment it finishes (docker run --rm). A container is not created per file, and it is never reused across actions or across revisions. This keeps every run clean, isolated, and reproducible.

What that means in practice:

• Across files in one revision — shared. When an action runs (say Mass Compile), it starts one container and processes every VI in that revision inside a single LabVIEW session, then tears the container down. You never get a container per VI.
• Across actions — not shared. Each capability (Mass Compile, VI Analyzer, VIDiff, Unit Tests, Antidoc) is its own workflow on its own runner. A push that triggers three actions spins up three separate containers — more if both Windows and Linux are enabled — each created and destroyed independently, usually in parallel.
• Across revisions / commits — not shared. Every new commit triggers fresh workflow runs and therefore fresh containers. Nothing carries over from the previous revision.
• The image is reused; the container is not. The prebuilt worker image (with your baked-in VIPC dependencies) is pulled once per job and cached on the runner, but each job runs a brand-new container instance from it and discards that instance when the job ends. Your repository files are bind-mounted in from the runner, so nothing changed inside a container is ever persisted.

The one exception — VI Browser snapshots. The snapshot renderer deliberately starts a single, long-lived container and keeps it warm, rendering many commits through it via docker exec (no per-VI or per-commit container churn), then tears it down when the job ends. Snapshots are content-addressed by VI content, so each unique VI is rendered exactly once — ever — and reused across commits instead of being re-rendered.

What you can change:

• Which image each container runs. Open ⚙ Configure Workers; on the Container tab choose Latest (always current) or pin a specific immutable build. The Per-action routing section lets you override this per action — for example pin VIDiff to a frozen build for stable rendering while Mass Compile tracks Latest; base forces the bare NI image for that action.
• When the image rebuilds. Bake VIPC files into the image and turn on Monitor so it rebuilds and re-pushes automatically whenever a dependency file changes — or trigger a rebuild on demand. This changes the image that future containers start from; it does not make a container persist.
• Where containers run. Point an action at a custom / self-hosted runner. On a self-hosted runner the machine and its Docker layer cache persist between jobs, so the multi-gigabyte image isn't re-pulled every run — but each job still runs a fresh --rm container. GitHub-hosted runners start from a clean VM every job.
• How many spin up at once. Lower the max concurrent runners cap so a busy push doesn't start many containers at the same time and exhaust your account-wide Actions concurrency limit.
• How many spin up at all. Enable or disable capabilities and choose Windows, Linux, or both, to control how many containers each submission creates.

There is no setting to make a single container persist across actions or across revisions — that isolation is intentional. The VI Browser snapshot renderer is the one place that reuses a warm container within a job, and it avoids repeat work across revisions by content hash rather than by keeping containers alive.

Stored in the GitHub Container Registry (GHCR, ghcr.io) as a package attached to your repository. The "Build LabVIEW CI Image" workflow builds your worker image and pushes it with the built-in GITHUB_TOKEN, so the image lives under your own account — for example ghcr.io/<owner>/<repo>-labview (and, if VI Browser 2.0 renders are enabled, ghcr.io/<owner>/<repo>-toimages). The image inherits your repository's visibility, and you can view or delete it under your repo's Packages. The NI base layer it builds on (nationalinstruments/labview) is pulled from NI's public registry — nothing is stored on the tooling author's servers.

Run on the GitHub Actions runner that executes the workflow job, never on NI's or the tooling author's infrastructure. For each job the runner:

• Pulls the image from GHCR (authenticating with the job's GITHUB_TOKEN), or from NI's registry for the base image.
• Starts a fresh container with your repository bind-mounted in, runs LabVIEW headless inside it, and writes the results back out.
• Destroys the container when the job ends (docker run --rm), so nothing persists between runs.

Windows container jobs run on a windows-2022 runner and Linux jobs on ubuntu-latest — either GitHub-hosted (the default) or a self-hosted runner you provide. In short: the images are your own packages on GitHub, and everything executes inside your own GitHub Actions environment, under your account's minutes and limits.

The dashboard shows an "Update available" badge when a new version of LabVIEW CI is released. Click Update now to:

• Review what changed in the new version
• Generate an update command
• Create a pull request that updates your pipeline to the latest version

Merge the PR to get the new features and improvements.

LabVIEW CI supports:

• Windows — GitHub-hosted runner or custom runner
• Linux — Mass Compile and select capabilities run on Linux via container

You choose which platforms your pipeline targets during setup or from Configure.

LabVIEW CI itself is free and open-source. Running CI on GitHub costs:

• Public repositories: free (unlimited Actions minutes on GitHub-hosted runners)
• Private repositories: counts against your GitHub Actions minutes quota (2,000/month included on Free, 3,000/month on Pro and Team)

You can lower the max concurrent runners to stay within quota. Keep in mind that GitHub's concurrency limit — how many jobs run at once (Free 20, Pro 40, Team 60, Enterprise 500) — is per account and shared across all your repositories, not per repo, and routine submissions and tooling upgrades draw from that same pool. That's why the per-repo runner cap defaults to a conservative value.

A runner is the machine that actually executes a GitHub Actions workflow job. When a run is triggered, GitHub hands the job to a runner, which checks out your code, runs each step in order, and — for LabVIEW CI — pulls and runs the worker container that does the compile, analysis, diff, or test. One job runs on one runner.

There are two kinds:

• GitHub-hosted runners (the default). Fresh, disposable virtual machines GitHub provisions for each job — windows-2022 for Windows jobs, ubuntu-latest for Linux — and wipes the moment the job finishes. There is nothing to install or maintain. They are free on public repositories and draw from your GitHub Actions minutes on private ones.
• Self-hosted runners. Machines you own and register with your repository or organization by running GitHub's runner agent on them. Use these when you need special hardware, a license tied to a specific machine, access to an internal network, or a persistent Docker layer cache so the multi-gigabyte worker image is not re-pulled every run. You are responsible for keeping them online and updated.

Because the worker container runs on the runner, choosing a runner is how you choose where your CI executes. You pick GitHub-hosted or a self-hosted runner label during setup or from ⚙ Configure Workers. Note that GitHub caps how many jobs — and therefore runners — can run at once per account (see the cost question above), which is why LabVIEW CI has a max concurrent runners setting.

Yes. When setting up or configuring your pipeline, specify custom runner labels if you've registered them with your GitHub organization or repository.

Custom runners are useful if you have:

• A local build machine with special hardware
• Licenses that tie to a machine
• Network requirements (internal package servers, etc.)

See your GitHub Actions settings to register custom runners.

The dashboard shows results for every commit. If CI fails on a commit:

• The failing commit is flagged on the dashboard
• You can click through to see Mass Compile errors, VI Analyzer warnings, or test failures
• Open a new pull request to fix the issue

Protecting your main branch (requiring CI to pass before merge) prevents broken commits from landing.

The Clients page lists the public repositories found to be running this LabVIEW CI stack. We want to be fully transparent about how that list is built, because it is gathered automatically.

Discovery is deliberately pull-based: the source repository finds its own clients by querying GitHub's public search index. Your repository is never modified, never has to "phone home," and there is no shared secret, tracking pixel, or telemetry call involved. A scheduled workflow in the source repository (discover-clients.yml, which you can also trigger by hand with the Scan for clients button) looks for three public signals that an install necessarily leaves behind:

• The labview-ci repository topic — added to a client repository at install time. This is the primary, most reliable signal, because GitHub indexes repository topics as structured metadata.
• A catalog reference — this repository's slug appearing as the source.repo value in a client's .github/labview-ci/catalog.json.
• A workflow reference — a uses: reference back to this repository inside a client's .github/workflows/ files.

Every candidate is then verified before it is listed: the repository must be public, must not be a fork, and its catalog must actually point back to this repository (or it must reference this stack from a workflow). Coincidental text matches in unrelated repositories are dropped, so the count reflects real installs.

Privacy. GitHub's search index only covers public repositories, and each candidate is additionally checked to be non-private. Private repositories are never discovered or listed — a deliberate property, since the Clients page itself is public. Only information GitHub already exposes publicly is shown: the repository name and owner, its installed tooling version, when it was last updated, and links to its dashboard and repository.

The scan runs about once a day, so a brand-new install can take up to a day — plus GitHub's own search-index lag — to appear; Scan for clients triggers it on demand. The workflow runs only in the source repository, so a fork or a vendored copy never scans on anyone else's behalf.

LabVIEW CI is open-source on GitHub:

github.com/elijah286/LabVIEW-CI-with-Containers

You can:

• Open an issue to report a bug or request a feature
• Check existing issues to see if your question or request has already been discussed
• Watch the repo to get notified of new releases