In PR #234, we had to change the mdspan key (in .github/workflows/cmake.yml) so that the PR testing wouldn't always pick up an old mdspan (with the wrong tag, stable instead of mdspan-0.3.0). The workflow output suggested that for key: mdspan-${{ steps.get-sha.outputs.sha }}, the key was evaluating to mdspan-null. Thus, it could be that the code for getting the SHA1 is broken. If we don't fix this, then we'll never be able to test stdBLAS against the latest mdspan; it will always hit the cache, unless we change it manually (as we had to do in PR #234).
In PR #234, we had to change the mdspan key (in .github/workflows/cmake.yml) so that the PR testing wouldn't always pick up an old mdspan (with the wrong tag, stable instead of mdspan-0.3.0). The workflow output suggested that for
key: mdspan-${{ steps.get-sha.outputs.sha }}
, the key was evaluating tomdspan-null
. Thus, it could be that the code for getting the SHA1 is broken. If we don't fix this, then we'll never be able to test stdBLAS against the latest mdspan; it will always hit the cache, unless we change it manually (as we had to do in PR #234).