My machine just had its hard drive re-imaged so I'm trying to rebuild it. At this point, I am trying to execute an ant script which has worked for years. Not anymore. When the script compiles the javac errors because it can't find a directory.
The error is...
BUILD FAILED
C:\Users\WHeckle\Documents\temp\6.9.2\build-tceq.xml:92: C:\Users\WHeckle\Documents\temp\6.9.2\${env.SEAM_HOME}\lib does not exist.
It looks like it is concatenating the current directory with seam_home and using it as a library reference to the compiler.
I am at a loss to explain the behavior. Any help is appreciated.
The Ant script expects to find a Windows environment variable named SEAM_HOME.
To get the script to work...
Close any Command Prompts that are open.
Create a SEAM_HOME Windows system environment variable (if this step is unclear, search Google to find instructions on how to do this for your version of Windows).
Open a new Command Prompt.
Run echo %SEAM_HOME% in the Command Prompt to confirm that the environment variable is set.
Re-run your Ant script.
SEAM_HOME appears to be related to JBoss. For an example of what the value of SEAM_HOME can be, see this JBossDeveloper forum post.
Related
According to this very old question you can use Bamboo variables in a batch script like %bamboo_buildNumber%, but it doesn't work for me, I just get an empty string. I also tried %bamboo.buildNumber% with the same result. The script is not in-line and is used by a Dockerfile. Does that have an influence on this? Or did something change since the above question was asked?
In the script I have a line
innosetup-compiler MySetup.iss "--DVERSION=%major%.%minor%" "--DPATCH=%bamboo_buildNumber%"
And in my Dockerfile I write
RUN ./MyScript.bat
Update:
So I think whats happening is that because the batch-script is run from the Dockerfile it is also run inside a container and doesn't have access to the Bamboo environment variables because of this. I tried passing the variable in question through the Dockerfile into the script, but it hasn't worked as of yet.
I believe that this has changed in newer versions of Bamboo. The preferred syntax now is to use ${bamboo.buildNumber} when passing variables to a build script. I even use that approach in my old /bin/sh cmd.exe scripts. You'll know you've got it working when you see the following in the logs: Substituting variable: ${bamboo.buildNumber} with xxxx
Once you verify that the above variable substitution is working, you can then troubleshoot how that variable is getting (or not getting) into your Docker scripts.
For more information on the major minor build numbers check out this page. You may need to call it slightly differently if it is a custom variable.
if we are using the script body in bamboo script task then ${bamboo.buildNumber} will work without any issue but if we need to access in bat file or a ps1 file then it is required to access in the below syntax
%bamboo_buildNumber% In a .bat file use
$Env:bamboo_buildNumber in a Powershell file
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.
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.
In my Jenkins build i want it to read my NSIS script file. This is how it looks.
installer.exe/D=C:\Program Files(x86)\NSIS
But Jenkins keep failing to build correctly from this. Anybody who can help me?
Create new batch command with following:
path_to_NSIS_folder>\makensis.exe path_to_your_nsi_file
makensis.exe is a NSIS compiler and all it needs is path to the script file (.nsi).
When run the script is compiled and (if no errors) reslting setup.exe is created (the output can se set in .nsi file).
This code was given to me by another user and works perfectly although I didn't structure this question correctly. But this is the answer.
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.