It appears the exception is thrown in
src\main\java\com\daml\FabricContext.java
Line 229
private void runChannel(Collection<Peer> peers, LifecycleChaincodePackage lifecycleChaincodePackage {
...
catch (Exception) {
debugOut("Caught an exception running Channel %s, fabChannel.getName());
e.printStackTrace();
}
I also checked
~/daml-on-fabric/src/test/fixture/chaincode/src/github.com/daml_on_fabric/
but could only find vendor
sub-directory with 1 empty file
NO_AUTO_COPYRIGHT
I believe the root cause here is the Docker build failure, i.e.
Get "https://proxy.golang.org/github.com/golang/protobuf/@v/v1.4.2.mod": EOF
My recommendation would be to check whether your corporate proxy allows you to connect to proxy.golang.com.
If I could find in the code where this get triggered then this will help me. I could change curl
to curl -sSLk
and that command will be allowed to go through the corporate proxy.
I just tested in this environment and
curl -sSLk "https://proxy.golang.org/github.com/golang/protobuf/@v/v1.4.2.mod"
returned
module GitHub - golang/protobuf: Go support for Google's protocol buffers
go 1.9
require (
GitHub - google/go-cmp: Package for comparing Go values in tests v0.4.0
protobuf module - google.golang.org/protobuf - Go Packages v1.23.0
)
1 Like
This log line may not come from curl
; I’m not very familiar with the go ecosystem, but I wouldn’t be surprised if the download was done by a custom-built go dependency-management tool. I don’t have much context here but I would try two lines en enquiry if I had access to your system:
- If I could get access to the Dockerfile that fails to build, I would try to just add a few lines in it to set the env vars for proxying (
http_proxy
, HTTP_PROXY
, https_proxy
and HTTPS_PROXY
, all with the same value) and hope the go tooling respects that.
- Look through the Docker documentation to see if maybe you can set this up at the Docker daemon level. You can’t be the first person that needs Docker to go through a proxy; maybe this can be set directly in the configuration of the Docker virtual network.
It’s been a long time since I had to deal with a corporate proxy so I’m a bit rusty on that front. I am not confident either of these approaches will solve the problem, but they’re the best options I can think of at this point.
1 Like