Closed kriptor closed 3 years ago
Ugg, this is because of some weirdness with how Consul split their go.mod
file; it's confusing the version check in the Makefile in to thinking everything's OK when it's not. This is already fixed on AES's master
branch (by virtue of upgrading the Consul libraries) and will be fixed in 1.13.0; but we should fix the examples for 1.12, certainly.
The example plugins that don't use github.com/hashicorp/consul/*
should all work fine.
Is it possible to get a complete dependency graph of AES 1.12.2 for it seems quite impossible to successfully/correctly build any kind of non-trivial plugin?
Yes, so that's what it's doing when the Makefile runs:
docker run --rm --entrypoint=cat docker.io/datawire/aes:1.12.2 /ambassador/aes-abi.txt > aes-abi.txt
aes-abi.txt
is the definitive listing of what went in to the actual AES executable. Alternatively, if you don't want to trust that, you can run go version -m /path/to/file
on the /usr/local/bin/amb-sidecar
file from the AES image (go
is not installed in the image; you can apk add go
, or extract the file from the image).
@LukeShu thanks for the explanation, I appreciate it.
Hi,
I cloned the repo and did the following (under master branch):
Is
go.mod
correct?In my plugin I would actually like to use
... but it seems even the samples don't work.
Is it possible to get a complete dependency graph of AES 1.12.2 for it seems quite impossible to successfully/correctly build any kind of non-trivial plugin?
Thx