I can't believe I am asking this but... It seems that in my dev environment on CLion, where I build then run, my changes work and all is well. I then go to a remote container where all my code is sync'd and I have built release binaries before. I execute cargo build --release. When I deploy the new binary, my output looks like none of the changes are in the binary. Does one have to exec cargo clean and the build release from the root of the project? Thanks as always.
No, cargo clean should never be necessary.
Cleaning might reveal that the binary you're running isn't the one you're rebuilding, though (because it will delete all the existing binaries).
If that's the case, it sounds like the correct way is to run cargo build release from the root of the project , such as, /Projects/my_rust_project cargo build --release. Correct?
I'm not sure what you're asking because I don't know what would be an incorrect way that you're comparing it to.
If you have a package or workspace (directory with Cargo.toml) then running cargo build --release anywhere inside it should result in binaries being built and placed in target/release/ at the root directory of the package or workspace.
Let me put it this way. When I run my dev version from JetBrains CLion and test, my results are what I expect after adding/changing the code. (I am polling devices across a network with snmp). When I build the binary and deploy the new binary, it appears that the changes are gone. My assumption was that it had to do with the way I was building the binary.
No. It shouldn't matter where your current working directory is, as long as it's within the project directory hierarchy. So building from eg the src/ subdirectory gives the same output as building from the project root.
Workspaces are a bit different though, but that's mostly because that's not really a crate and more a collection of crates that shares build artifacts.
1 Like
My assumption was that it had to do with the way I was building the binary.
In a situation like this, you need to take a troubleshooting approach and test your theories.
- Run
cargo cleanand redeploy, but do nothing else. Does that make a difference? If not, then lack of cleaning isn't the problem. - Does the source code that's in the container actually contain the changes you made? If not, then the problem must be somewhere “before” it in the pipeline/workflow. If so, then it has something to do with the build or the deployment of the built binary.
- And so on. Construct further hypotheses and test them.
2 Likes
It was my remote setup using a docker container as a remote staging for binaries. Kept sending the same "old" binary.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.