gw
Watch local git repositories, keep in sync with remote and run commands.
Motivation
gw is a lightweight binary that manages a simple pull-based continuous deployment for you. It watches a local git repository, fetches if the remote changes, and builds or deploys your code. Current CD solutions either lock you into proprietary software (e.g. Netlify or Vercel) or complicated to run and manage (e.g. ArgoCD). gw is a service that can run everywhere (even behind NAT or VPN), synchronizes code with your remote and deploys immediately, saving your developers time and energy.
Features of gw:
- lightweight: it is only a 1.5MB binary (~7MB with git and ssh statically built-in)
- runs anywhere: use it on baremetal or systemd on Linux (x86_64 and ARM) or in Docker (Windows and MacOS is supported on a best-effort basis)
- open source: written entirely in Rust, you can build it from source in a few minutes
- pull-based: works on any network, even behind a NAT or VPN
- flexible: build, deploy, restart or anything you can imagine
If you want to see how gw compare to other products: look at the comparisons.
Installation
To get started with gw, you can use the install script:
|
For more installation methods, see the documentation.
Get started
gw is a simple program, that you can use to pull changes from a remote repository and run scripts on the change.
Prerequisites
First, make sure, that gw is installed successfully and is in your PATH:
The other necessary part is a git repository to which you have pull access. It is recommended to use a repository that you know, but if you don't have one at hand, you can use the daniel7grant/time repository. This is an example repository that is updated in every minute, so it is useful to test the auto update of gw. First clone this repository (if you are using your own, clone again), and enter the cloned directory:
Pull files automatically
To get started, point gw to this local repository. By default it pulls the changes every minute. We can add the --verbose or -v flag to see when the changes occur:
If you are using your own repository, create a commit in a different place, and see how it gets automatically pulled (in the case of the time repo, there is a commit every minute). The verbose logs should print that a git pull happened:
# ...
Also check the files or the git log to see that it the repository has been updated:
Run scripts on pull
Pulling files automatically is useful but the --script or -s flag unlocks gw's potential: it can run any kind of custom script if there are any changes. For a simple example, we can print the content of a file to the log with cat:
This will run every time there is a new commit, and after the pull it will print the file contents. You can see that the results are printed in the log:
# ...
You can add multiple scripts, which will run one after another. Use these scripts to build source files, restarts deployments and anything else that you can imagine.
Run subprocess, restart on pull
It is often enough to run scripts, but many times you also want to maintain a long-running process e.g. for web services. gw can help you with this, using the -p flag. This will start a process in the background and restart it on pull.
For example starting a python web server:
# ...
)
This will run a python process in the background and stop and start it again if a git pull happened. Just wrap your deployment script with gw and see it gets updated every time you push to git.
Run actions on tags
Pulling on every commit might not be the fit for every product, especially ones that needs to maintains compatibility or strictly versioned. For these, you can instead trigger on tags. Use the --on tag flag to only pull changes if there is a tag on the current branch.
# ...
This will always fetch the current branch, check for the latest tag on it and pull only the commits up to that tag. To match some kind of commit, you can use the --on tag:v* which will only pull if the tag is matching the passed glob (in this case starting with v).
Next steps
If you like gw, there are multiple ways to use it for real-life use-cases.
If you want to put the gw script in the background, you can:
- wrap into a systemd unit, if you want to manage it with a single file;
- start in a docker container, if you already use Docker in your workflow;
- or run periodically with cron, if you don't have shell access to the server.
If you are interested in some ideas on how to use gw:
- if you only need to pull files, see PHP guide;
- if you are using a dynamic language (e.g. JavaScript, Python, Ruby), see Guide for dynamic languages for example on running your process;
- if you are using a compiled language (e.g. TypeScript, Go, Rust), see Guide for compiled languages for example on compiling your program;
- if you use a
docker-compose.yaml, see Guide for docker-compose; - if you want to easily manage configuration files as GitOps, see Configuration guide;
- for a full-blown example, check out Netlify;
- and many other things, for the incomplete list guides page.