i'm using teamcity 5.1.5.. trying to build an MSBuild project with an AfterDeploy target which calls a java function..
i get the following error: 'java' is not recognized as an internal or external command
I've tested the java command on the build server and the agent servers and they all run the command..but it seems it fails when running through teamcity.
any ideas?
i've checked the build agent env vars and they seem correctly setup:
Environment variables defined in the
agent configuration file
JAVA_HOME C:\Program
Files\Java\jdk1.6.0_21
JDK_16 C:\Program
Files\Java\jdk1.6.0_21
TEAMCITY_JRE C:\TeamCity\jre
the only thing i notice is that the java.exe are actually in the bin folders here not the root folder.
Build Agent runs from the SYSTEM account by default. SYSTEM account environment variables differ from your normal account which you've used for testing. I suspect that java.exe is not in PATH for the SYSTEM account. Either adjust PATH by adding JDK_HOME\bin to it or configure the Agent service to run from a different account.
Remember you need to restart the build agent service before changes to PATH will take effect.
You can also run your build agent service under a local administrator account (this might be preferred for several reasons), but there is a bug in TeamCity where only the USER environment variables (for example the PATH) are used by the agent, not SYSTEM+USER as normal in Windows.
So if you have a path defined for the user, the system paths are unknown by the agent!
The workaround right now (verified) is to add the user path to the system path and delete the user path (under System/Avanced System Settings/Environment Variables).
Bug here and a (not solved as of 2012-01-29):
http://devnet.jetbrains.net/thread/276957
We run the agent under a normal user account. Java can be found in an interactive session, but not in the TeamCity builds. I had to add the java bin directory to the PATH variable of the user. After a log off/log in, the java command could then be found by the TeamCity builds.
Related
I'm trying to add SonarQube to a local instance of GitLab-CI, but can't get past this error produced by GitLab-CI Runner:
Note: GitLab-Runner, Sonar-Scanner and SonarQube are all installed on the same Windows server.
My first thought was, it can't find the runner, installation/permission problem. So....
I have verified:
SonarQube Service run as Admin and has full access to Sonar-Scanner directory
GitLab Runner Service as Admin and has full access to Sonar-Scanner directory
Sonar-Scanner Installation double checked (Standalone executable: sonarscanner-for-msbuild) (installed per https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-msbuild/ )
Sonar-Scanner added to Environment Variables' 'Path':
And still the same error so I tried running Sonar-Scanner on its own:
and that seems to run ok. But GitLab still produces the same issue. Maybe I'm using the wrong Sonar-Scanner?
I'm fairly new to GitLab-CI's Runner so any guidance/suggestions you can offer is greatly appreciated. Not sure where else to look (I've read everything/anything remotely related).
My issue was related to environment path. I have multiple accounts.
GitLab Runner Service as Admin and has full access to Sonar-Scanner directory
The account that GitLab runner was using was not the account that had the environment variables. Once SonarScanner directory was added to the user environment variables (Path) of the GitLab runner windows account, it worked as expected.
Using Jenkins 2.46.2 on Windows Server 2012 R2.
I have pipeline script that runs:
bat 'env'
I'm interested in environment variable: PSModulePath
This is output as
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
in my console output. However, if I run this logged on as the Jenkins account on the Jenkins server, I get a different result:
PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\;C:\Program File
s (x86)\Microsoft SQL Server\140\Tools\PowerShell\Modules\;C:\Program Files\Wind
owsPowerShell\Modules
Why is that? I can't load some modules in a Jenkins job because they can't be found.
I worked around this by explicitly adding the path as an environment variable to Jenkins, but I don't know why I had to do that. Anyway it works now.
In my case it turned out that Jenkins' PowerShell Plugin runs as a 32bit process and does not see the modules installed in the 64bit Program Files folder.
Using the ProgramW6432 env var fixes the problem.
pipeline {
environment {
// Add the 'real' ProgramFiles folder to the PSModulePath as the powershell is run as a 32bit process
// and the modules are installed in the 'C:\Program Files\' folder
PSModulePath = "${env.ProgramW6432}\\WindowsPowerShell\\Modules;${env.SystemRoot}\\system32\\WindowsPowerShell\\v1.0\\Modules"
}
...
How to change Jenkins default folder on Windows where Jenkins runs as Windows service.
I want to change C:\Users\Coola\.jenkins folder to d:\Jenkins due to lack of space on C: partition (Every build takes ~10MB of free space). I don't want to reinstall Jenkins as Windows service. I just want to change folder of existing Jenkins instance. In case of lack of global solution I could focus only on relocating jobs folder.
Thanks in advance for your help.
Stop Jenkins service
Move C:\Users\Coola\.jenkins folder to d:\Jenkins
Using regedit, change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Jenkins\ImagePath to "d:\Jenkins\jenkins.exe"
Start service
Apparently, grams' answer works but is not preferred. In Windows software and data/configuration files are supposed to reside in different places. This should be well known to Unix guys, it is basically like having a home directory. However, the wording with regard to JENKINS_HOME is broken anyways as setting an environment variable does not help despite what is being said in the help text.
I used the procedure that is described here: http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Basically:
Stop Jenkins service
Edit entry <env name="JENKINS_HOME" value="%BASE%"/> in jenkins.xml in the Jenkins installation directory. This will be something like C:\Program Files (x86)\Jenkins. In your case value has to be set to d:\Jenkins
Move Files from the installation directory to the new destination, d:\Jenkins, all except (some of them may not exist in a fresh installation)
jre folder
jenkins.err.log
jenkins.exe
jenkins.exe.config
jenkins.out.log
jenkins.war
jenkins.war.bak
jenkins.war.tmp
jenkins.wrapper.log
jenkins.xml
Restart the service again.
When you read Administering Jenkins you can read all options how to modify the JENKINS_HOME environment variable.
On this website you can read how to configure you Tomcat container to override the JENKINS_HOME environment variable, they advise to create the file $CATALINA_BASE/conf/localhost/jenkins.xml, with the following content:
<Context docBase="../jenkins.war">
<Environment name="JENKINS_HOME" type="java.lang.String" value="/data/jenkins" override="true"/>
</Context>
Here is the answer that worked for me: Jenkins: How to change JENKINS_HOME on Windows
And in addition to grams answer, the most important part is creating an environment variable named JENKINS_HOME with value "D:\Jenkins". Without that, on starting Jenkins it would again create the .jenkins folder in your user home folder.
I was able to change the JENKINS_HOME variable following this http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Setting JUST %JENKINS_HOME% as windows system wide environment variable didn't have any effect!
We installed by dropping the .war into Tomcat, and could set home by just setting the environment variable JENKINS_HOME (with a service restart).
I'm using Jenkins to do continuous integration builds. I have quite a few jobs that have much of the same configuration code. I'm in the midst of pulling this all out into a common script file that I'd like to run pre and post build.
I've been unable to figure out how to set some environment variables within that script, so that both the Xcode build command, and the Jenkins build can see them.
Does anyone know if this is possible?
It is not possible to do exactly what you ask. A process cannot change the environment variables of another process. The pre and post and actual build steps run in different processes.
But you can create a script that sets the common environment variables and share that script between all your builds.
The would first call your shell to execute the commands in the script and then call xcodebuild:
# Note the dot in the beginning of the next line. It is not a typo.
. set_environment.sh
xcodebuild myawesomeapp.xcodeproj
The script could look like this:
export VARIABLE1=value1
export VARIABLE2=value2
How exactly your jobs will share the script depends on your environment and use case. You can
place the script in some well-known location on the Jenkins host or
place the script in the version controlled source tree if all your jobs share the same repository or
place the script in a repository of its own and make a Jenkins build which archives the script as a build artifact. All the other jobs would then use Copy Artifact plugin to get a copy of the script from the artifacts of script job.
From Apple's Technical Q&A QA1067 it appears that if you create the file /Users/YOU/.MacOSX/environment.plist and populate it with your desired environment variables that all processes (launched by the user with the environment.plist file in their home dir) will pick up these environment variables. You may need to restart your computer (or just log out and back in) before a newly launched process will pick up the variables.
This article also claims that Xcode will also pass these variables to a build phase script. I have not tested it yet but next time I restart my MacBook I will let you know if it worked.
From http://developer.apple.com/library/mac/#/legacy/mac/library/qa/qa1067/_index.html
Q: How do I set environment for all processes launched by a specific
user?
A: It is actually a fairly simple process to set environment variables
for processes launched by a specific user.
There is a special environment file which loginwindow searches for
each time a user logs in. The environment file is:
~/.MacOSX/environment.plist (be careful it's case sensitive). Where
'~' is the home directory of the user we are interested in. You will
have to create the .MacOSX directory yourself using terminal (by
typing mkdir .MacOSX). You will also have to create the environment
file yourself. The environment file is actually in XML/plist format
(make sure to add the .plist extension to the end of the filename or
this won't work).
The default path for teamcity artifacts is
C:\#User#\.BuildServer\system\artifacts
How can i change it to
d:\TeamCity\Artifacts
Thanks
For me the default is D:\BuildServer\system\artifacts
Yes you can, set the TEAMCITY_DATA_PATH environment variable.
See here: http://www.jetbrains.net/confluence/display/TCD4/TeamCity+Data+Directory
By default, the is placed in the user's
home directory (e.g. it is
$HOME/.BuildServer under Linux and
C:\Documents and
Settings\.BuildServer)
under Windows. Alternatively, you can
define this directory in one of the
following ways:
As a Tomcat system property teamcity.data.path (see System
Properties for Running the Server)
In the TEAMCITY_DATA_PATH environment variable (this will be
used if the teamcity.data.path JVM
system property is not found)