Refactor repository structure to adhere to new crate names and rust subfolder #157
Refactor repository structure to adhere to new crate names and rust subfolder #157soenkeliebau merged 35 commits intomainfrom
Conversation
…r and renamed crates: - operator -> operator-lib - server -> operator
1. replace all occurrences of `server/Cargo.toml` with `rust/operator/Cargo.toml` in ci scripts (4 occurrences for Kafka) 2. Change occurrences of -server in following files: deny, 2mal docker, build artifacts, stackable-kafka-operator-server.service, rust/operator/cargo.toml, assets in cargo.toml 3. Rename rust/operator/packaging/rpm/SOURCES/stackable-kafka-operator-server-VERSION/usr/lib/systemd/system/stackable-kafka-operator-server.service to stackable-kafka-operator.service Also remove server from path to that file 4. Add extra ../ to assets paths in Cargo.toml for operator 5. Rename rust/operator/packaging/rpm/SPECS/stackable-kafka-operator-server.spec
djc
left a comment
djc
left a comment
There was a problem hiding this comment.
What is the reason not to put the server/src/main.rs in the operator-lib crate? Crates can contain a library and any number of binaries, which would mean you don't have to have the ugly -lib suffix.
I'll leave this for @lfrancke to answer, as he was the only one who had a preference either way. My reasoning why this could make sense was that the Also, depending on the way the operator evolves, I can't say with certainty, that there will never be any other operators depending on it in the form of a library. So to me this was just a precaution to keep things more separate just in case. |
…_refactor_structure
…hat runs to test if the ci run was started from a forked repo.
backstreetkiwi
left a comment
backstreetkiwi
left a comment
There was a problem hiding this comment.
The PR binaries worked on CentOS 7, CentOS 8 and Debian 10 in test environments created using T2
5 participants
Description
stackabletech/issues#88
Review Checklist