tiny-pilot
Re-define development workflow to test changes on device
The /dev-scripts/remote-scripts folder is currently referenced in the Contributing guide lines, but we don’t use this workflow anymore. They also won’t work anymore with the new update mechanism, because there is no git repository on the device anymore.
I’m currently using a custom helper script to sync local changes up to the device. I found that pretty convenient, because it performs all necessary steps via a single command.
It would be cool to have something like this for the new update mechanism. I’d see the following requirements:
- Single command to sync local changes up to device, e.g. via ssh/rsync
- Doesn’t break dev-prod parity, so e.g. excludes non-production files in the same way as the bundler does
- Reasonably fast execution time – like, 5 seconds would be totally acceptable, but it shouldn’t run half a minute
- It should primarily sync the
tinypilot/tinypilot-proapp. For changes in Ansible, we already have a way to run the playbooks from the dev machine. - Bonus-points for a watcher, or some other useful automatism. (Though that’s probably a nice-to-have.)
Original “survey”
- First question: (cc @jdeanwallace, @mtlynch) is anyone still using these remote scripts?
- I personally don’t use them anymore (though I have used them in the beginning).
- Second question: shall we document the default/canonical way to push code changes to the device?
- I’d say yes.
- Third question: what is the default way to push local code changes to the device?
- I use
rsyncand composed a local helper script for myself for convenience (I sync from my machine to the device). That worked quite well for me. This will not work with the update overhaul anymore, though, at least not flawlessly, because we strip a lot of files from the bundle. One could argue the excluded files are non-production files anyway, so it wouldn’t matter if they are synced to the device. But it’s still not optimal. A potential solution could be a transient/intermediate docker step, that pushes all files through Docker (and thus.dockerignore) before syncing them up.
- I use
First question: (cc @jdeanwallace, @mtlynch) is anyone still using these remote scripts?
No, I never ended up using these. I don't think I move code to devices enough to have a regular workflow.
Second question: shall we document the default/canonical way to push code changes to the device?
Yeah, I think that's a good idea.
Third question: what is the default way to push local code changes to the device?
If I were doing it, I think I'd just create a bundle and then install that on the target device, but that's pretty slow.
Your script looks straightforward, so I support making that the official way if Jason doesn't have a way he likes better.
First question
No, I'm not using it anymore.
Second question
Yeah that would be useful.
Third question
I haven't really thought about it yet, but your script looks cool. I would also prefer a quick way to bundle up the code and install it the "official" way (i.e. Debian package), but I don't think that's feasible anymore.
Would be cool to add a watcher type thing to your script and let it sync automagically too 🙌
Cool, thanks for your thoughts. I’ve updated the ticket description, and tried to make the ticket actionable.
As always, feel free to edit/adjust/extend the requirements list.
I wanted to gently bump this up again, because I think having robust and well-defined testing procedures would be very helpful. Especially when working on more complex changes, e.g. in the ansible repositories, it could save us time if we had an out-of-the-box way to build and install an (experimental) installation bundle on a device.
I'm going to push this until 2.6.0. The priority right now is getting to Bullseye + audio capture. I'd like to minimize the lag between when our hardware is audio-ready but our software isn't.
A note just for reference: by now, we already have a dev convenience script to install a bundle from a device (via https://github.com/tiny-pilot/tinypilot/pull/1246).