Skip to content

Feature/linux lunit unit tests - #71

Open
antsundq wants to merge 6 commits into
ni:mainfrom
antsundq:feature/linux-lunit-unit-tests
Open

antsundq wants to merge 6 commits into
ni:mainfrom
antsundq:feature/linux-lunit-unit-tests

Conversation

@antsundq

Copy link
Copy Markdown
Contributor

Summary

Runs LUnit unit tests in the Linux worker.

  • Runner – new .github/labview/run-unit-tests.sh, the Linux counterpart of run-unit-tests.ps1: the same unitTests config, the same LUnit command template and tokens, the same lunit-<n>.xml / _tooling.json outputs, and it always exits 0 (pass/fail comes from the JUnit file). The frameworks it can run are listed in LINUX_TOOLS; LUnit is the only entry. Any other enabled tool is skipped, and the Linux report says it was not run on Linux.
  • Workflow – new unit-tests-linux-container.yml (ubuntu-latest, same triggers and image selection as the other Linux activities). It deploys to unit-tests/<sha>/linux/ and posts CI / Unit Tests (Linux), which the report's platform toggle and the dashboard's Windows / Linux pill already read. The dashboard's Run button now covers Linux too.
  • Catalog / installer / GitLab – unit-tests now supports ["windows", "linux"], with the Linux files listed and a GitLab unit-tests-linux.yml template; validate-catalog-source-sync.py passes. A Windows-only install gets nothing new.
  • Tooling – ci-tooling.vipc bakes LUnit CLI 1.7.1.32, the first release that runs on Linux. Only that entry changed; every other package in the committed VIPC is untouched.
  • Fix – install-vipc-linux.sh dropped a package's revision suffix (jki_rsc_toolkits_palette-1.1-1 was installed as @1.1, which VIPM rejects). That broke the Linux worker build as soon as the VIPC was applied.
  • Docs – the Unit Tests section of documentation.html (both copies), the Unit Testing page, the README row, config.example.yml, and a release-note fragment.

After merge

Linux client repos copy the shared Linux worker (LCWC_LINUX_BASE_IMAGE) instead of baking ci-tooling.vipc themselves. Run "Build LabVIEW CI Image - Linux" on this repo after merging so the shared worker gets LUnit CLI 1.7.1.32; until then, Linux clients report missing LUnit tooling.

Test plan

  • Built the shared Linux worker from this branch in a fork acting as the source repo (2026q3-linux): all 23 VIPC packages installed, including astemes_lib_lunit_cli v1.7.1.32.
  • Fresh install with os: [windows, linux] in a test repo with an LUnit Test Case: CI / Unit Tests (Linux) = 1 passed, and the report published under unit-tests/<sha>/linux/ (results.json: platform linux, tool lunit, 1/1).
  • Runner checked locally with a fake LabVIEWCLI: passing report, the -350053 missing-tooling banner, a non-LUnit tool skipped as not run on Linux, the -Headless override warning, and no hang when a child process keeps running.
  • install.py --dry-run for windows / linux / both and for GitLab linux; validate-catalog-source-sync.py passes.

antsundq and others added 5 commits September 30, 2026 08:46
Swap only the astemes_lib_lunit_cli entry (and its spec/icon) in the
committed VIPC; every other package is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
jki_rsc_toolkits_palette-1.1-1 was installed as @1.1, which VIPM rejects
(only 1.1-1 exists), failing the Linux source worker build.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LabVIEWCLI starts LabVIEW as a child that inherits stdout/stderr and keeps
running after LabVIEWCLI returns, so piping into tee never reached EOF and
the Linux unit-test step hung after 'LUnit operation succeeded.'. Write the
output to a file instead and print it once the call returns.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@antsundq
antsundq requested a review from elijah286 as a code owner September 30, 2026 11:44
The dashboard caller read source.ref from .github/labview-ci.yml but checked the tooling out from a repository fixed at install time (the catalog's canonical repo). Repointing source to a fork and one of its branches therefore fetched the fork's branch from the canonical repo and failed. Read source.repo as well, in the thin and consumer callers generated by install.py and in the source repo's own dashboard-pages.yml.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gvt367dUuHv3ZsYvywqQ1u

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant