This is one project that keeps getting put on the back-burner, despite the fact that it is really important. The deployment tool will allow us to deploy all software projects to their respective targets automatically.
Some code for this project has already been completed, under src/tool/deploy.rs. Use this as a starting point. The deployment tool should:
Locate all relevant devices on the network by their hostnames. (ex. sam-01, sam-02, flight-01, ground-01, server-01, gui-01, gui-02)
Download and cache the main branches of all relevant repositories, based on the active hostnames found. (ex. servo, flight)
Download and bundle dependencies for offline compilation (see cargo vendor). Targets are not expected to have Internet access.
Compress and transfer repo files to the relevant machines (see SCP, SSH, existing code).
Instruct the remote machine to compile the program in release mode.
Instruct the remote machine to automatically run the new compiled binary at startup. If there is a previous, outdated binary also set to be run at startup, remove it. The only exception to this is the GUI.
If you think it may be better to cross-compile for the remote machine and then transfer the binary, that was my thought initially too. There are many problems with it, mainly having to do with libraries that depend on libc. PyO3 is especially difficult when it comes to this. We have settled on compiling it on the target, and it must do this completely autonomously without any Internet access or human interaction on the target.
Each of these steps generally takes a while. The user running this tool must have feedback on what stage they are currently in. Use jeflog::task! and the associated pass!, fail!, and warn! macros to convey this. See examples in the existing code.
Test this on your own machine. Add localhost as a custom target when you're testing at home and ensure that the tool can reliably compile for your own computer. When in ESM, especially at the weekly project meeting, make sure that it works with all of the other hardware.
This is legitimately an extremely important project that all of AVI has been asking about for a while. It saves us a ton of time at testing, and it could prevent catastrophic issues related to versioning during hot-fires and launches.
This is one project that keeps getting put on the back-burner, despite the fact that it is really important. The deployment tool will allow us to deploy all software projects to their respective targets automatically.
Some code for this project has already been completed, under
src/tool/deploy.rs. Use this as a starting point. The deployment tool should:sam-01,sam-02,flight-01,ground-01,server-01,gui-01,gui-02)servo,flight)cargo vendor). Targets are not expected to have Internet access.If you think it may be better to cross-compile for the remote machine and then transfer the binary, that was my thought initially too. There are many problems with it, mainly having to do with libraries that depend on libc. PyO3 is especially difficult when it comes to this. We have settled on compiling it on the target, and it must do this completely autonomously without any Internet access or human interaction on the target.
Each of these steps generally takes a while. The user running this tool must have feedback on what stage they are currently in. Use
jeflog::task!and the associatedpass!,fail!, andwarn!macros to convey this. See examples in the existing code.Test this on your own machine. Add
localhostas a custom target when you're testing at home and ensure that the tool can reliably compile for your own computer. When in ESM, especially at the weekly project meeting, make sure that it works with all of the other hardware.This is legitimately an extremely important project that all of AVI has been asking about for a while. It saves us a ton of time at testing, and it could prevent catastrophic issues related to versioning during hot-fires and launches.