Coverage: 94.803%. Remained the same when pulling4d6a6bf on murrayrm:test_matrix-22Dec2022 into56f227f on python-control:main.

Added checks + xfail for Ubuntu with generic BLAs with numpy 1.24.0, in response to issue#820. Near as I can tell, this is some sort of edge case that gets triggered under this specific set of circumstances. Not sure this is the right way to handle it, but given that all of the other environments work out, I don't think it is a bug insolve_flat_ocp.

python-control is pure Python andshould not depend on the environment. Problems in the environment usually show up when the consumed libraries change, not during python-control PRs.

We already go through that test matrix in the Slycot CI and run the python-control test suite there. Not sure if we really should duplicate the resource consumption here.

I agree thisshouldn't be needed@bnavigator, but the failure pointed out in issue#820 is an example of where python-control does depend on the operating environment, because there is some sort of (non-slycot) interaction with something in the build environment (and only under Ubuntu, NumPy 1.24, generic BLAS).

I've changed the trigger to workflow_dispatch, which allows this to be manually triggered on the main branch, plus on PRs that affect files specifically associated with this workflow. That will get rid of the resource consumption except in the rather exceptional cases where we need it. (I also imagine that we might customize the test matrix here over time, so it could diverge from slycot.)

My current plan is to add a step in therelease Instructions suggesting running this workflow before a release, just to flag anything where python-control depends on the details of the OS, BLAS version, or installation method.