This document describes how to build, test, and distribute the LabVIEW Icon Editor using PowerShell. You can run these scripts locally on your development or self-hosted runner, or within GitHub Actions. By making this process open-source, we enable community collaboration, easier troubleshooting, and a more transparent build pipeline for the Icon Editor that ships with LabVIEW.
Build.ps1 Works.lvlibp, and producing a .vip artifact..github\actions\apply-vipc\runner_dependencies.vipc to LabVIEW 2020 (20.0), 32-bit & 64-bit—matching the apply-deps matrix in ../.github/workflows/ci-composite.yml.Back Up (highly recommended):
<LabVIEW>\resource\plugins\lv_icon.lvlibp
<LabVIEW>\vi.lib\LabVIEW Icon API
Clone the Icon Editor to your development location.
Apply dependencies:
.github\actions\apply-vipc\runner_dependencies.vipc to LabVIEW 2020 (20.0), 32-bit & 64-bit.
Open PowerShell (Admin):
Navigate to .github\actions\set-development-mode
.\Set_Development_Mode.ps1 -LabVIEWVersion 2021
Removes the default lv_icon.lvlibp and points LabVIEW to your local Icon Editor code.
lv_icon_editor.lvproj.github\actions\apply-vipc\runner_dependencies.vipc.cd .github\actions\build
Build.ps1:
.\Build.ps1 `
-RepoRoot "C:\labview-icon-editor" `
-Major 1 -Minor 2 -Patch 3 -Build 45 `
-Commit "my-commit-sha" `
-LabVIEWMinorRevision 0 `
-Verbose
This generates a .vip in builds\VI Package.
Branding tip: Add optional metadata fields such as -CompanyName and -AuthorName to the command above to embed your organization or repository name in the package. These values appear in the final VI Package metadata, helping identify builds from different forks.
..\revert-development-mode\RevertDevelopmentMode.ps1 -LabVIEWVersion 2021
.vip in VIPM (as Admin). Validate your custom Icon Editor changes.We provide GitHub Actions that wrap these same PowerShell scripts for building the Icon Editor:
Set_Development_Mode.ps1 or RevertDevelopmentMode.ps1.Build.ps1 to produce a .vip artifact (and can draft a release if configured).Unit tests run within the test job of the composite CI workflow defined in .github/workflows/ci-composite.yml.
In many workflows, you may want the organization or repository name injected into the VI Package to brand the build uniquely. For instance, if you have a GitHub Actions workflow, you can pass environment variables like $ (the org or user) and $ (e.g. myorg/myfork) to Build.ps1. This is useful when:
An example step in a GitHub Actions file might look like:
- name: Build Icon Editor
run: |
pwsh .\.github\actions\build\Build.ps1 `
-RepoRoot "$env:GITHUB_WORKSPACE" `
-Major 1 -Minor 2 -Patch 0 -Build 10 `
-Commit "$" `
# You can pass metadata fields to brand the package:
-CompanyName "$" `
-AuthorName "$" `
-Verbose
Passing these metadata fields ensures the final .vip clearly identifies which fork built it, and under which organization.
Key Points:
Build.ps1 WorksBuild.ps1 orchestrates the entire build pipeline for the Icon Editor:
.lvlibp files in resource\plugins.-Major, -Minor, -Patch, -Build, -Commit).lv_icon_x86.lvlibp, lv_icon_x64.lvlibp)..vip (64-bit) with build_vip.ps1:
CompanyName and AuthorName) gets placed into the Display Information section of the .vipb file to brand the package.-LabVIEWMinorRevision parameter can override default minor version logic..vip can identify who built it..vipb each time.Build.ps1 → (Optionally) revert dev mode..vip locally, too..vip.Set_Development_Mode.ps1 or a “Development Mode Toggle” workflow run.test job to confirm changes.major, minor, patch) for semver bump.Build.ps1 to produce .vip on merges..github/workflows/ci-composite.yml workflow uploads the built .vip as an artifact in its “Upload VI Package” step..vip and confirm final functionality.All scripts are fully open-source—collaborators can debug or extend them locally with minimal friction. By passing organization/repo data in either local builds or GitHub Actions, you ensure your unique version of the Icon Editor is clearly labeled and easily traced to its source.