Use shared helper to build http client for log and run

[Doridian]

Also this fixes gok run building anything at all.

Looking at packer.Build in its current version, it just isn't suited to "build current directory" it seems. Or at least I could not find any way to get it to build local packages (such as . or ./package) no matter what I tried to pass to it from the gok run code. (I fully expect this to not just get merged as I put it, but rather invite a discussion on the correct way to fix gok run)

[stapelberg]

Thanks for your PR! We should probably split it up into separate PRs, but we can discuss first what needs to be done.

Also this fixes gok run building anything at all.

Looking at packer.Build in its current version, it just isn't suited to "build current directory" it seems. Or at least I could not find any way to get it to build local packages (such as . or ./package) no matter what I tried to pass to it from the gok run code. (I fully expect this to not just get merged as I put it, but rather invite a discussion on the correct way to fix gok run)

This bit I don’t understand. I use gok run all the time, and it works just fine to build the current directory? Most recently, I ran GOARCH=amd64 gok run -i router7 to deploy the Go program in the working directory to my router.

Can you describe in detail what you see that doesn’t work please?

[Doridian]

This bit I don’t understand. I use gok run all the time, and it works just fine to build the current directory? Most recently, I ran GOARCH=amd64 gok run -i router7 to deploy the Go program in the working directory to my router.

Can you describe in detail what you see that doesn’t work please?

(Note: I have GOARCH/GOOS/... set via export so I don't have to retype them constantly)

When I use gok run with the current version of gok, I first hit one issue (note: I used tls=self-signed to set up my instance, gokr-packer correctly uses the right TLS cert and functions. I assume if my appliance had a public hostname and default trusted cert, this would just work):

$ gok run --instance streamdeckpi
2022/09/09 06:21:24 basename: "agent"
[done] in 0.00s
2022/09/09 06:21:47 checking target partuuid support: Get "https://streamdeckpi/update/features": x509: “gokrazy” certificate is not trusted

If I fix that issue (which my PR was first meant to address with the httpClient things), I get hit by the next problem:

$ gok run --instance streamdeckpi
2022/09/09 06:26:21 basename: "agent"
[done] in 0.00s
2022/09/09 06:26:21 Using certificate /Users/doridian/Library/Application Support/gokrazy/hosts/streamdeckpi/cert.pem
2022/09/09 06:26:25 binary agent not installed; are you not in a directory where .go files declare “package main”?

(Quite simply, the packer.Build just builds nothing at all, and I quite definitely am inside a folder with package main), see:

$ go build . && file agent
agent: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=t-Ef-HUSrp9knXF8y_iO/jHutp5hou9sRr3gjE88i/U7xChbd3elYxoFohVaPI/idyzGdZyBk1v9icvhilD, with debug_info, not stripped

[stapelberg]

How can I reproduce this? Which repository are you working with? In which directory are you building?

[Doridian]

How can I reproduce this? Which repository are you working with? In which directory are you building?

For me, this reproduces in any (freshly cloned or not) repo (the below log is with the TLS error fixed, but the same goes for the TLS error). For example (note: I tested this with a folder named just hello as well, that does not fix it):

$ cd ~/Programming
$ git clone https://github.com/gokrazy/hello.git gokrazy-hello
Cloning into 'gokrazy-hello'...
remote: Enumerating objects: 8, done.
remote: Total 8 (delta 0), reused 0 (delta 0), pack-reused 8
Receiving objects: 100% (8/8), done.
Resolving deltas: 100% (1/1), done.
$ cd gokrazy-hello
$ gok run --instance streamdeckpi
2022/09/09 07:04:03 basename: "gokrazy-hello"
[done] in 0.00s
2022/09/09 07:04:03 Using certificate /Users/doridian/Library/Application Support/gokrazy/hosts/streamdeckpi/cert.pem
2022/09/09 07:04:07 binary gokrazy-hello not installed; are you not in a directory where .go files declare “package main”?

//EDIT: I should apologize, completely forgot my bug report 101 there to actually provide a repro, whoops.

As for versions: Everything is using a git main branch version, compiled locally.

$ uname -a
Darwin capefox 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
$ go version
go version go1.19 darwin/arm64

I use macOS, but I am pretty sure the error would also happen on Linux. I'll test this in Docker in a bit.

Yes, it happens in a very stock Linux as well (latest golang Docker image):

root@21ec47653bbb:/tmp# git clone https://github.com/gokrazy/tools
Cloning into 'tools'...
[...]
root@21ec47653bbb:/tmp# git clone https://github.com/gokrazy/hello
Cloning into 'hello'...
[...]

root@21ec47653bbb:/tmp# ls
hello  tools
root@21ec47653bbb:/tmp# cd tools/
root@21ec47653bbb:/tmp/tools# go build ./cmd/gok
root@21ec47653bbb:/tmp/tools# cd ../hello/

root@21ec47653bbb:/tmp/hello# GOARCH=arm GOARM=6 ../tools/gok run -i streamdeckpi
2022/09/09 14:16:54 basename: "hello"
[done] in 0.00s
2022/09/09 14:16:57 checking target partuuid support: Get "https://streamdeckpi/update/features": x509: certificate signed by unknown authority

[ repeat build steps for gok-tlsfix, except with my fixes for just TLS, and not packer.Build ]
[ See: https://github.com/Doridian/gokrazy-tools/tree/only-fixtls ]

root@21ec47653bbb:/tmp/hello# GOARCH=arm GOARM=6 ../tools/gok-tlsfix run -i streamdeckpi
2022/09/09 14:17:58 basename: "hello"
[done] in 0.00s
2022/09/09 14:17:58 Using certificate /root/.config/gokrazy/hosts/streamdeckpi/cert.pem
2022/09/09 14:18:02 binary hello not installed; are you not in a directory where .go files declare “package main”?

[stapelberg]

Thanks for the steps. Turns out the answer to “how can I reproduce this?” is “by building the gok program from the latest commit” — when I worked on commit c3979e1ceb3ea4fe02b78b2c1493c8128a5dc3f9, apparently I never re-compiled gok, which is why I didn’t notice the issue.

I have added an integration test to prevent such problems in the future, and pushed a fix.

Could you rebase your pull request please?

[Doridian]

Rebase complete. Tested locally on my Pi and run/logs still works.

[Doridian]

New PR for the HTTPClient functionality only: https://github.com/gokrazy/internal/pull/14 Will have to update this PR once that one is merged for the go.mod hash.

[stapelberg]

Now merged! Also did a go mod tidy.

[Doridian]

PR rebased ontop of main with updated internal repo hash.