I am attempting to test a Golang application hauser locally on via -bash CLI before deploying on a VM.
Per the documentation, I compiled locally and copied the example-config.toml file. I then mapped to the GOPATH and opened hauser.exe to open config.toml file. However, when I execute, it returns open config.toml: no such file or directory
C02Z30ANLVDV:~ pmcgin2$ $GOPATH/bin/hauser -c Documents/go/bin/config.toml
2020/08/14 18:05:23 Cannot find folder , make sure it exists
C02Z30ANLVDV:~ pmcgin2$ open Documents/go/bin/config.toml
No application knows how to open /Users/pmcgin2/Documents/go/bin/config.toml.
Is there an alternative command I can execute to override the default config.toml location for an application like this?
There are two possibilities to solve your issue:
give an absolute path as argument:
$GOPATH/bin/hauser -c /Users/pmcgin2/Documents/go/bin/config.toml
give a relative path from the binary location:
$GOPATH/bin/hauser -c config.toml
Generally, it is easier to use absolute paths.
Related
Iam failing while integrating pio to the CLion IDE. I included the PATH variable to the ~/.profile file (three different ways) as:
export PATH=$PATH:~/.platformio/penv/bin
export PATH=$PATH:home/jonas/.platformio/penv/bin
export PATH="~/.platformio/penv/bin":$PATH
and can run the pio – version (and also the equivalent platformio) without sudo privelegies.
But when I’m trying to create a new pio project in CLion I always get
```Cannot run programm ./home/jonas/.platformio/penv/bin” (in directory “/tmp”): error=13, Permission denied``
Ok, I got it working. The problem was that the path to pio was not complete. The path (/home/jonas/.platformio/penv/bin/home/jonas/.platformio/penv/bin) points to the folder but not to the file to run. The full path is:
/home/jonas/.platformio/penv/bin/pio (or platformio).
However, in the create project window, you don’t even get to correct the path and it was automatically created during installation. This is a bit confusing.
I've installed jenkins on windows, and I wanted to use jenkins command to start and stop the program from anywhere in the system.
It turns out that after configuring jenkins and creating the environment variable I get the error below everytime I execute "jenkins start" from outside C:\Program Files (x86)\Jenkins.
Is there any configuration missing?
ERROR
System.IO.FileNotFoundException: Unable to locate jenkins.xml file within executable directory or any parents
at winsw.ServiceDescriptor..ctor()
at winsw.WrapperService.Run(String[] _args, ServiceDescriptor descriptor)
at winsw.WrapperService.Main(String[] args)
SYSTEM ENVIRONMENT VARIABLES
JENKINS_HOME:
C:\Program Files (x86)\jenkins
Path:
%JENKINS_HOME%
You need to run your jenkins install jenkins.xml at the place where is your jenkins.xml
1 rename winsw.exe to jenkins.exe
2 cd c:/...where is your jenkins.exe
3 run jenkins.exe install jenkins.xml (both files must be in the same directory)
In Windows 10, the path of the configuration file (config.xml) is:
C:\ProgramData\Jenkins.jenkins
The Folder ProgramData is hidden, so go to the address bar and type or use the CLI.
Solution: Save your jenkins-agent file as xml format. not just jenkins-agent.xml
we can use notepad++ to save the xml type. similarly remove .exe at end of jenkins-agent.exe
Hope its useful.... cheers !!
I've been trying to build grafana from its source code on windows by following the instructions here
I am stuck and am failing to set the GOPATH path properly.
I set it to the default go directory in C:\myname but whenever I try to change to that directory using the command "cd $GOPATH/src/github.com/grafana/grafana" it says the system cannot find the specified path.
And even if I put the path manually and in the directory try to run "go run build.go setup" the system cannot find the file specified.
If someone could help me that'd be great!
Try to create a new empty folder:
mkdir C:\myFolder
cd C:\myFolder
set GOPATH=C:\myFolder
go get github.com/grafana/grafana
That should create a src\github.com\grafana\grafana folder, with the sources inside.
I'm trying to use bash as the shell on Windows for a GitLab CI Runner.
concurrent = 1
check_interval = 0
[[runners]]
name = "DESKTOP-RQTQ13S"
url = "https://example.org/ci"
token = "fooooooooooooooooooobaaaaaaaar"
executor = "shell"
shell = "bash"
[runners.cache]
Unfortunately I can not find an option to specify the actual shell program that the CI Runner should use. By default, it just tries to run bash which it can not find. I don't know why, because when I open up a Windows command line and enter bash it works.
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
ERROR: Build failed (system failure): Failed to start process: exec: "bash": executable file not found in %PATH%
I tried adding a file bash.cmd to my user directory containing
#"C:\Program Files\Git\usr\bin\bash.exe" -l
That gives me this strange error:
Running with gitlab-ci-multi-runner 1.9.4 (8ce22bd)
Using Shell executor...
Running on DESKTOP-RQTQ13S...
/usr/bin/bash: line 43: /c/Users/niklas/C:/Users/niklas/builds/aeb38de4/0/niklas/ci-test.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1
Is there a way to properly configure this?
There are two issues going on here, and both can probably be solved.
gitlab-runner cannot find bash
gitlab-runner doesn't combine unix-style and Windows-style paths very well.
You have essentially succeeded in solving the first one by creating the bash.cmd file. But if you're curious about why it didn't work without it, my guess is that bash runs in your command prompt because the directory that contains it (e.g. in your case "C:\Program Files\Git\usr\bin") is included in the PATH environment variable for your user account. But perhaps you are running the gitlab-runner in the system account, which might not have the same PATH.
So the first thing to do is just check your system's PATH variable and add the bin directory if necessary (i.e. using the System applet in the Control Panel as described here or here). Just make sure you restart your machine after you make the change, because the change isn't applied until after you restart. That should make bash work, even when called from a service running in the system or admin account.
As for the strange error you got after creating bash.cmd, that was due to the second issue. Paths are often really hard to get right when combining bash and Windows. Gitlab-runner is probably trying to determine whether the build path is relative or absolute, and ends up prepending the windows path with what it thinks is the working directory ($PWD). This looks like a bug, but gitlab still has not fixed it (as of version 9.0 of the runner!!) and probably never will. Maybe they have decided it is not a bug or that it is due to bugs in underlying software or tools that they can't fix or that it would be too difficult to fix. Anyway, I've discovered a work-around. You can specify the base path for builds in the config.toml file. If you use a unix-style path, it fixes the problem.
On windows, config.toml is usually in the same folder as your gitlab-runner.exe (or gitlab-multi-runner-amd64.exe etc). Open that file in your favorite text editor. Then find the [[runners]] section and add two lines similar to the following.
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
The path you use should be the "bash version" of whatever directory you want gitlab-runner to use for storing builds etc. Importantly if you are using cygwin, you would use a path similar to /cygdrive/c/... instead of just /c/... (which is appropriate for msys-git or standalone MSYS2 etc).
Here's an example of a config.toml file:
[[runners]]
name = "windows"
url = "https://your.server.name"
token = "YOUR_SECRET_TOKEN"
executor = "shell"
shell = "bash"
builds_dir="/c/gitlab-runner/builds/"
cache_dir="/c/gitlab-runner/cache/"
It looks like you're attempting to link gitlab-ci up with the Windows Subsystem for Linux (which can be accessed by typing bash at the Windows command prompt)? I doubt that this is supported directly by Gitlab's runner configuration.
Instead, I would suggest using Powershell with your shell executor.
Executor = 'shell'
Shell = 'powershell'
You can then drop down into Bash in the scripts you call from .gitlab-ci.yml.
Given that it's bad practice to execute more than very trivial shell scripts within the .gitlab-ci.yml itself (as opposed to calling out to an external script), you lose little by being forced to use a native Windows shell.
I am testing an application by starting certain commands in sequence. During which for one of the command when I get into the directory and run it it works where as when I run directly it gives No such file or directory
cd /opt/abc/ then running gulp serve will work
Where as when I run directly - /opt/abc/gulp serve it fails
Attached is the snapshot of the same.
enter image description here
You are thinking that PWD is in your PATH, which as root it should not be (I personally don't think it should be for any user, but definitely not the super user).
So, when you type in "gulp serve" it's checking your path and finding "gulp". If you type which gulp you can see where it finds it. When you type the path to gulp, it is not finding an executable there. So-- that's not the one you want, and if there is a file called gulp there it is not executable.