this is a batch file that i have. It is located in C:\Work\6.70_Extensions\Lab Tools\ folder.
ANT.BAT:
set CLASSPATH=%CLASSPATH%;.;c:\JavaMail\javamail-1.3\mail.jar;c:\JavaMail\javamail-1.3\mailapi.jar;c:\JavaMail\javamail-1.3\pop3.jar;c:\JavaMail\javamail-1.3\smtp.jar;c:\JavaMail\jaf-1.0.2\activation.jar
CALL "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
#echo on
%ANT_HOME%\bin\ant -logger org.apache.tools.ant.listener.MailLogger -q -buildfile "Master Build.xml"
pause
along with ant.bat, i have a Master Build.xml file located inside the same folder.
When i double click on ant.bat, it will execute the Master Build.xml ant script properly.
However, whenever i try to use another application to open the batch file's absolute path, it always state that Master Build.xml file does not exist!
I tried to open the absolute path using both console application and another ANT Script(via Cruisecontrol framework) but both gives the same error. What is the error here?
for your information here is what ive done with cruisecontrol:
create config.xml (to set intervals for builds)
create nightbuild.xml (so that config.xml will go into it to perform required tasks)
nightbuild.xml will run several console applications to sort files, checkout files from version control etc
lastly, nightbuild.xml will execute ant.bat file to execute the build
These files, config.xml and nightbuild.xml are found in C:\build
When you execute from a directory other than the one containing Master Build.xml, Ant will fail to find the build file, which it expects to be in the current working directory.
You could set an additional environment variable to specify the path to the build file, e.g.
%ANT_HOME%\bin\ant -buildfile "%MASTER_BUILD%\Master Build.xml"
If you set your variable to an absolute path (e.g. C:\Work\6.70_Extensions\Lab Tools) then it will always work. If you use a relative path (e.g. .\Lab Tools), then it will only work if executed from the relative root dir.
(BTW, life will probably be easier if you use buildfiles without spaces in their names, e.g. master_build.xml rather than Master Build.xml).
Related
I know its possible to run a .dsl file from an external source instead of just writing the code of the flow in the job's description, but every time I try to run lets say:
/home/flows/flow_script.dsl
I get the following error:
java.io.FileNotFoundException:/home/flows/flow_script.dsl (No such file or directory)
The path is correct, I can see the file through that path from the shell, but it doesnt let me select anything outside the "builds workspace" apparetly.
I recently ran into this very issue: my DSL script was outside of my workspace (installed via a package). The problem is that the DSL Scripts path is an Ant format that only allows specific patterns (and not absolute paths).
My workaround is hacky, but it did work: add an Execute Shell step before the "Process Job DSLs" step that symlinks the external directory into the workspace.
Something like this:
echo "Creating a symlink from /home/flows to workspace"
ln -sf "/home/flows" .flows
Then you can set the DSL Scripts path to ".flows/flow_script.dsl".
This has some additional caveats, of course: the directory you're symlinking from will need to be accessible by the jenkins user. And it likely violates a lot of best practices.
I have a test project in Jenkins. And each time I build my project it says.
The results file "My File Path" already exists. Please specify a
different results file or verify the existing file is no longer needed
and delete it.
So I've decided to include the build number in the name of my result file.
And I'm using my result file to generate some graphical output also.
How can I include my Build Number in both locations
This is the windows batch command execution
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\mstest.exe"
/testcontainer:"%WORKSPACE%\TestAutomation\bin\debug\TestAutomation.dll"
/resultsfile:"%WORKSPACE%\results.xml"
And I'm using my result file as follows.
How can I change both these locations to add current build number in my result file as followingformat
result_BuildNumber.xml
Try this,
result_%BUILD_NUMBER%.xml - for batch
result_$BUILD_NUMBER.xml - for shell
BUILD_NUMBER is environment variable.
Im trying to setup jenkins in my company and Ive got some problems.
Im using this commands to build the project:
SET MSBuild="C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe"
SET BUILDS=C:\Program Files (x86)\Jenkins\jobs\xxx\builds\
SET OUTPUT_PATH="%BUILDS%%BUILD_NUMBER%"
SET RSVARS="C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
CALL %RSVARS%
SET PATH=%PATH%;D:\komponenty\DXE3\ADSI
%MSBuild% xxx.dproj /t:Build /p:Config=Debug;Platform=Win32;DCC_ExeOutput=%OUTPUT_PATH% /maxcpucount:4
It works fine when i type this in cmd but. I gave administrive privileges to jenkins service. When I try to build project with jenkins i receive error like this:
F1026: File not found: 'ADSI.dcu
this is a component for Delphi and i have this component on second partition. Jenkins has access for many components on this partition but not for this one.
The difference between the two will be your current directory.
Jenkins will start you off in a specific working folder for the job (possibly C:\Users\<User-ID>\.jenkins\jobs\<Job-Name>\workspace).
Add the following to your Jenkins commands to see where you're doing the build from:
echo Current Folder: %cd%
A simple "solution" would be to just add a command in Jenkins to change directory to the same folder you're in when you test from the command-line.
However, I suggest you rather do the following:
Ensure Jenkins gets the latest source from your source repository into its working folder. (There are various plugins depending on what particular tool you use.)
Ensure you cd (change directory) to the correct folder within the workspace folder.
I'm using Ant with eclipse and everything was working fine, until I decided to do some house keeping and created 2 sub directories under my Ant dir.
I moved my build.xml to the sub directory and now nothing is working an I get:
BUILD FAILED C:\Users\OdedHarniv\Workspaces\Force.com
IDE\vidmind\ANTs\Vid Service\build.xml:26: Problem: failed to create
task or type antlib:com.salesforce:retrieve Cause: The name is
undefined.
Any idea what am I doing wrong?
I see two possible problems
1 You have a relative path defined somewhere in your ant file, or a file that you are importing. Note that if you are importing e.g. a properties file, relative paths in that one will be interpreted relative to the directory containing the main ant file.
2 If you are running through Eclipse, it will run through a run-configuration. That might have extra jars put on its class path. I expect Eclipse will create a new run configurations when you move the file, which has the default class path. Too see your run configuration go to Run > External Tools > External Tools....
The problem: I am setting up TeamCity as a build server for an ASP.NET MVC project. I am using Powershell with psake to run msbuild against our .csproj file and create a deployable package. From the build server, I can open up powershell, run the script and, because there are no source code changes, msbuild does not regenerate the project DLL files. BUT, when I call the exact same script from the TeamCity web interface, msbuild ALWAYS rebuilds and regenerates the DLL files even though there are no changes. Not what it should do AFAIK.
I have narrowed this problem down to a single step. To keep it simple, I have set up my TeamCity config so it is not using any source control, it runs a single "powershell" build step that calls my powershell script.
The powershell script runs a single command:
exec { &$msbuild $ProjectFile /t:Package "/p:PackageLocation=$PackageFile;OutDir=$TempPath;Configuration=$Config;SolutionDir=$BaseDir\Source\" /v:m }
When I call the script manually from a powershell command line, I see:
CoreCompile:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
When I call the exact same script through TeamCity, I see:
[11:11:26]: CoreCompile:
[11:11:26]: c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig ...
<SNIP>
[11:11:32]: CopyFilesToOutputDirectory:
[11:11:32]: Copying file from "obj\Demo\Website.Web.dll" to "d:\deploy\Build\package\Demo\temp\Website.Web.dll".
[11:11:32]: Website.Web -> d:\deploy\Build\package\Demo\temp\Website.Web.dll
[11:11:32]: Copying file from "obj\Demo\Website.Web.pdb" to "d:\deploy\Build\package\Demo\temp\Website.Web.pdb".
[11:11:32]: _CopyWebApplicationLegacy:
[11:11:32]: Copying Web Application Project Files for Website.Web
[11:11:32]: Copying file from "obj\Demo\Website.Web.dll" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Web.dll".
[11:11:32]: Copying file from "obj\Demo\Website.Web.pdb" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Web.pdb".
[11:11:32]: Copying file from "d:\deploy\Build\package\Demo\temp\Website.Data.dll" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Data.dll".
[11:11:32]: Copying file from "d:\deploy\Build\package\Demo\temp\Website.Data.pdb" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Data.pdb".
Any ideas why running this script from TeamCity causes msbuild to detect changes and rebuild, but running the exact same script manually does not?
UPDATE:
Thinking this might be caused by some quirk with the TeamCity Powershell runner, I just tried making a batch file that passes the script into Powershell.exe and called it using the Command Line runner:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -File D:\deploy\Build\run-build.ps1 && exit /b %ERRORLEVEL%
and I get the exact same behavior. If I call this batch file from the command line, the msbuild skips compilation. If I call it from TeamCity, the DLLs are recompiled.
UPDATE #2:
Eureka! I turned on diagnostic debugging in msbuild and found the cause of the forced recompile. It is caused by the GenerateTargetFrameworkMonikerAttribute target. Here is the key bits from the log output:
[15:23:28]: Target "GenerateTargetFrameworkMonikerAttribute" in file "c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets" from project "d:\deploy\source\Website.Data\Website.Data.csproj" (target "BeforeCompile" depends on it):
[15:23:28]: Building target "GenerateTargetFrameworkMonikerAttribute" completely.
[15:23:28]: Output file "C:\TeamCity\buildAgent\temp\buildTmp\.NETFramework,Version=v4.0.AssemblyAttributes.cs" does not exist.
[15:23:28]: Using "WriteLinesToFile" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
[15:23:28]: Task "WriteLinesToFile"
[15:23:28]: Done executing task "WriteLinesToFile".
[15:23:28]: Done building target "GenerateTargetFrameworkMonikerAttribute" in project "SMM.Data.csproj".
It looks like this target creates/updates an AssemblyAttributes file in the TEMP dir as specified in the TEMP environment variable. Apparently TeamCity overrides the TEMP environment variable and sets it to: C:\TeamCity\buildAgent\temp\buildTmp and this directory is cleaned before every build.
I can see this if I call Get-ChildItem Env: from powershell:
TEMP C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
TMP C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
But if I call it from the powershell script as called from TeamCity:
TEMP C:\TeamCity\buildAgent\temp\buildTmp
TMP C:\TeamCity\buildAgent\temp\buildTmp
The key piece is that after this file is regnerated:
[15:23:28]: Building target "CoreCompile" completely.
[15:23:28]: Input file "C:\TeamCity\buildAgent\temp\buildTmp\.NETFramework,Version=v4.0.AssemblyAttributes.cs" is newer than output file "obj\Demo\SMM.Data.pdb".
And this is why the whole project is getting recompiled.
When I run the script from Powershell, the temp directory is not changed or cleaned and the build runs as expected.
So, anyone know how I can either change the directory that this AssemblyAttributes file is created, or tell TeamCity to use a different TEMP dir? I have to believe that this is an issue that others have run into.
Thanks!
So, as I mentioned in "Update #2" above, the problem seems to be caused by 2 things:
- TeamCity sets the TEMP and TMP environment vars to its own temp directory
- TeamCity "cleans" this temp directory prior to every build
- Part of the msbuild process runs a GenerateTargetFrameworkMonikerAttribute target that updates a specific file in the directory specified by the TEMP environment variable - causing the compiler to thing it needs to recompile the whole project
Once I figured this out, I found an applicable answer in this unrelated question:
In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?
So I added:
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
to both of the projects in my solution that compile to DLLs and it worked.
As a variation of obliojoe's answer, you can backup and restore these files to/from TEMP folder, if you do not want or cannot change the individual project files:
First attempt to restore the files from a backup:
copy temp\*.* %%temp%% /y
echo AssemblyAttributes restore attempted
Then perform your build step(s) using TeamCity build runner
Backup the files:
mkdir temp 2> nil
copy %%temp%%\*AssemblyAttributes.cs temp /y
echo AssemblyAttributes files saved
Both batch files need to run from the same directory.
Do note the final ECHO in these batch files, it is there to guarantee successful exit (error code 0).