bazel build gives "Argument list too long" error - go

Trying to build go application using bazel. It fails due to multiple packages and source files present within the application.
OS: Mac OS (High Sierra)
Bazel version : 0.11.1 (homebrew)
Go rules: 0.11.0
Defined local_repository in WORKSPACE to get external dependencies
Running following command
bazel build //go-app
leads to error
Action failed to execute: java.io.IOException: Cannot run program
"/usr/bin/sandbox-exec" (in directory
"/TEMP_DIR/PATH"):
error=7, Argument list too long
Target //go-app:go-app failed to build
I came across https://docs.bazel.build/versions/master/skylark/lib/Args.html#use_param_file and thought it would fix my issue. Could anyone point me in the direction of how and where to implement this in my BUILD file and make it work? Thanks.

I think it's not in your BUILD file but rather in rules_go.
I'd recommend opening them an issue since AFAIK this is something the rule implementation needs to support.
For example in rules_scala we write the arguments to a file and then pass that file to the worker exactly like how you mention above.
https://github.com/bazelbuild/rules_scala/blob/master/scala/private/rule_impls.bzl#L274

Related

No version set for command go

I attempted to check the version of my go executable with go version on an Ubuntu machine, however I got the following error:
No version set for command go
Consider adding one of the following versions in your config file at
golang 1.16.8
golang 1.17.1
How do I resolve this? I have no prior experience with config file, I searched on google but I found nothing which could solve this issue.
That seems to be an error message from asdf-vm/asdf, a tool which manages multiple runtime versions with a single CLI tool, extendable via plugins.
You can see that error message in asdf-vm/asdf issue 838.
The config file should be in $HOME/.tool-versions
To resolve this, as in this example:
asdf plugin add go
asdf install go latest

libprotoc.so.9: cannot open shared object file: in IntelliJ

I'm trying to get protocol buffer working with intelliJ and gradle. However, I'm running into this error:
Execution failed for task ':generateProto'.
protoc: stdout: . stderr: protoc: error while loading shared libraries: libprotoc.so.9: cannot open shared object file: No such file or directory
I've seen this post: Protobuf cannot find shared libraries that explains the situation. But my question is that everything runs perfect on terminal as shown below:
yuefengzhao#zyf-ubuntu:~$ which protoc /usr/local/bin/protoc
yuefengzhao#zyf-ubuntu:~$ protoc --version libprotoc 2.6.1
But it's just not working at all on intelliJ. I'm not sure if intelliJ is configured so that protoc is pointing to eleswhere rather than what's set up in terminal.
scrrenshot of build.gradle and error message
Also, it's one of the requirements that I have to use protobuf v2.6.1
I've spent many hours trying and failing, looking for tons of solutions online but still couldn't wrap my head around.
Any help would be appreciated!
After debugging all night, I figured it's path to protoc that causing the problem. In my system terminal, protoc points to /usr/local/bin as expected when I do which protoc. But IntelliJ somehow gets a different path, pointing to /yuefeng/bin which is under /home.
The solutions is to start IntelliJ from system terminal instead of GUI (I'm using ToolBox) - a suggestion from IntelliJ support team.
I guess this is just a glitch from IntelliJ.

Gradle init isn't interactive

I am using gradle through command line for the first time. I am running the latest version of Ubuntu. My professor's instructions indicate that upon typing "gradle init" I should be prompted to say what type of project it is as well as the language, etc. Mine simply skips all of that and says "build successful" afterwards, my professors' file ends up with the proper directory structure and mine only has the basic root folders. From the quick searches I've done, I see that there is a difference between interactive and non-interactive responses, but I can't find anything regarding how to make it interactive.
My issue was I installed gradle with sudo apt install gradle which installs a very old version. Instead you can install sdk and then run sdk install gradle
If it says something along the lines of:
> Task :init SKIPPED
The build file 'build.gradle' already exists. Skipping build initialization.
BUILD SUCCESSFUL in 5s
Then it means you already have a Gradle build structure present. In order to initialize a new one, the directory you run it in must be empty.
I had this problem, too. Seems to be a bug.
You can tell gradle non-interactively what type to create, for example:
gradle init --type java-library
Other build types

Install Kubectl Plugin on Windows

Question: What are the steps to install a kubectl plugin on Windows?
I have written a plugin standalone binary that I would like to invoke from within kubectl (following the instructions in https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/)
The documentation for installation states to perform the following steps:
"A plugin is nothing more than a standalone executable file, whose name begins with kubectl-. To install a plugin, simply move this executable file to anywhere on your PATH."
This works fine on Mac and Linux, but performing those instructions on Windows does not seem to work. Running "kubectl plugin list" does not list my plugin and I cannot invoke it from within kubectl. I even tried adding my binary to the .kube directory autogenerated by kubectl, and it does not detect the plugin.
Several discussions on github reference this issue, without providing a response of how to install a kubectl plugin on Windows (ex: https://github.com/kubernetes/kubernetes/issues/73289). And after performing a lengthy google/stackoverflow search, there don't seem to be any tutorials/solutions that I (or my teammates) could locate. Any help would be much appreciated! Thank you.
In my case I don't have an issue with installing a plugin on Windows 10 machine (by simply including it on my PATH). Here is the output of 'kubectl plugin list':
c:\opt\bin>kubectl plugin list
The following kubectl-compatible plugins are available:
c:\opt\bin\kubectl-getbuildver.bat
- warning: c:\opt\bin\kubectl-getbuildver.bat identified as a kubectl plugin, but it is not executable
c:\opt\bin\kubectl-hello.exe
c:\opt\bin\kubectl-helloworld.p6
- warning: c:\opt\bin\kubectl-helloworld.p6 identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found
Instead I'm encountering a known github issue: 'not supported by windows' error, while invoking my plugin with kubectl (v1.13.4).
c:\opt\bin>kubectl hello
not supported by windows
c:\opt\bin>kubectl-hello.exe
Tuesday
*kubectl-hello.exe - is console application written in csharp. I tried also to use Windows batch file and Perl6 program as plugins, but none of these worked out on Windows.
I think only .exe file extensions are considered as executables by kubectl when it searches for plugins in the $PATH when running in Windows environment.
I tested by creating a simple HelloWorld App as a single file executable, added it to my system's $PATH and it got picked up and executed correctly.
kubectl krew like brew to manage the kubectl plugin. You can try it. It supports Window.
https://github.com/kubernetes-sigs/krew

facing issues while running chaincode locally using docker

i m getting below error while running learn-chaincode example on my local system please provide me the suitable solution for the mentioned error
$ go build
# github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11
exec: "gcc": executable file not found in %PATH%
Looks like the Fabric team introduced "nopkcs11" tag to bypass the problem - https://jira.hyperledger.org/browse/FAB-2854
I used the following command to build my chain code:
go build -tags nopkcs11
My understanding is that the Learn Chaincode example from https://github.com/IBM-Blockchain/learn-chaincode was being followed. Note that this example is for use with Hyperledger Fabric version 0.6.
The message is related to a PKCS11 package that is referenced by the example. This PKCS package requires a gcc compiler in order to build. I would suggest obtaining a gcc compiler and then trying to build the example again.

Resources