I trying to run my Tests cases for a project in Jenkins through DOS Command line on Windows server . I am using Jenkins ver. 1.559.
I am trying to run a Windows batch file through a Jenkins job that has the java command.
Under the "Build" section >> "Execute Windows Batch command" >> Command: call E:\Jenkins\App\UnitTests\App_UnitTests.bat
Save and Build the job.
I am getting an error and here is my Console Output
C:\Program Files (x86)\Jenkins\jobs\App Test Cases\workspace>java.exe -cp "E:\Jenkins\App\PPS\App\bin\;E:\Jenkins\App\PPS\App\lib\junit-4.10.jar;E:\Jenkins\App\PPS\App\lib\*.jar;" org.junit.runner.JUnitCore com.omnitracs.fra.junit.EventTests
'java.exe' is not recognized as an internal or external command, operable program or batch file.
C:\Program Files (x86)\Jenkins\jobs\App Test Cases\workspace>PAUSE
Press any key to continue . . .
C:\Program Files (x86)\Jenkins\jobs\App Test Cases\workspace>EXIT
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
The java command runs fine outside Jenkins.
I have set the JAVA_HOME for the local user and also the PATH variable to point to where java.exe is.
What am I doing wrong? Please help.
For a windows environment, there is some extra configuration needed for more advanced builds. Ultimately you have two options
From Jenkins, The Definitive Guide:
This basic installation will work fine in a simple context, but you
will often need to fine-tune your service. For example, by default,
the Jenkins service will be running under the local System account.
However, if you are using Maven, Jenkins will need an .m2 directory
and a settings.xml file in the home directory. Similarly, if you
are using Groovy, you might need a .groovy/lib directory. And so on.
To allow this, and to make testing your Jenkins install easier, make
sure you run this service under a real user account with the correct
development environment set up. Alternatively, run the application as the
system user, but use the System Information page in Jenkins to check
the /Users/johnsmart/Projects/Books/jenkins-thedefinitive- guide
directory, and place any files that must be placed in the user home
directory here....
To configure your Jenkins server to run under a service account (The suggested option), Install Jenkins as a service, and under the services properties set the log on user info.
Related
I'm a beginner to Jenkins, and trying to run a small Python code from Jenkins batch command for Windows.
However, the build run throws below error:
Running as SYSTEM
Building in workspace C:\Program Files (x86)\Jenkins\workspace\PythonProject1
[PythonProject1] $ cmd /c call C:\Windows\TEMP\jenkins7865401366299588301.bat
C:\Program Files (x86)\Jenkins\workspace\PythonProject1>cd C:\Users\Ben\Desktop\py
C:\Users\Ben\Desktop\py>python C:\Users\Ben\Desktop\py\for.py
'python' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\Ben\Desktop\py>exit 9009
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Python is installed in my machine and is declared in Environment Variable too. What am I missing?
"Running as SYSTEM" means the Jenkins service is not running with your account, but the Windows system account, used as a service account.
That means you need to add python path to the system environment variables, not the user ones.
I have a problem trying to launch a server via a .bat file during a TFS build.
I usually launch the server via a cmd window and it works fine.
When I set it in the TFS build, I end up with the following message :
"'..\server_common.bat' is not recognized as an internal command or external, an executable or a command file".
I also have the following line:
"java -Dsun.lang.ClassLoader.allowArraySyntax=true -Xbootclasspath/a:..\..\..\lib\framework\serverjvm15.jar; -cp ..\..\..\lib\framework\fwtime.jar;" indicating a java syntax error (? I'm not skilled in java)
This batch calls other .bat files and sets java VM-related environment variables
From my research, it is probably a problem of rights as I don't have admin rights when I use TFS. However, all the other steps in the build work fine (installing and launching an appli through command lines, or launching a python script via command lines).
However I also tried to launch a basic script with the same kind of step and it works.
First, suggest you to follow the tutorial in Batch script. Make sure you have meet the requirements of Arguments and used correctly. Such as
Path
Specify the path to the .bat or .cmd script you want to run. The path
must be a fully qualified path or a valid path relative to
the default working directory. In Team Foundation Build, this
directory is $(Build.SourcesDirectory).
Also RDP to your build agent and use your build service account manually run the server_common.bat to narrow down if the account have enough permission.
I have configured a job in Jenkins and checked "This build is parameterized" option. The parameter name I have given is "My_Param". The Jenkins is installed in the server machine. So I access the Jenkins dashboard through http://<servername>:8080/ In the Build part, I have to call a script by opening cygwin. So I write
#!C:\cygwin\bin\bash --login -i
./build/myscript.sh -full
After the build is completed, I want to move the files to another new directory prefix with Output, This directory name is the parameter I intend to pass. so I write
mkdir /cygdrive/c/users/admin/Ouput$My_Param
I run the build and pass param as first
But, the directory is created as Output in the server machine and not as Outputfirst
Since you noted you use cygwin, I understand the server is on windows.
Try parameter windows style environment variable: %My_Param% or linux: ${My_Param}
I hope this helps.
I am trying to use Jenkins to compile my MSBuild project created with Delphi. I have the MSBuild plugin installed into Jenkins and configured. I'm choosing the specific configuration for my build job.
I have set all the environmental variables in Jenkins that are required by the Delphi compiler (from rsvars.bat for you Delphi types.)
The project compiles just fine on the command line. If I do it on the command line, MSBuild reports a nice big fat PATH (the correct one) as part of the command line it uses to call the Delphi compiler.
However, when I try to use it with Jenkins, the result is quite different:
C:\Program Files (x86)\Embarcadero\RAD Studio\8.0\bin\dcc32.exe -$D- -$L- -$Y- --no-config -B -Q -AWinTypes=Windows;WinProcs=Windows;DbiTypes=BDE;DbiProcs=BDE;DbiErrs=BDE -DRELEASE -K00400000 HTMLWriterTestApp.dpr
Embarcadero Delphi for Win32 compiler version 22.0
Copyright (c) 1983,2010 Embarcadero Technologies, Inc.
Noet the complete lack of a path, or any other information about were to find what the compiler needs. This information is there when I run from the command line.
Can anyone think of any reason why Jenkins is failing to get the correct PATH information?
Depending on how you run Jenkins, it may not have the full path line that you are used to seeing. For example, if you run Jenkins as a Windows Service and have your USERS PATH variable populated, you won't necessarily have it populated for the SYSTEM user. In this case, modify the Logon Account used by the Service to be your account, rather than a system one.
I have Jenkins running on a server inside Glassfish, running as the local system account, as it was installed, by using a derivation of this blog post, and I was able to get it to work by setting property variables in the "system configuration" (Jenkins Environment Injector Plug-in) in Jenkins. (BDS, BDSCOMMONDIR, FrameworkDir, FrameworkSDKDir etc...)
Then the trick for Delphi to pick up the appropriate path is to send the command line parameter "Win32LibraryPath" to MSBuild. Make sure to escape your double quotes in this parameter in Jenkins or else you will pull out your hair.
I had Jenkins started as windows service and it could not find an SVN command even if I had SVN\bin in my PATH variable for the System user.
It seems that the service uses only the environment variables available at start up time.
So if later on you add some more environment varibales to the Windows System user, they will not be available to the service.
All you have to do is restart the window service and it will pick the new environment variables !
Anything with git pull/ where git commands, which are not executing from Jenkins is because of the path issue in the environmental variables in Windows.
Check the PATH in Environment variables.
Check the same command executes from windows command prompt or not.
If it is executing & Windows is running as slave service, then restart the slave service from services.msc.
Log out and login back to Jenkins.
My company is trying to automate the creation of a nightly installer with Hudson. Our license to install anywhere is running on a separate server. We have an ANT build script set up to call the InstallAnywhere jar file which creates the installer automatically, and that works great when ran from the command prompt.
However when we try to run it inside of Hudson, Hudson is not able to connect to that license server. InstallAnywhere spits out The evaluation period has expired. Does anyone know what we can do to solve this issue?
I'm assuming it's a Hudson issue since our ANT script works fine when used outside of Hudson.
My best guess is that you need to set up some environment variables required by the InstallAnywhere process; I'm not very familiar with that product, but maybe it needs a home directory for the product, the location of the license file, the license key value, etc.
One easy way to debug this would be to check if Hudson is running under the same user that you are using to run the Ant script from the command line, then check the environment settings for the command line user if they are different.
Since I'm running Hudson as a service I had to use the "Default User" user. The solution was to copy the InstallAnywhere folder tree from "C:\Documents and Settings\MyUser" to "C:\Documents and Settings\Default User"
I just had the same issue, so I thought I would share my solution. You can also register the CI build user so you can continue using the automated user rather than switching it to your own user account: http://www.flexerasoftware.com/downloads/instructions/productlicensing/en/InstallAnywhereProductLicensing.pdf#page=15
Set up a bat file to execute:
<PATH_TO_IA>\build.exe -registerNodeLocked <PATH_TO_IA>\License.lic
Note, the License will be your mac address.lic, and you only have to do this once.
My bat was:
C:\Progra~2\Instal~2\build.exe -registerNodeLocked C:\Progra~2\Instal~2\[MAC].lic
Then I added a bat task to jenkins, and ran the job:
You should see something like:
Trying to checkout IAEE version=12.0
InstallAnywhere is successfully registered.