Automated release builds

[SpComb]

Expecting users to build the Go binaries and web assets from the sources is not cool.

Building release binaries by hand is not cool.

Needs a CI with automated builds :)

Ideally including a ready-to-install stateless rpi image using buildroot.

[SpComb]

Added release build scripts under https://github.com/qmsk/e2/tree/master/build, tagged the 0.2.2 release, and uploaded the release builds

@dougthebug do you want to test these?

Something along the lines of this incantation should be enough for a working setup on an rPI:

$ curl -vL https://github.com/qmsk/e2/files/468375/qmsk-e2_0.2.2_linux-arm.tar.gz | tar -C /opt -xzv && ln -s qmsk-e2_0.2.2_linux-arm /opt/qmsk-e2
...
$ ls -la /opt/                              
total 4
drwxr-xr-x 1 root root   64 Sep 12 21:14 .
drwxr-xr-x 1 root root  152 Sep 12 21:11 ..
lrwxrwxrwx 1 root root   25 Sep 12 21:14 qmsk-e2 -> qmsk-e2_0.2.2_linux-arm
drwxr-xr-x 1 1000 users  24 Sep 12 21:06 qmsk-e2_0.2.2_linux-arm
$ /opt/qmsk-e2/bin/tally --http-listen=:8001 --http-static=/opt/qmsk-e2/static 
2016/09/12 21:15:19 Serve static /static/ from /opt/qmsk-e2/static
2016/09/12 21:15:19 tally: Update: sources=0 inputs=0 outputs=0 tallys=0

Then it's just a question of configuring a systemd unit to start it at boot... There's an example at /opt/qmsk-e2/etc/systemd/system/qmsk-e2-tally.service, but it needs additional setup for the "User" and the GPIO pins used..

EDIT: linux-arm, not linux-amd64

EDIT: use the right release files URL

[dougthebug]

Works fine so far! I ran both client and server and from the above and both browser windows reconnected to the new service.

I did just experience a timeout on server, but it reconnected when I relaunched. I'll let this one burn in with no activity to see what happens.

I would advise that I had to use sudo on the second and third commands strung together in the first line.

[dougthebug]

I spoke too soon... after exactly five minutes the server crashed

2016/09/12 22:04:42 xmlClient.read: update 2016/09/12 22:04:42 client:TCPClient 192.168.1.27: recv: []string{"\x04ATRN", "-e", "0"} 2016/09/12 22:09:43 xmlClient.read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout 2016/09/12 22:09:43 server.Run: xmlClient.Read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout goroutine 8 [running]: runtime/debug.Stack(0x0, 0x0, 0x0) /usr/lib/go-1.6/src/runtime/debug/stack.go:24 +0x84 github.com/qmsk/e2/client.(_XMLClient).reader.func1(0x10714ac0) /home/build/go/src/github.com/qmsk/e2/client/xml.go:175 +0x138 panic(0x35e930, 0x10a7e000) /usr/lib/go-1.6/src/runtime/panic.go:443 +0x448 github.com/qmsk/e2/client.(_XMLClient).reader(0x10714ac0) /home/build/go/src/github.com/qmsk/e2/client/xml.go:194 +0x21c created by github.com/qmsk/e2/client.(*XMLClient).start /home/build/go/src/github.com/qmsk/e2/client/xml.go:153 +0x1cc pi@raspberrypi:~ $

[SpComb]

Updated the release URLs, I had uploaded the files as github markdown attachments, not github release binaries >_>

curl -vL https://github.com/qmsk/e2/releases/download/v0.2.2/qmsk-e2_0.2.2_linux-arm.tar.gz

I would advise that I had to use sudo on the second and third commands strung together in the first line.

Yeah, I'm not sure what a suitable distribution package format for generic use on rPIs is... @depili has something going on with buildroot to build an entire bootable rPI SD card image. We could perhaps also consider something like raspian .deb packages or even a Docker image.

I spoke too soon... after exactly five minutes the server crashed

2016/09/12 22:04:42 xmlClient.read: update 2016/09/12 22:04:42 client:TCPClient 192.168.1.27: recv: []string{"\x04ATRN", "-e", "0"} 2016/09/12 22:09:43 xmlClient.read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout 2016/09/12 22:09:43 server.Run: xmlClient.Read: read tcp4 192.168.1.25:40214->192.168.1.27:9876: i/o timeout

That's a timeout error on the XML connection. Did your network connection between the rpi server and your E2 break?

The tally binary handles E2 client disconnects by waiting for it to reappear. The server code is far more simple and only handles a single E2 client, and it exits if the client disconnects.

ATM this "crash fast" behaviour is more or less intentional, and you should use something like systemd to restart the service. The server itself is stateless, so it's more or less the same end result as handling reconnects within the code. Just far simpler than implementing the reconnect code.

[gerrylusk]

I just successfully installed this on a Raspberry Pi with a very basic Arch Linux build. Used the pre-built binaries and installed the required dependancies that Doug listed. A bit of arguing with Arch Linux regarding GPIO permissions, but that's expected. I now have tally for my e2 system.

I rarely post to these things but really wanted to say thanks for the tally code. And to Doug for the extra documentation. It all seems to work.

[dougthebug]

I’m glad you’re up on this Gerry!

I’ve got a few ideas for extending this with some Photons and a relay board, in addition to the GPOs on the Pi.

I’m also sitting in front of a BMD Tally for the week, which isn’t being used at all… I’d love to work out integrating that into this tally system.

-Doug

On Sep 18, 2016, at 8:27 PM, gerrylusk notifications@github.com wrote:

I just successfully installed this on a Raspberry Pi with a very basic Arch Linux build. Used the pre-built binaries and installed the required dependancies that Doug listed. A bit of arguing with Arch Linux regarding GPIO permissions, but that's expected. I now have tally for my e2 system.

I rarely post to these things but really wanted to say thanks for the tally code. And to Doug for the extra documentation. It all seems to work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qmsk/e2/issues/6#issuecomment-247905684, or mute the thread https://github.com/notifications/unsubscribe-auth/AHJoOZCPnaGRMMVJGxHwqzdzFhyMPIKCks5qrgESgaJpZM4J62is.

[SpComb]

I'll close this issue in favor of #10 and #11 now, as the builds themselves are done.

It would be good to have some updated install guide in the Wiki, for using the release tarballs vs building yourself.

I just successfully installed this on a Raspberry Pi with a very basic Arch Linux build. Used the pre-built binaries and installed the required dependancies that Doug listed.

Hmm... the release binaries should work as-is without any dependencies. You only need the Go/Bower dependencies if:

• you want to build/run a very specific version of the code
• you want to customize the source code

A bit of arguing with Arch Linux regarding GPIO permissions, but that's expected.

Did you run it as a non-root user? At least on raspian, there's a gpio group that has permissions for /sys/class/gpio, but you need to use the gpio-export.sh helper script to handle some race conditions with the udev setup.

I now have tally for my e2 system.

Great :)