This revised guide focuses on the release workflow, specifically how we handle multiple pre-release channels (Alpha, Beta, RC) in addition to final versions.
This Multi-Channel Release Workflow automates packaging LabVIEW .vip files for multiple pre-release channels. It uploads artifacts but does not create Git tags or GitHub releases. It:
-buildNN).release/* for RC. The pre-release number uses the same commit count as the build number, so both values are identical.By adopting these patterns, maintainers can run alpha, beta, and RC pipelines in parallel or sequentially, each channel generating distinct pre-release versions.
.vip files.GITHUB_TOKEN) needs contents: read to upload artifacts.major, minor, or patch to increment those fields. If none is provided, the workflow defaults to a patch bump. Multiple release labels cause the workflow to fail. See compute-version for the label-handling logic.release-alpha/*.vX.Y.Z-alpha.<commitCount>-build<commitCount>.release-beta/*.vX.Y.Z-beta.<commitCount>-build<commitCount>.release-rc/*.vX.Y.Z-rc.<commitCount>-build<commitCount>.main, develop, hotfix/* produce final releases with no alpha/beta/rc suffix.The accompanying GitHub Actions workflow (ci-composite.yml) lists release-alpha/*, release-beta/*, and release-rc/* in its trigger patterns so commits or pull requests to these branches automatically run this pipeline.
To enable these pre-release branches, ensure the workflow’s on.push.branches and on.pull_request.branches sections include the patterns:
on:
push:
branches:
- main
- develop
- release-alpha/*
- release-beta/*
- release-rc/*
- feature/*
- hotfix/*
- issue-*
pull_request:
branches:
- main
- develop
- release-alpha/*
- release-beta/*
- release-rc/*
- feature/*
- hotfix/*
- issue-*
Use whichever patterns best fit your project’s branching model. If you prefer subdirectories (release/alpha/* vs. release-alpha/*), adapt the snippet accordingly.
The composite CI workflow only runs full jobs when the issue-status check succeeds. That job requires the source branch name to contain issue-<number> (for example, release-alpha/issue-123 or issue-456) and the linked GitHub issue’s Status to be In Progress. Branches without this prefix—such as release-alpha/2.0—trigger the workflow but skip all subsequent jobs. See the issue-status job in ci-composite.yml for details and its downstream gate.
Below is a high-level breakdown. In your .github/workflows/ci-composite.yml, these steps typically appear in order:
fetch-depth: 0 to have full commit history.major, minor, patch, or none).git rev-list --count HEAD).v0.0.0).release-alpha/*, release-beta/*, or release-rc/*, append -alpha.<commitCount>, -beta.<commitCount>, or -rc.<commitCount>. The <N> value equals the commit count.-build<commitCount>. Because both suffixes use the commit count, the pre-release number and build number are identical.build-lvlibp and build-vi-package actions to compile code and produce the .vip package..vip as an ephemeral artifact with actions/upload-artifact@v4.release-alpha/1.0, release-alpha/mynewfeature, etc.release-beta/2.0, release-beta/test, etc.release-rc/2.1, release-rc/final-stability.Any commit to these branches triggers an alpha/beta/rc suffix. Merging to main finalizes the version (suffix removed).
if ($branchName -like 'release-alpha/*') {
$preSuffix = "alpha.$commitsCount"
}
elseif ($branchName -like 'release-beta/*') {
$preSuffix = "beta.$commitsCount"
}
elseif ($branchName -like 'release-rc/*') {
$preSuffix = "rc.$commitsCount"
}
else {
$preSuffix = ""
}
$preSuffix is non-empty, isPrerelease = true.v<major>.<minor>.<patch>-<preSuffix>-build<commitCount>. Since <preSuffix> incorporates $commitsCount, the pre-release number and build number are the same.$preSuffix is empty.isPrerelease = false, resulting in a stable release, e.g. v1.3.4-build50.release-alpha/2.0.v2.0.0-alpha.41-build41.release-beta/2.0. Now each commit yields v2.0.0-beta.45-build45.main yields a stable v2.0.0-build46.release-rc/2.1. The workflow sets -rc.<commitCount> so your testers see it’s near final, e.g. v2.1.0-rc.50-build50.v2.1.0-buildXX.develop or main directly, no suffix is appended, e.g. v1.2.3-build22.release-apha/* (typo in “alpha”), the script won’t detect alpha. Ensure consistent naming.if wins. Keep patterns distinct.USE_AUTO_NOTES == true, you get auto-generated release notes for alpha/beta/rc. Manually finalize them if you prefer.Q1: Can I have alpha, beta, rc all in one folder, like release/alpha/*, release/beta/*?
A1: Yes, just adapt the pattern checks, e.g. $branchName -like 'release/alpha/*', $branchName -like 'release/beta/*', etc.
Q2: What if I want numeric channel IDs, e.g. -alpha2 instead of -alpha.2?
A2: You can build $preSuffix = "alpha$commitsCount"—just remove the dot.
Q3: Does GitHub auto-flag alpha or beta suffix releases as pre-release?
A3: Not automatically. We set prerelease: true if $preSuffix is non-empty. This ensures the release is marked pre-release in GitHub’s UI.
Q4: How do I integrate these channels with tagging older versions or skipping certain channels?
A4: You can skip alpha or beta if you like, or go from develop → release-alpha/* → release-rc/* → main. The workflow logic is flexible.
By supporting multiple pre-release channels (Alpha, Beta, RC), this updated release workflow offers greater flexibility for iterative testing stages. Each branch pattern yields a distinct suffix (-alpha.<commitCount>, -beta.<commitCount>, or -rc.<commitCount>). Merging into a final branch (e.g., main) produces a stable release with no suffix, but still uses commit-based build numbering—so the pre-release number and build number are always identical. Combined with label-based major/minor/patch increments, you have a robust, fork-friendly, and multi-stage CI/CD pipeline for LabVIEW.