feat(weaver): add build script and fix minor issues

[outSH]

• Add a bash script in tools to build all the weaver packages in single command.
• Export getMSPConfigurations from fabric interop sdk (is imported in fabric cli, was causing compilation error on node 20)
• Move bash shebang to the top of check-nodes-status. On ubuntu 20 having this below was causing the file to be interpreted as sh (resulting in error)
• Update package-local.json files to be more inline with package.json.

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[outSH]

Hello @VRamakrishna @sandeepnRES, please review :)

More context on changes:

ad Add a bash script in tools to build all the weaver packages in single command.

• I've wanted to have a simple run-and-leave-for-coffee command for sanity checks of weaver build while I was working on TS upgrade PR, and didn't find anything suitable in weaver dir, so I've created this script - please double check if process is right and I haven't skip any packages. As noted in the comment I'm clearing node_modules in weaver because building it after cacti was causing some errors.

ad Update package-local.json files to be more inline with package.json.

• My understanding is that this file should be similar to package.json but used to build outside of cacti monorepo context (please correct me if I'm wrong).
• My intention was to add minimal nodejs / npm requriements (as done previously in package.json) to silent some warnings in newer node, but in the end I've noticed that there are more discrepancies between these two files. So, I've sync these files, except for:
  • references to local weaver packages in package-local.json
  • eslint-plugin-prettier which is 3.4.1 in package-local.json but 5.0.0 in package.json (upgrade caused compilation error, it's a way it already was done before my changes).

[sandeepnRES]

Hello @VRamakrishna @sandeepnRES, please review :)

More context on changes:

ad Add a bash script in tools to build all the weaver packages in single command.

* I've wanted to have a simple run-and-leave-for-coffee command for sanity checks of weaver build while I was working on TS upgrade PR, and didn't find anything suitable in weaver dir, so I've created this script - please double check if process is right and I haven't skip any packages. As noted in the comment I'm clearing node_modules in weaver because building it after cacti was causing some errors.

ad Update package-local.json files to be more inline with package.json.

* My understanding is that this file should be similar to package.json but used to build outside of cacti monorepo context (please correct me if I'm wrong).

* My intention was to add minimal nodejs / npm requriements (as done previously in package.json) to silent some warnings in newer node, but in the end I've noticed that there are more discrepancies between these two files. So, I've sync these files, except for:
  
  * references to local weaver packages in `package-local.json`
  * `eslint-plugin-prettier` which is `3.4.1` in `package-local.json` but `5.0.0` in package.json (upgrade caused compilation error, it's a way it already was done before my changes).

Thanks @outSH for the PR. Looks good to me just one thing you missed all the go packages (except one protos-go is there), not sure if it was intentional. Otherwise the PR looks good to me, given that CI tests are passing even after that package-local.json tests. So if you can confirm about go packages, I can approve the PR.

And to correct the package-local.json files are for building locally i.e. without not depending on the packages published in github. The default package.json files depends upon published github packages.
And that's the difference for every make build and make build-local in each module.

[outSH]

Thanks @outSH for the PR. Looks good to me just one thing you missed all the go packages (except one protos-go is there), not sure if it was intentional. Otherwise the PR looks good to me, given that CI tests are passing even after that package-local.json tests. So if you can confirm about go packages, I can approve the PR.

And to correct the package-local.json files are for building locally i.e. without not depending on the packages published in github. The default package.json files depends upon published github packages. And that's the difference for every make build and make build-local in each module.

@sandeepnRES Well, at first I wanted to just build basic scenarios, and then I wanted to make it into build script and I've forgot about go sdk (to be precise, you mean sdks/fabric/go-sdk and samples/fabric/go-cli?). When try to build go-cli now, I run into following error:

rm -rf ./bin
rm -rf vendor
go mod edit -replace github.com/hyperledger/cacti/weaver/common/protos-go/v2=../../../common/protos-go/
go mod edit -replace github.com/hyperledger/cacti/weaver/sdks/fabric/go-sdk/v2=../../../sdks/fabric/go-sdk/
go mod vendor
go: updates to go.mod needed; to update it:
        go mod tidy
make: *** [Makefile:15: run-vendor] Error 1

It seem to be caused by update of go-sdk dependencies in https://github.com/hyperledger/cacti/pull/2901. After go mod tidy the updates are applied in this go.mod as well, but I don't see an easy way to undo them (and keeping them breaks regular build based on remote version of sdk). I think the easy way would be to release latest go-sdk and use it here, but on the other hand would be nice to make this work even after dependencies are updated. Any suggestions? I don't really know golang and it's module system to well

[petermetz]

@outSH I like this a lot personally, but also I'll defer to @VRamakrishna and @sandeepnRES for final approval just to be sure they are OK with it too!

[sandeepnRES]

Thanks @outSH for the PR. Looks good to me just one thing you missed all the go packages (except one protos-go is there), not sure if it was intentional. Otherwise the PR looks good to me, given that CI tests are passing even after that package-local.json tests. So if you can confirm about go packages, I can approve the PR.
And to correct the package-local.json files are for building locally i.e. without not depending on the packages published in github. The default package.json files depends upon published github packages. And that's the difference for every make build and make build-local in each module.

@sandeepnRES Well, at first I wanted to just build basic scenarios, and then I wanted to make it into build script and I've forgot about go sdk (to be precise, you mean sdks/fabric/go-sdk and samples/fabric/go-cli?). When try to build go-cli now, I run into following error:

rm -rf ./bin
rm -rf vendor
go mod edit -replace github.com/hyperledger/cacti/weaver/common/protos-go/v2=../../../common/protos-go/
go mod edit -replace github.com/hyperledger/cacti/weaver/sdks/fabric/go-sdk/v2=../../../sdks/fabric/go-sdk/
go mod vendor
go: updates to go.mod needed; to update it:
        go mod tidy
make: *** [Makefile:15: run-vendor] Error 1

It seem to be caused by update of go-sdk dependencies in #2901. After go mod tidy the updates are applied in this go.mod as well, but I don't see an easy way to undo them (and keeping them breaks regular build based on remote version of sdk). I think the easy way would be to release latest go-sdk and use it here, but on the other hand would be nice to make this work even after dependencies are updated. Any suggestions? I don't really know golang and it's module system to well

Ah okay, I'll approve this PR, we can do that in another PR, I'll look into this why this is happening, ideally it should not

[petermetz]

LGTM!