implement matrix-testing with a reusable behave workflow

[komish]

Fixes #327

Summary - this PR:

1. Adds a net-new reusable workflow (behave.yml) that will run our behave-driven tests, such as the nightly and smoke tests in a matrix, subdivided by feature file definition.
2. Removes version-check related tests and code that enabled those tests. As discussed with maintainers, this check did not seem to deliver as much value and added a good deal of overhead in behave testing that only applied to that use case.
3. Refactors all behave testing callers to use the new reusable workflow. In effect, this amounts to the nightly tests, release tests, and smoke tests used for workflow modification pull requests.

Long form notes for maintainers:

• Reusable workflow vs. composite actions: I ended up using a reusable workflow instead of a composite action because the former gives access to the user's base environment. I believe I also read that you cannot run a matrix in a composite action, and instead need to invoke the matrix at the call point. This would have added some overhead to every call point that just seemed inefficient. The reusable workflow completely encapsulates the behave tests, so the caller just needs to specify what tags and the state of the repository (if not default) to pull.

• Splitting single-job workflows into multiple jobs: Arguably the trickiest part of this effort, I had to split workflows into, at the very least, two jobs (from one) because a matrix happens at the job level. In effect, the task that would run in a matrix would inevitably need to be in its own job, and therefore would have to receive both inputs from any previous jobs, and emit outputs for subsequent jobs. For this reason, there are several changes that partition out workflows that would be one or two jobs into many jobs.

• Checkout-related inputs to behave.yml: In certain cases, the behave.yml would need to pull the changes submitted by the contributor in order to either (a) use new scripts, or (b) test updated workflows. Most of the workflows that call behave.yml are pull_request_target-triggered workflows, and so the actions/checkout task does not pull the PR (for security reasons) but instead pulls the HEAD of the main branch. We gate pull requests for critical things like this using the check-contributor action in-repo, and release-related scripts and entrypoints check it as well. Either way, in order to run the new code, we have to be able to pull the new code in. The inputs in behave.yml have had descriptions added so that the caller understands their responsibility in checking the author of the content before running.

• Using a list of feature files as the matrices: IIRC I couldn't tell behave to run only HC-001 features without writing a tag for each new feature file. I also couldn't find a a clean way to generate a list of tests that were both in the full tag AND the HC-001 feature definition. Either way, both of those options would have required us to modify our tag definitions in workflow every time we want to either extend a feature file or add new features. To that end, it felt better to auto-generate the list of files and just run the full tag against the individual feature file. Worth noting - when you specify a feature file with a tag, and that feature file has no tests with that tag, you'll just get an auto-green test case in GitHub Actions. It's not perfect, but it's the simplest way I've been able to split the work into a matrix. Open to suggestions if there is an obvious other approach that doesn't have similar (or its own array of alternate) tradeoffs.

Where can I see it running?

Here's an example release: https://github.com/practice-room/development/actions/runs/12019147275/job/33508212448

Here's an example of the PR to the production repo containing new workflows and scripts. The test set here has been reduced to speed up the development feedback cycle. That's why we only see two tests: practice-room/charts#9

Remaining concerns:

• This should speed up the behave full test suite a reasonable amount, but each new job that we spin up means we have to get scheduled to a runner which adds work time. Hopefully the overall time will be improved compared to our previous 5-6 hours. We can continue to explore other ways to reduce this time (such as reducing the timeout on our 30 minute timeout tests).
• We have to be careful with secondary rate limits now. The number of API requests made per minute may be high in release cases. E.g. after we've sent a bunch of requests for a release, then have PRs against all three repositories that may continue to count against API limits. For this reason, concurrency of the matrix is set to 4. As long as this value isn't 1, I'd think we should see an improvement overall.

[jsm84]

/lgtm