Closed ionut-arm closed 3 years ago
Well on fedora we run against 3.0 version. Is it some kind of special workflow that is needed?
Hmm, it may run against 3.0.0 "incidentally", but I'd rather have a workflow that runs against that specific version of tpm2-tss. For example, there's already a 3.1.0 tpm2-tss version out, we can't have guarantees about which one we're actually testing against. I think the Fedora workflow is more about checking that the crate works well with Fedora in particular, not with a specific version of the library.
True it inly takes the latest package available for the Fedora distribution.
I wonder if we should make it so that for each platform we make it build and run against several different version of the libarary.
Example:
Ubuntu:
install tpm2-tss 2.3.3
build (without generating bindings)
run tests
build (generate bindings)
run tests
uninstall tpm2-tss 2.3.3
install tpm2-tss 2.4.0
build (generate bindings)
run tests
uninstall tpm2-tss 2.4.0
install tpm2-tss 3.0.0
build (generate bindings)
run tests
uninstall tpm2-tss 3.0.0
Needs to make the script that runs take a version and an option to set if the bindings should be generated or not. And then we could set up all of the containers to run in parallel.
Our current CI workflows test against version 2.3.3 of the tpm2-tss library. However, we have functionality intended for compatibility with 3.0.0 which we do not automatically test (see https://github.com/parallaxsecond/rust-tss-esapi/pull/267). Ideally, all such functionality should be tested to make sure we are indeed compatible.
A new workflow should be created to run all our tests against tpm2-tss v3.0.0.