Fix Docker build on ARM

[nguyer]

Resolves #469

[peterbroadhurst]

I'm really worried about how deep we're burying dependency information that needs to be regularly updated in the Dockerfiles at the moment.

Specifically:

• UI release version
• This pretty obscure tag that links to a particular (I assume ARM friendly) image of Golang

Can these be rolled up to the Manifest?

[nguyer]

It's a very good point. I think it's possible to pull these into the manifest if we are okay with moving beyond just a basic docker build ... command. Perhaps we can add a target to the Makefile for docker so the command just becomes make docker. And that script takes care of passing the versions from the manifest to here or wherever else they need to go.

[nguyer]

As an aside, this is just the sha for the x86_64 version of this image (which runs just fine on an M1 Mac). It is the same image that this Dockerfile would have picked if it were running on an x86_64 host.

[peterbroadhurst]

Think make docker sounds like a good approach.

Other option which would move forwards with this PR as is, is to put in the comments a repeatable instruction to find (without owning an M1 Mac) the reverse lookup to "what Go image is this?" and most importantly the next x86_64 image to apply a Go patch release (common security update requirement).

[peterbroadhurst]

Suggested change

	FROM golang@sha256:bab81aadc644eee23bafdf479e9bd60c418d405dbc79370ababbb2a2f88d8034 AS fabric-builder
	FROM --platform=linux/x86_64 golang:1.16-alpine3.13 AS fabric-builder

This seemed to work for this step for me @nguyer - I think it's doing the same thing as your change

[peterbroadhurst]

... please see the bigger thought, but most important thing needed for a merge here is an explanation in the code somewhere of how this Docker image was chosen and when it needs to be updated going forwards.

[peterbroadhurst]

@nguyer - I've submitted #484 as a PR to this branch, with the above discussion/suggestion, and a few other changes and updates to dependencies necessary for the build to work for me

[peterbroadhurst]

I note after my PR, I'm still seeing a failure from IPFS:

pbroadhurst@macbook-pro firefly_e2e % docker compose logs ipfs_0
firefly_e2e_ipfs_0  | Changing user to ipfs
firefly_e2e_ipfs_0  | ipfs version 0.11.0
firefly_e2e_ipfs_0  | generating ED25519 keypair...done
firefly_e2e_ipfs_0  | peer identity: 12D3KooWPgtHDht3oR2gmRRYzGzhH5UvS62NUN4fdtkdTBrLdBXK
firefly_e2e_ipfs_0  | initializing IPFS node at /data/ipfs
firefly_e2e_ipfs_0  | to get started, enter:
firefly_e2e_ipfs_0  | 
firefly_e2e_ipfs_0  | 	ipfs cat /ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc/readme
firefly_e2e_ipfs_0  | 
firefly_e2e_ipfs_0  | Copying swarm key from variable...
firefly_e2e_ipfs_0  | Initializing daemon...
firefly_e2e_ipfs_0  | go-ipfs version: 0.11.0-67220ed
firefly_e2e_ipfs_0  | Repo version: 11
firefly_e2e_ipfs_0  | System version: amd64/linux
firefly_e2e_ipfs_0  | Golang version: go1.16.7
firefly_e2e_ipfs_0  | 2022/02/07 01:37:09 [zeroconf] no suitable IPv4 interface: udp4: failed to join any of these interfaces: [{169 1500 eth0 02:42:ac:12:00:02 up|broadcast|multicast}]
firefly_e2e_ipfs_0  | 2022/02/07 01:37:09 [zeroconf] no suitable IPv6 interface: udp6: failed to join any of these interfaces: [{169 1500 eth0 02:42:ac:12:00:02 up|broadcast|multicast}]
firefly_e2e_ipfs_0  | 2022-02-07T01:37:09.907Z	ERROR	cmd/ipfs	ipfs/daemon.go:430	error from node construction: no supported interface
firefly_e2e_ipfs_0  | 
firefly_e2e_ipfs_0  | Error: no supported interface

[peterbroadhurst]

Workaround listed here: ipfs/kubo#8645 (comment)

[nguyer]

Yep I've run into the same thing and found that same thread. This is a firefly-cli issue. Shouldn't be too bad to implement but it's more than one line, since we're currently not writing a custom config file for IPFS. I'm going to look into this more tomorrow though.

[nguyer]

I pulled in changes from #484 as well

[codecov-commenter]

Codecov Report

Merging #473 (05eb881) into main (a3992b8) will increase coverage by 0.07%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main      #473      +/-   ##
===========================================
+ Coverage   99.92%   100.00%   +0.07%     
===========================================
  Files         266       267       +1     
  Lines       15134     15236     +102     
===========================================
+ Hits        15123     15236     +113     
+ Misses         11         0      -11     

Impacted Files	Coverage Δ
pkg/fftypes/event.go	100.00% <0.00%> (ø)
internal/assets/token_pool.go	100.00% <0.00%> (ø)
internal/batchpin/batchpin.go	100.00% <0.00%> (ø)
internal/broadcast/manager.go	100.00% <0.00%> (ø)
internal/contracts/manager.go	100.00% <0.00%> (ø)
internal/events/aggregator.go	100.00% <0.00%> (ø)
internal/restclient/config.go	100.00% <0.00%> (ø)
internal/restclient/ffresty.go	100.00% <0.00%> (ø)
internal/assets/token_transfer.go	100.00% <0.00%> (ø)
internal/txcommon/token_inputs.go	100.00% <0.00%> (ø)
... and 14 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a3992b8...05eb881. Read the comment docs.

[peterbroadhurst]

Think it might be worth the script checking if jq exists:

 if [[ ! -x `which jq` ]]; then echo "Please install \"jq\" to continue"; exit 1; fi

[peterbroadhurst]

Looks great!