This document defines the minimum contract for a downstream team adopting
compare-vi-cli-action.
- compare two LabVIEW
.vifiles through the published composite action - run the maintained manual compare workflows described in
README.md - consume released versions from the active supported release line
- GitHub Actions repository context
- self-hosted Windows runner for full compare execution
- maintained LabVIEW installation
- maintained LVCompare installation at the canonical path described in
CONTRIBUTING.md
Hosted Linux/macOS and non-LabVIEW checks are useful support lanes, but they do not replace the maintained compare runtime.
Use these as the authoritative adoption surface before consulting deeper operator docs.
Do not assume:
- every workflow in
.github/workflows/is part of the public product contract - internal release conductor, downstream promotion, or standing-priority automation is stable for external reuse
- hosted-only execution is sufficient for full compare support
- undocumented workflow lanes are supported consumer APIs
A downstream adoption should be considered successful only when:
- the downstream repo can invoke the supported action or workflow entrypoint
- the required Windows + LabVIEW + LVCompare runtime is available and healthy
- a compare run completes and produces the expected diff/no-diff artifacts
- the downstream team can identify which released version they are pinned to
- the downstream team knows where to report security or support issues
If those five conditions are not met, the consumer is still in onboarding, not in stable adoption.
Use FIRST_CONSUMER_SUCCESS_PATH.md when a
team needs the shortest operator-ready walkthrough to satisfy those five
conditions before moving into the deeper onboarding program.