hyperledger-labs / fabric-smart-client / 33873004368
86%

DEFAULT BRANCH: main
Ran
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
33873004368

push

github

web-flow 
test(integration): keep the fabric and fabric-x tools apart under FAB_BINS (#1724)

Both toolchains ship a configtxgen and a cryptogen, and install-fabricx-tools
installed its own on top of fabric's: GOBIN was $(FAB_BINS), the very directory
install-fabric-bins unpacks the fabric distribution into. Whichever target ran
last won, so locally the two platforms could not be set up at the same time.

CI never noticed, because each matrix job installs exactly one toolchain.
Locally the state also never heals: download_fabric.sh gates its re-download on
`bin/peer version`, which the fabric-x install leaves untouched, so
install-fabric-bins reports "already downloaded" while configtxgen stays the
fabric-x build and every fabric-* suite fails generating artifacts.

Give the fabric-x tools their own subdirectory of FAB_BINS instead:

  $FAB_BINS/            fabric distribution (peer, orderer, configtxgen, ...)
  $FAB_BINS/fabric-x/   fabric-x tools (fxconfig, configtxgen, cryptogen)

Developers still export a single FAB_BINS, can run both install targets, and
neither disturbs the other. The lookup is a subdirectory, not a fallback: a
network that declares one never reads the other toolchain's binaries, so a
missing fabric-x tool is an error rather than a silent run of fabric's. The
fabricx platform needs nothing else from the parent directory -- it starts no
peers or orderers, and idemixgen is built from IBM/idemix.

The "could not find %s" messages now name the directory that was actually
searched rather than $FAB_BINS itself.

Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>
Source Files on build 33873004368
Detailed source file information is not available for this build.