This guide explains how to automate build, test, and distribution steps for the LabVIEW Icon Editor using GitHub Actions—with multiple pre-release channels (Alpha, Beta, RC), optional hotfix branches, and a toggleable Development Mode feature. It is designed to align with Gitflow practices, allowing you to enforce a hands-off approach where merges flow naturally from develop → release-alpha → release-beta → release-rc → main, while also ensuring forks can reuse the same build scripts.
[!NOTE] For troubleshooting and a more extensive FAQ, see
troubleshooting-faq.md. For more detailed runner setup instructions, seerunner-setup-guide.md.
Automating your LabVIEW Icon Editor builds and releases offers several benefits:
major, minor, patch).-build<commitCount>.This workflow ensures that all forks of the repository can sync the latest build scripts from upstream (e.g., NI) and follow the same rules. If you keep your fork up to date, you benefit from any bug fixes or improvements made in the original repo.
.github/workflows
Ensure the following workflows exist (or adapt names as needed):
development-mode-toggle.yml (Development Mode Toggle)ci-composite.yml (CI Pipeline (Composite); includes the Build VI Package job)major, minor, or patch to request a version bump. If no label is present, the workflow defaults to a patch bump. The workflow fails only if multiple release labels are applied. See compute-version for details.release-alpha/* for early testing (-alpha.<N>),release-beta/* for later testing (-beta.<N>),release-rc/* for near-final (-rc.<N>),hotfix/* merges can go directly to main for quick patches..vip file is generated and uploaded as a build artifact.For a visual reference, you may consult a Gitflow diagram that includes alpha/beta/rc branches as an extension of the typical release/ branch. This helps illustrate how merges flow between develop and main.
Development Mode configures LabVIEW for local debugging or specialized project setups. It often involves modifying labview.ini so LabVIEW references local source code. You can enable or disable it as needed:
mode=enable (or manually call Set_Development_Mode.ps1).mode=disable (or call RevertDevelopmentMode.ps1).[!IMPORTANT] When Development Mode is enabled, you generally can’t test the final
.vipinstall properly (since LabVIEW might be pointing to local source). Always disable dev mode before attempting a final install or distribution test.
For detailed runner configuration, see runner-setup-guide.md. Below is a short summary:
self-hosted-windows-lv-ie (or self-hosted-linux-lv for Linux). Ensure your workflow’s runs-on references these labels.Below are the two key workflows. Each one is defined in its own .yml file.
You’ll typically name the workflow file development-mode-toggle.yml. Its purpose is to enable or disable a “development mode” on a self-hosted runner that has LabVIEW installed.
What Is “Development Mode”?
labview.ini)..vip for normal testing—so you’ll want to toggle it off once you finish coding or debugging.Purpose of This Workflow
workflow_dispatch) or by other workflows (via workflow_call).enable or disable to run the corresponding PowerShell script (Set_Development_Mode.ps1 or RevertDevelopmentMode.ps1).labview_version).bitness, default 64).self-hosted-windows-lv-ie)..vip may fail or cause conflicts.workflow_call. Pass the input parameter mode = enable or disable.labview_version: 2021 if you include the input (other values are not supported).bitness (32 or 64) to select the LabVIEW bitness.A) Call from Another Workflow in the Same Repository
name: "My Other Workflow"
on:
workflow_dispatch:
jobs:
call-dev-mode:
runs-on: self-hosted-windows-lv-ie
steps:
- name: Invoke Dev Mode Toggle (enable)
uses: ./.github/workflows/development-mode-toggle.yml
with:
mode: enable
labview_version: 2021
bitness: 64
B) Call from Another Repository
name: "Cross-Repo Dev Mode Toggle"
on:
workflow_dispatch:
jobs:
remote-dev-mode:
runs-on: self-hosted-windows-lv-ie
steps:
- name: Use remote Dev Mode Toggle
uses: <owner>/<repo>/.github/workflows/development-mode-toggle.yml@main
with:
mode: disable
labview_version: 2021
bitness: 64
C) Call from a Fork
name: "Forked Dev Mode Example"
on:
workflow_dispatch:
jobs:
forked-workflow-call:
runs-on: self-hosted-windows-lv-ie
steps:
- name: Call Dev Mode Toggle from My Fork
uses: <your-fork>/<repo>/.github/workflows/development-mode-toggle.yml@my-feature-branch
with:
mode: enable
labview_version: 2021
bitness: 64
All dev-mode logic resides in two PowerShell scripts:
Set_Development_Mode.ps1 – Called when mode is enable.RevertDevelopmentMode.ps1 – Called when mode is disable.ci-composite.ymlcompute-version) derives the version from PR labels and commit count, and the Build VI Package job builds the .vip artifact using that version output.issue-<number> (e.g., issue-123, feature/issue-123) and the linked issue has Status In Progress.major, minor, patch); unlabeled pull requests
default to patch (see .github/actions/compute-version/action.yml, used by
compute-version in ci-composite.yml).vX.Y.Z-build<commitCount> (plus optional pre-release suffix).release-alpha/*, release-beta/*, release-rc/*..vip file and uploads it as a workflow artifact (no automatic GitHub Release attachment).main, develop, release-alpha/*, release-beta/*, release-rc/*, feature/*, hotfix/*, or issue-*.
The workflow explicitly lists these pre-release patterns and does not use a generic release/* trigger.workflow_dispatch) if needed.Gitflow typically involves:
develop: main integration branch for ongoing development.feature/*: branches off develop for individual features.release/*: branched off develop when nearing release.hotfix/*: branched off main for urgent fixes.In this repo, we extend the concept of release/* into release-alpha/*, release-beta/*, and release-rc/* to differentiate pre-release stages. The CI workflow mirrors this by triggering on these exact patterns. Merges flow as:
Branches named:
release-alpha/* → produces a version suffix -alpha.<N>.release-beta/* → produces a version suffix -beta.<N>.release-rc/* → produces a version suffix -rc.<N>.Merging into these branches (or pushing directly to them) triggers a pre-release build. After final testing in release-rc/*, merging into main yields a stable release without any suffix.
hotfix/* merges produce a final release (no -rc, -alpha, or -beta).When you open a Pull Request into develop, release-alpha/*, or release-beta/* (or even main/hotfix/*):
major, minor, or patch to increment the corresponding version segment (e.g., 1.2.3 → 2.0.0 if major, etc.).compute-version for implementation details.Note: This means you can version-bump incrementally while merging into
develop(to reflect that new features are in development), or you can wait until you merge to a pre-release branch. Each time the build runs, the resulting.viphas an updated version (with a new build number, plus any alpha/beta/rc suffix if applicable).
git rev-list --count HEAD.-build<commitCount> in the final version string.In order to enforce the Gitflow approach “hands-off”:
main, release-alpha/*, release-beta/*, and release-rc/* so that only approved Pull Requests can be merged, preventing direct pushes.CONTRIBUTING.md:
Only the original (upstream) repo typically enforces these rules. Forks may choose to adopt them but are not forced to. However, if you submit a PR upstream, you’ll need to comply with the branch protections in place there.
multichannel-release-workflow.md for details on alpha/beta/RC branch strategy.runner-setup-guide.md.troubleshooting-faq.md for a detailed list of common issues, solutions, and frequently asked questions.CONTRIBUTING.md.