Open Source LabVIEW Actions is a collection of GitHub Actions and PowerShell scripts that streamline LabVIEW CI/CD workflows. Each task is exposed as its own action backed by a unified dispatcher. Refer to the documentation for setup guidance, detailed examples, and the complete action reference.
- Node.js 24+ (run
npm installafter cloning to fetch tsx and other dependencies) - PowerShell 7+ (
pwsh) - NI LabVIEW with command-line interface support (g-cli) for LabVIEW-based actions
- Supported platforms: Windows for LabVIEW tasks; PowerShell-only scripts also run on macOS and Linux
See Environment Setup for installation steps and commands to verify each dependency.
- name: Run tests
uses: LabVIEW-Community-CI-CD/open-source/run-unit-tests@v1
with:
minimum_supported_lv_version: '2021'
supported_bitness: '64'Each adapter has its own wrapper. Replace run-unit-tests with any action name listed in the action reference. The wrappers translate the typed inputs above into the dispatcher.
Common optional inputs available on all wrappers:
| Name | Description |
|---|---|
gcli_path |
Path to the g-cli executable when it is not on PATH. |
working_directory |
Directory where the action runs. |
log_level |
Verbosity level (ERROR, WARN, INFO, DEBUG). |
dry_run |
Simulate the action without side effects. |
Run tests from a subfolder:
- uses: LabVIEW-Community-CI-CD/open-source/run-unit-tests@v1
with:
minimum_supported_lv_version: '2021'
supported_bitness: '64'
working_directory: srcEnable debug logging and perform a dry run:
- uses: LabVIEW-Community-CI-CD/open-source/run-unit-tests@v1
with:
minimum_supported_lv_version: '2021'
supported_bitness: '64'
log_level: DEBUG
dry_run: trueFor a full workflow example that chains multiple actions to build the LabVIEW Icon Editor, see docs/quickstart.md#build-icon-editor.
If you prefer or need to run tasks directly, serialize arguments as JSON and call the dispatcher script actions/Invoke-OSAction.ps1 yourself:
$json = @'
{
"MinimumSupportedLVVersion": "2021",
"SupportedBitness": "64"
}
'@
pwsh ./actions/Invoke-OSAction.ps1 -ActionName run-unit-tests -ArgsJson $jsonAlternatively, load arguments from a JSON file:
pwsh ./actions/Invoke-OSAction.ps1 -ActionName run-unit-tests -ArgsFile ./config/run-tests.jsonBy default the dispatcher ignores unknown parameters and emits a warning. Add -FailOnUnknown to treat unexpected parameters as errors:
pwsh ./actions/Invoke-OSAction.ps1 -ActionName run-unit-tests -ArgsJson $json -FailOnUnknownList all available actions:
pwsh actions/Invoke-OSAction.ps1 -ListActionsGet details about a specific action:
pwsh actions/Invoke-OSAction.ps1 -Describe run-unit-testsWorkflows distinguish between standard GitHub-hosted images and integration runners with preinstalled tooling. See docs/runner-types.md for a detailed comparison.
Run the JavaScript tests and generate traceability artifacts with:
npm install
npm run test:ci
npm run derive:registry
RUNNER_OS=Linux TEST_RESULTS_GLOBS='test-results/*junit*.xml' npm run generate:summary
npm run check:traceabilityWhen running locally, set RUNNER_OS (for example, RUNNER_OS=Linux) before invoking npm run generate:summary.
npm run test:ci writes JUnit files to test-results/. scripts/generate-ci-summary.ts parses these results to build requirement traceability files in OS‑specific subdirectories (e.g., artifacts/windows, artifacts/linux) based on the RUNNER_OS environment variable. Commit test-results/* and artifacts/linux/* along with your source changes. The summary script searches artifacts/ by default; set TEST_RESULTS_GLOBS if your reports are elsewhere.
Pester tests cover the dispatcher and helper modules. See docs/testing-pester.md for guidelines on using the canonical argument helper and adding new tests. The GitHub runner installs Pester automatically; install it locally only if you plan to run the tests yourself:
Install-Module Pester -Force -Scope CurrentUser$cfg = New-PesterConfiguration
$cfg.Run.Path = './tests/pester'
$cfg.TestResult.Enabled = $false
Invoke-Pester -Configuration $cfgXML test result output is intentionally disabled.
Committing build artifacts together with a release.json file enables the
release pipeline. The release.json file supplies the JSON payload describing
the release:
{"major":1,"minor":0,"patch":2,"title":"Release title"}Ensure the build artifacts are present (for example under artifacts/) and
checked in alongside release.json. The ci.yml workflow runs first and, on
success, hands off to release.yml to publish the release. See
Test and Release Mode for more details.
Each requirement is tracked as an issue or entry in
requirements.json. Every code change must reference the
requirement it addresses, and each requirement must have at least one automated
test. The CI pipeline checks these links and reports missing associations. For a
full mapping of requirements to tests, see
docs/requirements.md.
Contributions are welcome! See CONTRIBUTING.md for general guidelines and docs/contributing-docs.md for documentation rules.
To preview docs locally:
pip install mkdocs mkdocs-material
mkdocs serveIf npm prints npm warn Unknown env config "http-proxy", remove the
npm_config_http_proxy environment variable or replace it with
npm_config_proxy/npm_config_https_proxy.
Node.js 24+ removes legacy constants like fs.R_OK. Scripts and patches in
this repository rely on fs.constants.R_OK to remain compatible with newer
Node releases.