-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go modules for fabric #954
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Option 2 worked locally. 2Qs:
|
added gossip flake to https://jira.hyperledger.org/browse/FAB-17451 /ci-run |
AZP build triggered! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand it's a WIP but it should not be merged. There a number of hacks in here that have some unsavory side effects.
I've dusted off my previous work and I think (go figure) it's a better path forward.
https://github.com/sykesm/fabric/commits/modules-playground-2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for review @sykesm
What's left in https://github.com/sykesm/fabric/commits/modules-playground-2
I'll give it a run and see what shakes out.
|
@MHBauer - Some of the prep changes have been merged into master. Are you planning to continue this thread by implementing some of the remaining items I enumerated above? Also, with respect to the vendor vs. non-vendor: You're assuming that the modules required for a fabric build will be cached. While that's true for most local development, it's not generally true. For example, our docker images are built within an alpine container that has no cache. That means each time we build a binary, we go off to get all of the packages we need for build. The time it takes can vary widely depending on where you are in the world and what the network looks like. I'd also assert that vendored packages help when doing code-scans and reproducible builds when building with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
flake, but the dependencies look weird to me from the tools update.
go.mod
Outdated
go.uber.org/atomic v1.4.0 // indirect | ||
go.uber.org/multierr v1.2.0 // indirect | ||
go.uber.org/tools v0.0.0-20190618225709-2cfd321de3ee // indirect | ||
go.uber.org/zap v1.11.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
especially weird that this would go backwards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you look at sykesm@1493171 ?
Part of https://github.com/sykesm/fabric/commits/modules-playground-4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, you did the tools first. I can slap the third commit for the verify on top of those two and give it a go.
I'm worried about what happens in a clean environment in terms of it changing go.mod when building the tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a CRLF git issue with
vendor/github.com/Knetic/govaluate/.gitignore
but otherwise got it cleanly building.
Looks to work in the build as well, besides some gossip flaknes: https://dev.azure.com/mbauer0254/fabric/_build/results?buildId=4&view=results
I'll push a modified rebase with everything, and you can check it out or modify it yourself on my fork, or push your own. Let me know what you want to do.
github.com/vektra/mockery v0.0.0-20181123154057-e78b021dcbb5 | ||
golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f | ||
golang.org/x/tools v0.0.0-20191227053925-7b8e75db28f4 | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I get it now, a separate module for the tools.
_ "github.com/vektra/mockery/cmd/mockery" | ||
_ "golang.org/x/lint/golint" | ||
_ "golang.org/x/tools/cmd/goimports" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this going to need to be vendored as well?
I can repro a bunch of other flakes, but not this one. /ci-run |
AZP build triggered! |
Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com> Change-Id: I6e0b4666e12aec65ed9e3f2f6b871cd942ca66d9
original has crlf Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com> Change-Id: I2212e14f574d9e2c3d870bd718aee50ebcf1fc85
Change-Id: Iad450b21a63156a73b4299fbc22745cd2fe96e1f Signed-off-by: Morgan Bauer <mbauer@us.ibm.com>
Looks mostly superceded by #1064, but it doesn't look like we actually care about replicating check-deps. |
wip
Type of change
Improvement - Infrastructure/Build
don't carecheck_deps.sh
checking implemented with modules baseTools are installed into $(go env GOPATH)/bin. That's problematic in cases where $GOPATH is really a path or when $GOPATH is not on the $PATH.
more?
Description
Would like to use some of fabric as a dependency for golang plugins.
Additional details
pkcs11 unit-tests always fail for me. On master and this branch.
idemix integration-tests always fail for me. On master and this
branch.
Completed work:
Related issues
https://jira.hyperledger.org/browse/FAB-10562
A
tools.go
based dependency management.https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module