Closed daringer closed 1 year ago
awwww, that's a very good argument - I might even remember the initial discussion :nerd_face:
variables.mk
feels like a very good idea, I will simply make sure that run-hw
will only run, if the variables.mk
UUID matches the one extracted by the Makefile
so this serves as an additional safe-guard...
Okay! You could also just pass it through directly to the test suite and change UsbDevice.find
to accept a list of UUIDs instead of a single UUID. That would be more general.
https://github.com/Nitrokey/nitrokey-3-tests/blob/79ee739a4870f4b495d1916c8e404fb13399f805/conftest.py#L63 https://github.com/Nitrokey/nitrokey-3-tests/blob/79ee739a4870f4b495d1916c8e404fb13399f805/utils/device.py#L167
mmmmh, docs, how about this one:
The idea of adding the UUID parameter was to make test execution on hardware more explicit to avoid accidental usage of a production device. This new target would reverse that. I’m not vetoing it if it is useful for you, but maybe the following approach would also work for you: We include an optional
variables.mk
that is not under version control in the mainMakefile
. In that file, you set the UUIDs of your development devices. This would still allow you to run the tests with a single command (after the initial setup) but would keep the additional safety of having to explicitly list the UUIDs at least once.