Pool names, default versions, capabilities checks

[Karl-G1]

• [x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

• Parameterize build pool name
  • Allow for overriding build pool at the azure-pipelines.yml level (instead of re-implementing stages.yml)
• Add defaults for build versions
  • Allow almost all custom devices building against this template to assume the same set of default versions without updating every repo when versions are changed
  • One-off differences like Scan Engine's multiple bitnesses are exercised via BuildMinimalCase list of versions
• Hard-code an optional new parameter lvVersionToDiff
  • Remove previous logic to choose the last 64-bit version in the list of versions to build
  • Massively simplifies the diff stage logic and should not require other repos to update unless to override the default value
• Add Capabilities checks
  • when determining which build agent in a pool to use, check for matching capabilities
  • VeriStand20XX = True must be set on build agents for build and diff steps after this change
  • Allows for a mix of build agent capabilities, which is helpful when adding new LabVIEW support on major version changes

Why should this Pull Request be merged?

As we get closer to a new major version of VeriStand and LabVIEW support, these changes allow us to prototype new custom device builds earlier. This is due to leaving 2020, 2021, and 2023 builds enabled on an official build agent pool with released software stacks, as well as enabling 2024 builds on other nodes.

What testing has been done?

Branch build was successful after updating Capabilities tags on build agents Pending PR build to test diff pipeline stage

[niveristand-diff-bot]

Bleep bloop!

LabVIEW Diff Robot here with some diffs served up hot for your pull request.

Notice something funny? Help fix me on my GitHub repo.

ClearCache.vi.png