When writing go, I've always found if I find myself constantly restarting & recompiling a program during development, it means that I should be writing tests instead.
Air – Live reload when developing with Go
11–20 of 46 posts
Re: Air – Live reload when developing with Go
#12```
filewatcher --immediate --restart "*/*.go" "killall ${BINARY_NAME}; make run"
```
Re: Air – Live reload when developing with Go
#13Useful tool, but it has some bugs related to consecutive build failures. Restarting Air is required to fix it. I still use it, just wish I didn't have to restart it frequently.
Re: Air – Live reload when developing with Go
#14I built something like this in Go a few years ago but it reloads your infrastructure when it changes, recompiles your code when it needs to, and syncs static files or interpreted files to wherever your app is running (desktop or cloud). Think of it like docker-compose but with file watching + sync + smart rebuilds. https://skaffold.dev/
Re: Air – Live reload when developing with Go
#15Earlier quoted context omitted.
That can’t handle file creation after the command is run, though, right?
I'm not sure about "find" -- but I also use "entr" for this (and just about a billion other tasks, is there anything you can't use it for?) and I personally do something like: ls src/**/*.filetype | entr -r -s "some command" And this will catch new files
Re: Air – Live reload when developing with Go
#16I built something like this in Go a few years ago but it reloads your infrastructure when it changes, recompiles your code when it needs to, and syncs static files or interpreted files to wherever your app is running (desktop or cloud). Think of it like docker-compose but with file watching + sync + smart rebuilds. https://skaffold.dev/
Is there a skaffold for borg that inspired this? Curious if there are any existing things you were inspired by, or particular pitfalls in alternatives you wanted to avoid!
(1) minikube, which I also maintained at Google. I saw how difficult getting started with Kubernetes could be even when you were able to create a local cluster. I also knew all the shortcuts that you could take to streamline local Kubernetes workflows (e.g., loading images directly into the minikube docker daemon).
(2) docker compose, which remains a great tool but had no analogue for Kubernetes. It also didn't have a concept of syncing for hot-reloadable projects or built-in file watcher.
(1), Draft by the Deis folks at Microsoft, which was a great tool but suffered from having a component that you needed to install on the cluster to work, where the skaffold architecture was purely client side (making it a lot easier to get started, and faster). I also wanted to make skaffold pluggable, so it supported helm, kubectl, docker, bazel, and other tools right from the start. It also had clear boundaries between build and deploy and ideas for CI and gitops workflows built in.
Re: Air – Live reload when developing with Go
#17 executable=/path/to/target
while true; do
make build
if [ ${?} -eq 0 ]; then
${executable} run &
pid=${!}
fi
inotifywait -qq -e create -e modify -e delete --exclude '\.#.*' -r .
[ -n "${pid}" ] && kill ${pid}; pid=
done
This is simplified a bit, as the script usually contains some other things like starting and initializing the database.Re: Air – Live reload when developing with Go
#18It's straightforward to use but also has a ton of options so you can do whatever you want with it. It also handles common issues you'll run into when working with larger codebases where you end up watching over too many files. And finally, it has configuration files so you can have the same setup as the rest of the engineers on your team.
More importantly, it's actively maintained and has been out for a while, and it's not specific to Go apps: you can use it for anything you want to watch and execute on.
Re: Air – Live reload when developing with Go
#19Re: Air – Live reload when developing with Go
#20I've found it simple enough to start a goroutine to watch argv[0] and exec it if it's newer than the startup time of the process. Unlike other languages with insane build and link times, I've never needed this for Go. Builds are nearly instantaneous.
We started using this tool a couple of months ago. It was a huge productivity boost. We had multiple binaries produced by the build and all had to run to make the complete service