LabVIEW CI 4.18.6

Protected-branch releases and promotions now recover when an older prepared catalog branch already exists for the same version. A non-fast-forward rejection uses a separate branch keyed to the new prepared commit, preserving the original branch and its review history without a force-push. Other push failures retain their Git diagnostics and still stop publication. Regression checks now run in the Catalog Source Sync pull-request gate. Review and merge only the current catalog proposal; close older proposals once their release notes are accounted for.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.5

Caraya runs now retain runner startup/execution failures and LabVIEW CLI logs in the Unit Tests report instead of hiding an empty result as a missing report. The driver reads the configurator's nested configuration, preserves command quoting, removes stale output, and fails when an enabled runner cannot execute. Invalid JUnit, zero tests, and all-skipped runs cannot produce a green result. Caraya 1.4.4.148 is installed with the required early worker packages; a failed required bake now explicitly fails the final worker Docker build. Rebuild existing seed-only workers and supply all project dependencies. The documented native LabVIEWCLI wrapper path passed 44 assertions locally in Measurement Utility Reference; clean-container validation is not yet established. The old g-cli extension command remains an unverified scaffold.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.4

dashboard: surface SBOM reports on GitHub Pages

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.3

Bug fix: dashboard's populate history checkboxes

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.2

Running CI on a fresh fork of a configured repository now works on the first try. A fork copies the workflows but never the worker container images, so every container activity used to fail on an opaque "manifest unknown" pull error. The dependency gate now detects that the worker image has never been built, starts the Build LabVIEW CI Image run itself, waits for it (a first build takes 80-100 minutes), and then continues. When it cannot start the build automatically, the job stops up front with instructions instead of a doomed pull, the commit status reads "Worker image unavailable - build it via Configure Workers" rather than a generic activity failure, and a pinned container tag that was never published is reported as a configuration error. Applies the same on any repository whose first worker build never ran.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.1

A failed push to the GitLab distribution mirror no longer paints the whole Release run red or raises the dashboard's attention banner: the release still publishes, the run finishes with a warning naming the fix, and the Sync GitLab Distribution workflow re-pushes the tag once the cause is resolved. The dashboard's red attention banner now ignores owner-only maintenance workflows entirely, so visitors only see failures that reflect the repository's own CI health. The configurator's GitLab mode also drops its GitHub-specific hints — the target field is labeled as a project path, notes that nested subgroup paths like group/subgroup/project work, and links the Installing-from-GitLab notes instead of the private-GitHub-repo notes.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.18.0

Adds a release-driven GitLab distribution mirror so GitLab projects can bootstrap the same canonical LabVIEW CI implementation without a second codebase. GitLab-source installs record their archive origin in the manifest, and later bootstrap updates re-fetch that origin instead of relying on a stale local installer; immutable release tags remain protected while channel aliases advance with the mirror. Added an installable native GitLab CI provider for custom workers, Mass Compile, VI Analyzer, Unit Tests, Antidoc, SBOM Generation, Builds, VIDiff, and both snapshot paths. It publishes private project-registry workers, preserves Pages report history, and keeps existing root GitLab pipelines safe during installation. GitLab-hosted Linux Docker-in-Docker worker builds are verified; Windows jobs still need a self-managed Docker-capable runner. Linux VIPM bakes now show install phases and fail closed with focused diagnostics when a package action fails, so incomplete workers are never published. A package-owned post-install VI must itself support unattended Linux execution; VIPM cannot safely skip it.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.17.2

The configurator's install progress no longer reports "one worker image did not finish successfully" when the image actually seeded fine. A fork install starts each copy workflow twice -- the page dispatches it and the install merge's own push trigger fires it -- and their shared concurrency lane cancels one of the twins while it is still queued. The watcher used to judge only the newest run, so when the cancelled twin was the newer one it showed a false warning; it now prefers a successful run of that workflow from the same install before judging.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.17.1

Every vendored workflow file now carries a tooling-version stamp, so each update rewrites every workflow file and the update push makes GitHub (re)register them. This heals repositories -- typically fork installs whose pipeline was pushed while Actions was still disabled -- where dispatch-only workflows like Reconfigure existed on the default branch but were never registered, so the dashboard's "Save monitored files" and container-update buttons failed with HTTP 404 no matter what token was supplied. The Dependencies and Configure pages now also tell this case apart from a real token problem and say exactly how to fix it.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.

LabVIEW CI 4.17.0

Fixed the dashboard's disappearing "Queued" pills. When a queued run died before it could report anything — typically the repository ran out of GitHub Actions minutes, hit a billing block, or the run was cancelled while still waiting for a runner — the dashboard lost all trace of it: the browser's optimistic Queued badge silently expired about 20 minutes after you queued, and the rebuilt page showed a clean idle cell, as if nothing had ever been queued. Dead runs now stay visible everywhere: the badge in the queuing browser turns into a sticky red Failed marker within a minute even when the run dies in seconds, and the dashboard itself now renders a red Failed badge — for every viewer — on any cell whose latest run ended without reporting a result, linking straight to the dead run so the cause is one click away. The badge yields to any newer result, ages out after a day, and Populate history counts those cells as missing so Fill re-queues them. Warm-container batch backfills are covered too: the single batch run is now tracked per revision both in the browser and on the rebuilt page (its run name carries the revision list), so a healthy batch no longer watches its badges evaporate mid-run. The history card's concurrency note now describes how queued runs actually pace themselves (GitHub's account-wide runner limit) instead of a per-repository cap that was never enforced.

Consumers pinned at the major alias (e.g. @v4) receive this automatically.