I am fairly new to CI.
I am receiving the following msbuild error when trying to run my build on Dobby (my other Windows slave/node):
FATAL: \msbuild.exe doesn't exist
However, my Master's Global Tools path is set to:
Name: MSBuild v4.5.1
Path to MSBuild: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe
And on Dobby under Configure --> Node Properties I've added the tool locations as written above.
My question is will Dobby be able to execute the MSBuild from the Master server's file location? Or would I need to add tools to the Jenkins Home --> tools location in order for it to be recognized globally?
Let me know if you have any questions, thanks!
If I understand your question correctly then you would have to have the MSBuild set up on the node. When we set this up we used the absolute file path in the build. The code snippet below is from a Jenkinsfile (declarative pipeline) so we had to escape the backslashes.
bat 'C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\msbuild .\\solution_file.sln'
Typically with the master/agent setup in Jenkins you want to make sure the agent contains all of the information and tools necessary to handle the job.
Related
I have Jenkins v2.60.3 with the MSBuild Plugin v1.27 installed on Windows.
I have configured the path to my msbuild.exe in Jenkins' Global Tool Configuration. I have also setup a Multi Branch Pipeline in Jenkins that picks up a Jenkinsfile from git repo successfully.
My question is: How do I invoke the MSBuild Plugin as a step in my Jenkinsfile?
Please note I know I can invoke msbuild.exe directly as a Windows batch step but I prefer to go through the MSBuild Plugin if possible.
`
It looks like MSBuild is not supported by pipeline yet
https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md
You can try this in the meantime.
https://github.com/jenkinsci/pipeline-examples/blob/master/jenkinsfile-examples/msbuild/Jenkinsfile
Our teams need to migrate a ton of freestyle MSBuild jobs that were created in the UI. mjd's answer helped but still left me scratching my head. The examples just didn't work... until I figured out the disconnect.
Here's the secret sauce:
You have to call the "named msbuild configuration" directly using the
"bat" and "tool" commands.
go into the Config of one of your freestyle jobs that uses the MSBuild plugin
scroll down to the msbuild section and click the "MSBuild Version" drop down, take note of the exact names that are listed. This is your 'named msbuild configuration'. Choose one name that you will use in the next step.
open your jenkinsfile, locate the stage and step where you want to call msbuild, then add this line and replace 'MSBuild 15.0' with the name that you chose in step 2:
bat ""${tool 'MSBuild 15.0'}\\msbuild" SolutionName.sln /p:Configuration=Release /p:Platform="Any CPU" /p:ProductVersion=1.0.0.${env.BUILD_NUMBER}"
like so...
(For Declarative Pipelines, you'll need to put this inside of a "script" block. If you don't know what a 'Declarative Pipeline' is, it is one of two styles of writing pipeline scripts in Jenkins using the "groovy" language. For more info here is a comparison of the scripted vs declarative styles.)
run the pipeline and examine the output - the code you added in step three won't build anything, you just want to use it to see if msbuild will actually get called before investing anymore time into my script.
(I usually use the Replay button which allows me to edit the script online in Jenkins rather than editing, committing, and pushing to remote repo... it just saves a bit of time debugging.)
examine the output of the pipeline job you ran in step 4. You should see something like below indicating that the correct version of MSBuild was called. If not, you either have a typo or your administrator needs to intervene.
workspace\Pipeline_Test>"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\15.0\Bin\msbuild" SolutionName.sln
/p:Configuration=Release /p:Platform="Any CPU"
/p:ProductVersion=1.0.0.308 Microsoft (R) Build Engine version
15.9.21+g9802d43bc3 for .NET Framework Copyright (C) Microsoft Corporation. All rights reserved.
Congratulations you can now configure your build! Replace SolutionName.sln with your build file and pass the correct parameters to it.
I am surprised that all solutions doesn't work for me.
Platform : Window 10 Jenkins at latest version in 2020-11-05.
I am not sure if there's any reason that window & other OS will cause the pipeline script engine behaved differently.
Below are the possible encountered issues and solution finally combined with the above solution.
in my compiler, a single '' will cause error, '' must be escaped by replaced by '\'. which is similar to other char such as '"'
${tool 'MSBuild'} OR ${tool 'MSBuild 15.0'}\msbuild\ does not work, the error is the path cannot specified or cannot find the bat program. It must be an absolute path of the actual msbuild.exe
So this is the working solution for adding MSbuild in the pipeline script in window platform's jenkin
bat '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\msbuild" YourSolution.sln /p:Configuration=Release /p:Platform="Any CPU" /p:ProductVersion=1.0.0.${env.BUILD_NUMBER}'
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 have a Maven module that utilizes the NAR plugin to build some JNI libraries, and in Jenkins I have configured a Maven project to build this module. In order for these libs to be built, the Visual Studio bat file that sets up the path and other environment variables must be run. I have tried several different ways to get this bat file to execute before the Maven commands are called, and none of them have worked correctly. I know that Jenkins isolates all of the build process steps, so it can be difficult to get the environment set up, but I'm hoping someone has solved this particular issue. Here's what I've tried:
calling the bat file as a pre build step.
Using the EnvInject plugin to call the bat file, both as a pre build step and as a pre job step.
Setting the environment variables directly without calling the bat file using EnvInject.
calling the bat file from the mvn.bat file (this failed because it appears Jenkins will call Maven directly, without using the bat file).
As a workaround, I'm using the Freeform project type and setting the build steps to
call the bat file.
Directly call maven with appropriate parameters.
This works, but it's not as nice as using the Maven project type, ex. a failed unit test will fail the entire build instead of just sending a warning. Is there a way to configure this as a Maven project?
I would like to run Sonar plugin on Jenkins without any build process (my intent was to integrate Sonar analysis within Jenkins and take advantage of the subversion plugins and configurations we already had on there).
I do not want to run the build process since that would take up unnecessary time; I would only like to have a Jenkins job dedicated for Sonar analysis.
You can do that. You have to triggering the analysis with the SonarQube Runner.
Go to the Build section, click on Add build step and choose Invoke Standalone Sonar Analysis
Configure the SonarQube analysis. You can either point to an existing sonar-project.properties file or set the analysis properties directly in the Project properties field
When you analyse with SonarQube Runner , then you should give the following mandatory properties:
sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0
# Path to the parent source code directory.
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional. If not set, SonarQube starts looking for source code
# from the directory containing the sonar-project.properties file.
sonar.sources=src
In this case you may miss some rule violations (like FindBugs), because .class files are not provided. You have to build the project manually and set the sonar.binaries property to your class files. If you never want to build the project, then you can use the SourceMeter plugin for SonarQube too. It only needs the source files, but can produce more metrics and issues if you needed.
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.