Giter Site home page Giter Site logo

go-watcher's Introduction

Watcher GoDoc Build Status

Watcher is a command line tool inspired by fresh and used for watching .go file changes, and restarting the app in case of an update/delete/add operation.

Most of the existing file watchers have a configuration burden, and even though Go has a really short build time, this configuration burden makes your binaries really hard to run right away. With Watcher, we aimed simplicity in configuration, and tried to make it as simple as possible.

Installation

Get the package with:

go get github.com/canthefason/go-watcher

Install the binary under go/bin folder:

go install github.com/canthefason/go-watcher/cmd/watcher

After this step, please make sure that your go/bin folder is appended to PATH environment variable.

Usage

cd /path/to/myapp

Start watcher:

watcher

Watcher works like your native package binary. You can pass all your existing package arguments to the Watcher, which really lowers the learning curve of the package, and makes it practical.

Current app usage

myapp -c config -p 7000 -h localhost

With watcher

watcher -c config -p 7000 -h localhost

As you can see nothing changed between these two calls. When you run the command, Watcher starts watching folders recursively, starting from the current working directory. It only watches .go and .tmpl files and ignores hidden folders and _test.go files.

Package dependency

By default Watcher recursively watches all files/folders under working directory. If you prefer to use it like go run, you can call watcher with -run flag anywhere you want (we assume that your GOPATH is properly set).

watcher -c config -run github.com/username/somerootpackagename

For the cases where your main function is in another directory other than the dependant package, you can do this by passing a different package name to -watch parameter.

watcher -c config -run github.com/username/somerootpackagename -watch github.com/username

Vendor directory

Since Globs and some optional folder arrays will make it harder to configure, we are not planning to have support for a configurable watched folder structure. Only configuration we have here is, by default we have excluded vendor/ folder from watched directories. If your intention is making some changes in place, you can set -watch-vendor flag as "true", and start watching vendor directory.

Watcher in Docker

If you want to run Watcher in a containerized local environment, you can achieve this by using canthefason/go-watcher image in Docker Hub. There is an example project under /docker-example directoy. Let's try to dockerize this example code first.

In our example, we are creating a server that listens to port 7000 and responds to all clients with "watcher is running" string. The most essential thing to run your code in Docker is, mounting your project volume to a container. In the containerized Watcher, our GOPATH is set to /go directory by default, so you need to mount your project to this GOPATH.

docker run -v /path/to/hello:/go/src/hello -p 7000:7000 canthefason/go-watcher watcher -run hello

Containerized Watcher also supports different versions of Go by leveraging gvm. Currently it only supports major versions right now. If you don't set anything, by default Watcher will pick version 1.7. If you want to change the Go version, you can use GO_VERSION environment variable. Currently it only supports 1.4, 1.5, 1.6, 1.7 at the moment

docker run -v /path/to/hello:/go/src/hello -e GO_VERSION=1.6 -p 7000:7000 canthefason/go-watcher watcher -run hello

To provide a more structured repo, we also integrated a docker-compose manifest file. That file already handles volume mounting operation that and exposes the port to the localhost. With docker-compose the only thing that you need to do from the root, invoking `docker-compose up

Known Issues

On Mac OS X, when you make a tls connection, you can get a message like: x509: certificate signed by unknown authority

You can resolve this problem by setting CGO_ENABLED=0 golang/go#14514 https://codereview.appspot.com/22020045

Author

License

The MIT License (MIT) - see LICENSE.md for more details

go-watcher's People

Contributors

canthefason avatar lizrice avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

go-watcher's Issues

Missing WORKDIR leads to building failure

I was testing your Docker right now and I was having a weird issue. Even if I mapped the Volume correctly, I was having this output by watcher:

can't load package: package .: no buildable Go source files in /go

Then after some trials, I found that the issue was mainly because you're missing the WORKDIR declaration in the Dockerfile.

For now I fixed it by declaring it on the docker run command line, although would be nice to have it directly there.

Thanks again and keep up with this awesome project :)

Use an idempotent, predictable output filename to prevent firewall warnings

It seems this is unmaintained but figured I'd raise this anyway.

A reason I usually go build -o app.exe ; ./app.exe is to keep security software from treating each compilation as a new binary (because it uses a temporary directory). Otherwise, if the application wants access to certain resources such as network sockets, webcams, sound, etc. then you must hit "allow access" for every compilation.

I went to try this app, and it seems it also uses a different output name for every compilation. Resulting in this:

image

It also doesn't seem to clean up these temporary binaries, which has resulted in my %userprofile%/go/bin directory filling up with executables named watcher-.-(random ID).

Building with Go 1.20.1: flag provided but not defined: -i

It seems that the watcher can no longer be used with the newest version of Go 1.20.1

The problem is that up until now the -i flag was deprecated and using it gave a warning, but the watcher was successfully building the binary.

From Go 1.20.1 the watcher no longer works, because using the -i flag returns an error, not a warning:

myservice  | flag provided but not defined: -i
myservice  | usage: go build [-o output] [build flags] [packages]
myservice  | Run 'go help build' for details.
myservice  | A build error occurred. Please update your code...

Can you please update the code or would you accept a PR that does that? Thank you!

Does someone know of a alternative similar to the go-watcher which is maintained and supports new Go versions?

Cannot use watcher in MacOS Mojave

Hello, first of all, I'm sorry for my English, I had help from Google Translator ... rsrs

I'm trying to use your library on MacOS Mojave. For this I followed exactly as it is in README.md:

  • I installed the package through the command: go get github.com/canthefason/go-watcher
  • I installed the binary through the go install github.com/canthefason/go-watcher/cmd/watcher command

But even so it was not possible to run the watcher command on the terminal.

Could you help me, please?

startcmd ignores keepalive

Hi,

first of all, thanks for implementing a watcher, which is as small and concise, as I want it to be!!

I've found a little bug in my humble opinion, though:

If you start the watcher with keepalive flag and startcmd flag, and the command returns a non zero.

watcher -cmd="false" --keepalive --startcmd

Windows: Only one usage of each socket address (protocol/network address/port) is normally permitted.

My go app is a http server with go routines.
When I run it the first time it's fine

watcher -c config -p 7777 -run /c/Projects/go/src/gitlab.com/jeremyjohn/http-project -watch gitlab.com/jeremyjohn/http-project

It starts two watcher-http-project process up and the main watch process.

But after changes to a .go file i get this error

2019/08/16 23:05:15 build started
Building C:/Projects/go/src/gitlab.com/jeremyjohn/http-project...
2019/08/16 23:05:16 build completed
Running C:/Projects/go/src/gitlab.com/jeremyjohn/http-project...
2019/08/16 23:05:16 listen tcp :7007: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Add ability to run with -race

As far as I can see there is no option to build Go binaries with the -race flag set; the go build command is hard-coded as:

cmd, err := runCommand("go", "build", "-i", "-o", fileName, pkg)

did I miss something?

Could this option be added? Perhaps it would be good to allow passing arbitrary flags to go build; maybe after --?

watcher -c appflag -run example.com/pkg -- -race

Or maybe something like?

watcher -c appflag -run example.com/pkg -buildflags '-race'

Slow down building process a bit?

Great tool, though there's one big problem. I use other watcher (go-razor's templates watcher) which builds .go templates on change, but seems like 99% of the time go-watcher can't yet get changed templates so it rebuilds with an old version. Maybe there's a quick fix (timeout) for this? Thanks.

Add polling

On Windows using Docker inotify from the filesystem won't pick up changes. Can you add an option for polling changes?

Wrong test labelling

I was reading the unit test file you've made, and I found a wrong labelling I guess.

At this line you wrote:

expected true, got false

for the .md file. But I guess it should be ( looking at the IF condition ):

expected false, got true

right?

Add an option for sending SIGINT instead of SIGKILL

With each file change, we are sending SIGKILL command for killing the running process. The problem is, it would leave some open connections behind. For the programs that require graceful shutdowns, it is better to have an optional SIGINT support for go-watcher.

Dockerfile without VOLUME

I was wondering how to use your Docker, if you didn't declare a Volume. Which will be the path that it will watch? Can you add support for Volumes? Would be a nice-to-have feature :)

Best regards,
Julian

Panic when running watcher

Hi, I have a panic when I run go-watcher

go env

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/alex/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/alex/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build165720837=/tmp/go-build -gno-record-gcc-switches"

Command

$ watcher

Error

2018/03/11 19:40:05 Could not run the go binary: exec: "-.-785150": executable file not found in $PATH 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x46ef4e]

goroutine 7 [running]:
os.(*Process).signal(0x0, 0x502320, 0x56c0e8, 0x0, 0x0)
	/usr/lib/go/src/os/exec_unix.go:56 +0x2e
os.(*Process).Signal(0x0, 0x502320, 0x56c0e8, 0xc42008e100, 0xc420090120)
	/usr/lib/go/src/os/exec.go:129 +0x3f
os.(*Process).kill(0x0, 0xc4200900f0, 0x2)
	/usr/lib/go/src/os/exec_posix.go:54 +0x43
os.(*Process).Kill(0x0, 0x0, 0x54)
	/usr/lib/go/src/os/exec.go:114 +0x2b
github.com/canthefason/go-watcher.(*Runner).kill(0xc42000a160, 0xc4201122c0)
	/home/alex/go/src/github.com/canthefason/go-watcher/run.go:66 +0x41
github.com/canthefason/go-watcher.(*Runner).Run(0xc42000a160, 0xc42000a0c0)
	/home/alex/go/src/github.com/canthefason/go-watcher/run.go:39 +0x211
created by main.main
	/home/alex/go/src/github.com/canthefason/go-watcher/cmd/watcher/main.go:17 +0x110

If you want to reproduce I just listen on a tcp socket. You can ask for anything else.

Could not run the go binary

taras@taras-Z370-HD3P /media/taras/Storage/source/server-panel $ watcher
2018/02/10 17:52:26 build started
Building ....
2018/02/10 17:52:27 build completed
Running ...
2018/02/10 17:52:27 Could not run the go binary: exec: "-.-533426": executable file not found in $PATH
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4718b8]

goroutine 7 [running]:
os.(*Process).signal(0x0, 0x573800, 0x5720e8, 0x0, 0x0)
/usr/local/go/src/os/exec_unix.go:56 +0x38
os.(*Process).Signal(0x0, 0x573800, 0x5720e8, 0x54, 0xc420082180)
/usr/local/go/src/os/exec.go:121 +0x3f
os.(*Process).kill(0x0, 0xc4200840f0, 0x2)
/usr/local/go/src/os/exec_posix.go:53 +0x43
os.(*Process).Kill(0x0, 0x0, 0x54)
/usr/local/go/src/os/exec.go:106 +0x2b
github.com/canthefason/go-watcher.(*Runner).kill(0xc42000a500, 0xc42014e160)
/home/taras/go/src/github.com/canthefason/go-watcher/run.go:66 +0x41
github.com/canthefason/go-watcher.(*Runner).Run(0xc42000a500, 0xc42000a080)
/home/taras/go/src/github.com/canthefason/go-watcher/run.go:39 +0x23c
created by main.main
/home/taras/go/src/github.com/canthefason/go-watcher/cmd/watcher/main.go:17 +0x120

MacOS Catalina: Does not work

It does not work with the following message:

$ watcher
2019/10/24 21:02:15 build started
Building ....
2019/10/24 21:02:17 build completed
Running ...
2019/10/24 21:02:17 process interrupted: signal: killed

Other people from my team who upgraded to Catalina report the same

$ go version
go version go1.12.9 darwin/amd64

vim file jumping

Hi,

I'm using vim to write my .go files and the default behavior of vim is the following:

- write buffer to new file
- delete the original file
- rename the new file

I therefore get a lot of this:

Building project/something...
can't load package: package project/something: no Go files in /home/roland/go/src/project/something
An error occurred while building: exit status 1

My guess is that this has something to do with timers. Your watcher seems to update faster than vim writes/moves the file. Is there any way to modify that?

Clear terminal output on re-build

It would be helpful for readability if there was a flag that would tell watcher to clear the terminal when a re-build was started.

If there is a work around that exists currently, please let me know!

need to run above src directory

I'm trying to use watcher with a REST server. I have src and public directories in the application directory. It seems I can't run the watcher command from the application directory and must instead run it from the src directory. But this causes an issue with serving static files because my server expects to find those in ./public, not ../public. Is there any way I can tell watcher to watch the files in src and start it from my application directory?

Travis build fails due Go version

Travis is currently building on versions 1.5 and 1.6 of Go, however runtime.KeepAlive is only present in versions 1.7+ of Go, as referenced here.

This is making most builds fail I think. Error can be seen for the missing field here

# golang.org/x/sys/unix

../../../golang.org/x/sys/unix/ioctl.go:18: undefined: runtime.KeepAlive

../../../golang.org/x/sys/unix/ioctl.go:28: undefined: runtime.KeepAlive

../../../golang.org/x/sys/unix/syscall_linux.go:99: undefined: runtime.KeepAlive

github.com/canthefason/go-watcher/docker-examples/hello

github.com/canthefason/go-watcher/vendor/gopkg.in/fsnotify.v1

The command "eval go get -v -t ./... " failed. Retrying, 2 of 3.

Is this still maintained?

I've seen no new commits in a number of years and as newer go versions are released issues are being encountered here.

Can't find fsnotify

Getting errors while on go get:

build github.com/canthefason/go-watcher/cmd/watcher: cannot load gopkg.in/fsnotify.v1: cannot find module providing package gopkg.in/fsnotify.v1

Could this one be related?

Run go get as part of containerized version

Nice tool!

I'm looking at the containerized version and I'd like to add a step to do go get (to get the dependencies installed into the file system on the container). A very little local testing suggests this could be achieved by adding go get ./... just before the exec line in entrypoint.sh.

Happy to do a PR but I thought I'd run the idea past you first. Wdyt?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.