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.
Related
I want to deployto WebLogic using groovy code inside Jenkins job pipeline.
Has anyone ever used a groovy code inside Jenkins job pipeline to deploy to WebLogic application? WebLogic version is 10.x.
I know how to do it with freestyle job and it works via plugin, but when I click on pipeline syntax, I don't see nothing from this plugin.
I have googled and googled, and nothing actually works or is not the scope of my needs and too complex to understand so I could addapt (using Java etc).
SOLVED: OK so I found a way and a way to make it work. Basically one can write a python (jython) code which can manage WebLogic with its built-in WLST scripting mechanism.
But to make everything work, one needs to:
generate wlfullclient.jar on your WebLogic machine: https://docs.oracle.com/cd/E12839_01/web.1111/e13717/jarbuilder.htm#SACLT239
Use the following steps to create a wlfullclient.jar file for a JDK 1.6 client application:
Change directories to the server/lib directory.
cd WL_HOME/server/lib
Use the following command to create wlfullclient.jar in the server/lib directory:
java -jar wljarbuilder.jar
You can now copy and bundle the wlfullclient.jar with client applications.
Add the wlfullclient.jar to the client application's classpath.
in order for this to work from other machine, without installing WebLogic to it, one needs additional .jar files, which can be found on WebLogic machine in some Weblogic folder e.g. C:\bea10\wlserver_10.3....
copy dependent .jar files to desired machine, create empty props.txt file and call your python script like this (in the command you will note which .jar files are also needed in classpath -cp). Dweblogic.home is where weblogic.jar is located. Note that if you gonna put those jars in environment classpath variable, you can NOT add a path to folder, since .jar and .zip files need to be targeted directly.
java -cp C:\Users\icami\Desktop\weblogic\wlfullclient.jar;C:\Users\icami\Desktop\weblogic\com.bea.core.xml.xmlbeans_2.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.comdev_6.4.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config-wls-schema_10.3.6.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config-wls_7.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.config_7.2.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.cie.wizard_6.1.0.0.jar;C:\Users\icami\Desktop\weblogic\com.oracle.core.weblogic.msgcat_1.2.0.0.jar;C:\Users\icami\Desktop\weblogic\jython.jar;C:\Users\icami\Desktop\weblogic\weblogic.jar -Dprod.props.file=C:\Users\icami\Desktop\weblogic\props.txt -Dbea.home= -Dweblogic.home=C:\Users\icami\Desktop\weblogic weblogic.WLST test.py
Example of a safe test.py, it only retreives state, listen address etc, doesn't change anything, feel free to run it:
username = 'weblogic'
password = 'weblogic'
URL='t3://weblogic.domain.com:7001'
connect(username,password,URL)
domainRuntime()
cd('ServerRuntimes')
servers=domainRuntimeService.getServerRuntimes()
for server in servers:
serverName=server.getName();
print '**************************************************\n'
print '############## ', serverName, '###############'
print '**************************************************\n'
print '##### Server State #####', server.getState()
print '##### Server ListenAddress #####', server.getListenAddress()
print '##### Server ListenPort #####', server.getListenPort()
print '##### Server Health State #####', server.getHealthState()
We have a Code Composer Studio (Eclipse) project that uses CMAKE to generate makefiles and build. The project compiles as expected when the project is manually imported onto the Jenkins slave (Win10 x64) and executed from the command line but fails when the build is handled by Jenkins. The failure always follows the same pattern: a singular letter is dropped from the path of an object file. For example, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir becomes [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir and linking fails because it cannot find the referenced object file.
I made sure that there are no differences between the account environment variables and the system environment variables and have also configured the Jenkins Service to use the admin account on the slave instead of SYSTEM in order to get rid of as many differences between Jenkins and the command line as possible.
The project will build successfully using one of our other Jenkins slaves (also Win10 x64), so we know that it's not a Windows 10 issue or a problem with our Jenkins configuration. Since I can't find any differences between the configuration of the two slave machines, I was hoping that someone might be able to suggest somewhere to look for this path issue.
I never found out why the paths to object files were being mangled, but I did get the project to build successfully on the slave via Jenkins. All I did was change all of my system environment variables into user environment variables. I copy-pasted, so I know that the variables themselves did not change.
I have no idea why this corrected this issue as I had inserted a whoami call at the beginning of the build to confirm that Jenkins is indeed running as a user and not System. I guess from this point on all of my environment variables will be specific to a user and not SYSTEM...
EDIT: The problem has returned. I have made no further progress in tracking down the cause behind this issue, but I have found that I do not see this symptom when running the scripts in a bash environment instead of a Windows command prompt. Fortunately for me the scripts have all been written in such a way that they can be run in both environments, so I have had my coworkers use bash instead for them.
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.
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.