mkantor
commented
4 years ago It's worth noting that some of the tests and samples expect a POSIX-compliant environment (due to shell scripts), and some go even further and use common-but-not-technically-in-the-spec things like /dev/urandom.
If this ends up being an issue, some potential mitigations include:
- Dumb down the samples/tests as much as is necessary so that they work on all major platforms.
- Rewrite all scripts in samples/tests using a more portable language that's easy to install on all platforms (say, Python). Document that you need a runtime for that language on your system if you want to run the samples/tests.
- Containerize the samples and run them in a known environment. Document that you need Docker (or another container runtime) to use them.
- Make any affected tests conditional on the platform, simply do not run them (or run an alternate test) on platforms that do not meet the requirements.
Remember that making Operator cross-platform doesn't necessarily imply making the development environment for Operator cross-platform, though that would definitely be handy when addressing platform-related issues.
The way that the content directory is loaded expects Unixy filesystem semantics (e.g. executeableness indicated by a permission bit,
/as the path separator, etc). There may be other platform-specific stuff in the codebase too (so far I've only developed/run Operator on macOS and Ubuntu).I don't think it'll be difficult to make things more portable, but CI should be set up to run checks on multiple platforms so that once things are working they stay working.