We use DELPHI 10.4 and MSBuild on a JENKINS slave for CI within our projects.
As the paths to *.exe output, search folder, .... in the given *.dproj on our local clients are different on the JENKINS slave we use *.optset files with paths adjusted to the Jenkins slave.
This strategy seems to work nicely except for some project where it seems that the compilation is only based on the *.dproj settings.
To ensure the use of an options file we add to the *.dproj the following statement
<Import Condition="Exists('$(OptSet)')" Project="$(OptSet)"/>
But this seems to fail sometimes.
Q: how to force the usage of the *.optset file, how to handle the compilation on different systems with MSBuild - some very flexible replacements for path settings.
Related
I would like to call MSBuild in Jenkins, in a shell step. Although from what I recall; you can access only the workspace folder, which is what is allowed in Jenkins.
How do you actually build in Windows environment, when using Jenkins, if your build tool is in Windows\Microsoft.NET\Framework ?
Although from what I recall; you can access only the workspace folder, which is what is allowed in Jenkins.
That is true for the source on which your command (here MSBuild) will operate on.
But the command itself can be called (from a build step) with its full path, even though said full path is outside the local workspace.
Or you can specify that installation path through the Jenkins MSBuild Plugin.
To use this plugin, specify the location directory of MSBuild.exe on Jenkin's configuration page.
The MSBuild executable is usually situated in a subfolder of C:\WINDOWS\Microsoft.NET\Framework. If you have multiple MSBuild versions installed, you can configure multiple executables.
Then, on your project configuration page, specify the name of the build file (.proj or .sln) and any command line
arguments you want to pass in. The files are compiled to the directory where Visual Studio would put them as well.
I've been pulling my hair out on this for a while now. I'm trying to implement a continuous integration and deployment pipeline using TeamCity and Octopus Deploy. I am 99% there, except for one problem. I am using the standard msbuild runner of teamcity, configured to use the version 12 of msbuild.
I need to include the web.config transforms in the published output so they can be packaged into a nuget package for octopus deploy. I do not want the transforms to be applied by msbuild.
I am not using Octopack to create packages. I'm using the built-in teamcity nuget packager. So I'm publishing the website to a filesystem folder and then creating the package from the files in this folder. However, no matter what I do I cannot get msbuild to include the web.config transform files in the publish (I am using Octopus Deploy to perform the transforms, so I don't want msbuild to perform them).
I have verified that all the transform files (Web.Release.config, etc..) are marked as "Content". I have NOT marked them to copy always, because doing this copies them to the bin folder, not the root folder where they belong.
I have removed the /p:Configuration= property from the msbuild command line as I've read that is required for transforms to be applied. my parameters to msbuild look like this:
/p:DeployOnBuild=true /p:PublishProfile=Deployment
There is nothing in the publish profile that seems to relate to transforms. The publish profile contains the filesystem location to publish to.
Any suggestions here?
Note: I've given up and found a different solution, but I'm leaving this open in case anyone has any input.
You could create a custom .nuspec file and reference the files that you want to include from there.
My suggestion would be to have the .nuspec file in the same directory as the web.config / web.release.config files, and make the paths relative from there.
So if you publish to a directory called /output you could use rules like this
<files>
<file src="*.config" target="\" />
<file src="publish\*.*" target="\" />
</files>
So nuget pack nuspecPath would become the way to pack the project
NuSpec Reference
Hope this helps
I have a number of Gradle builds that work very well from the command line, from buildship, etc.
However now I am porting them to a Jenkins system. And it is producing some very strange results. I'm pretty much a total newbie to Jenkins, so this may have an easy answer. So far I haven't found it.
I am using the Gradle Plugin for Jenkins, v.1.24 to configure my build in Jenkins. However, Jenkins (at least as I have it configured) organizes its build structure as {jenkins root}/data/jobs/{project_name}/workspace. When code is checked out of source control it is deposited in that directory, not in a directory named {project_name}.
Gradle seems to assume that the directory in which it is running names the project, and when I'm running outside of Jenkins this assumption is true. The name of the project that Gradle sees is the name of the project that was checked out from source control. Project.name is a gettable but not a settable property of a gradle Project. So in the Jenkins case, the archives that gradle builds are named workspace* rather than {project_name}*. It is also named workspace in the repositories it publishes into. I must be missing something very obvious but for the life of me I cannot figure out what it is.
Has anyone grappled with this?
UPDATE - It appears that the problem is that the people who designed my Jenkins instance knew nothing about Gradle. The {jenkins root}/data/jobs/{project_name}/workspace layout that I described above is not required by Jenkins, but apparently was felt to be useful for some reason in some other, non-Gradle context. So the question becomes, where is the project layout set up in the Jenkins configuration - OR - can Gradle be modified somehow to assume a different project layout/naming strategy.
Set Manage Jenkins → Configure System → Advanced... (the one right at the top) → Workspace Root Directory: ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}.
The inline help:
Specify where Jenkins would store job workspaces on the master node. (It has no effect on builds run on slaves.) This value can include the following variables.
${JENKINS_HOME} — Jenkins home directory.
${ITEM_ROOTDIR} — Root directory of a job for which the default workspace is allocated.
${ITEM_FULL_NAME} — '/'-separated job name, like "foo/bar".
Changing this value allows you to put workspaces on SSD, SCSI, or even ram disks. Default value is ${ITEM_ROOTDIR}/workspace.
.../jenkins/config.xml
...
<workspaceDir>${JENKINS_HOME}/workspace/${ITEM_FULLNAME}</workspaceDir>
...
Gradle seems to assume that the directory in which it is running names the project
Yes this is gradle's default behavior, but can be easily overridden. If it is just the output artifact name you're concerned about, override the jar name with:
jar{
baseName 'actualProjectName'
}
We have Delphi 2010 setup as described here and jobs are running fine.
Now we need to add Delphi XE5 to that node as well.
Problem are variables BDS and BDSCOMMONDIR.
They are set as global variables pointing to e.g. BDS points to C:\Program Files (x86)\Embarcadero\RAD Studio\7.0.
For XE5, BDS should be have the value of C:\Program Files (x86)\Embarcadero\RAD Studio\12.0.
So how to setup multiple delphi versions?
I am using batch scripts for each build job.
Each script is able to set different environment variables. Basically I set the content of Delphi's rsvars.bat in my specific build scripts (Delphi paths, path to MSBuild depending on Delphi version etc.).
So the build script for a distinct build job contains the call to MSBuild (thus I have not set up MSBuild through Jenkins).
Could look something like this for you:
set BDS=C:\PathToDelphiLib
set FrameworkDir=C:\Windows\Microsoft.NET\Framework\v3.5
set FrameworkVersion=v3.5
set PATH=%FrameworkDir%;%BDS%\bin;%PATH%
set LANGDIR=EN
// set other variables
echo ### building the project
MSBuild.exe %WORKSPACE%\YourApp\YourApp.dproj "/p:Win32LibraryPath=$(BDS)\lib" /target:Build /p:config=%AConfigVariable% /p:Platform=Win32 /p:DCC_ExeOutput=%OutputDirVariable% /verbosity:quiet
In Jenkins then I can set up the Build using Windows Batch
call %WORKSPACE%\YourApp\ContinuousIntegration\DelphiXE2_Build_Release.bat
An advantage is that you can cascade batch scripts and keep all that logic away from Jenkins. I have also put my build scripts under version control. Everything is inside the repository and under control.
Using Delphi 2009 (or higher) and the ITE (Internal Translation Manager), how can I build the language projects from the command line? The projects are for example
Project\Languages\DEU\Project_DEU.bdsproj
Project\Languages\ENG\Project_ENG.bdsproj
Theses bdsproj files are not MSBuild projects, so do I have to call DCC32 and pass all search paths and compiler parameters using a script file, or is there a way to use MSBuild for this task, if I specifiy a special build target?
You could have a separate .groupproj including the .dproj files.