I predominantly work on windows OS and quite new to MAC systems. I am trying to set up Jenkins CI tool on one of the MAC machines, I have installed jenkins on mac and it is running on 8080 port.
Issue: I am getting the following error on Jenkins console output when i execute the job:
**/var/folders/zz/zzzivhrRnAmviuee+++++E++++2/-Tmp-/hudson6910375920437308281.sh: line 13:
**ampts: command not found**
Build step 'Execute shell' marked build as failure**
Things I tried:
I added the correct path in .bash_profile and since then I am able to successfully run the ampts command from terminal and every thing works fine from terminal. But the same does not run from the execute shell in Jenkins which is running on MAC.
Earlier the job was running as anonymous I created the account in jenkins and placed .bash_profile with the correct path under ~jenkins/users/home/my.account and restarted jenkins but still I am facing the same issue.
I also tried placing .bashrc under ~jenkins and also under ~jenkins/users/home/my.account but still no success.
Can some one point out what I am missing. or what needs to be done in case of Jenkins running on MAC.
This will depend on how you've started the Jenkins client. If you start it from the command line with the javaws command then I think this will inherit the environment variables of the terminal prompt. If you start the JNLP agent from the browser then it will inherit the system environment (which is different to the bash environment). There's a few things you could try:
Set the PATH variable explicitly in the ~/.MacOSX/environment.plist file (see the Apple docs)
If you are using Ant to run the jobs then you can add the environment variable to the ~/.antrc file (same syntax as the .bash_profile)
Set the environment variable in the Jenkins configure page for this node.
Related
Problem
I am trying to use a Windows Docker container to run GitHub Actions.
I want to run scripts before and after the job (e.g. to clean the directory).
I have successfully done this before on a computer not running docker, so I figured the same should work in docker.
What I have tried
I found here that you can do that using Environment Variables.
I used the following two commands in command prompt to set the environment variables.
Pre-Job Script:
setx ACTIONS_RUNNER_HOOK_JOB_STARTED C:\actions-runner-resources\scripts\pre-post-build\pre-run-script.ps1
Post-Job Script:
setx ACTIONS_RUNNER_HOOK_JOB_COMPLETED C:\actions-runner-resources\scripts\pre-post-build\post-run-script.ps1
The scripts do not run.
I have tried restarting the docker container.
I have tried restarting the actions runner service.
I am new to docker, so I am wondering if I am doing something wrong with the environment variables that does not work with docker.
How do I get the actions runner to run pre/post job scripts in docker?
You can safely add them to your environment variable by doing this recommended method;
Inside the actions-runner directory, locate the .env file, edit it by adding your environment variable. Save and restart the runner service.
I am running a Jenkins slave on a restricted environment. This environment will only allow me to execute files in a specific directory.
The problem I have is running simple batch commands.
The slave's java.io.tmpdir being AppData/Local/Temp, jenkins will copy my command in a temp bat file and attempt to run it, like such:
cmd /c call D:\Users\TastyWithPasta\AppData\Local\Temp\hudson8090039221524722157.bat
Here the issue becomes obvious, the command cannot be run due to restriction and the build fails.
Anybody working in a restricted environment and facing the same issues? What would be a good workaround?
Unfortunately, -Djava.io.tmpdir=newpath is not an option since this taps into the Java installation. Maybe there is a way to override it locally?
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 have Jenkins running on Windows, and I have a build that works fine under CygWin bash from the CygWin terminal, so I now want to automate it. However, using this script:
#!C:\cygwin\bin\bash.exe
whoami
make
The system reports me as nt authority\system, not the ken that I get when using an interactive shell. Is there an easy way to persuade Jenkins or CygWin to run as me?
Most likely you are running jenkins with default installation. You have two options. First is mentioned in the comment. Change the "Service account" to be same as yours.
Second option is derived from best practices. Run the jenkins master on a system with backup etc. Configure slave node with your account credentials. Change the project configuration to build on the specific node.
(It is possible to run slave and master on same machine with different credentials - just in case you want to try out things)
The real problem I was having was not that the shell script was running as the wrong user, but that the shell script was not executing the default /etc/profile. So, the solution was simply:
#!C:\cygwin\bin\bash.exe -l
whoami
make
I was still nt authority\system, but now I had the correct environment set up and could run make successfully.
Note also that if I create a /home/system directory I can add .bash_profile, etc, to that directory to further customise the build environment.
I am building a visual studio solution containing number of project. I wanted to disable multiprocess build, so , i tried setting an enviroment variable CL to /MP1. But it didn't worked in Jenkins while working in running the batch script for building solution using command line.
Good morning,
Log to your Jenkins server, and stop the Jenkins from the command line. While doing this, open your web-browser and refresh the Jenkins webpage to make sure it stopped(it will take around 5 seconds to stop the service). Then start again from the command line, it will update the variable. I did yesterday, to run my unit tests. It should work.
To set environment variables for individual projects, use the checkbox 'Prepare an environment for the run' and set what environment variables you want in the format 'ENV=value' in the Properties content box.
Otherwise, all I can suggest is that you haven;t restarted the Jenkins service after setting your variable in Windows.
You can also used the EnvInject plugin, it works well.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin