I have a java project and I'm gonna build it using a build agent running TFS 2015. I've installed JDK as well as ANT and also set the JAVA_HOME and ANT_HOME system variables. However the build process fails because of the following error message.
Unable to find Ant. Verify ANT_HOME is set and pointing to a valid Ant installation on the build agent: http://ant.apache.org/manual/install.html.
According to the instruction here, I should also install TFS build extensions, but I assume TFS 2015 does not require that and it comes with it by default.
I can figure out what the problem is.
Ensure the user running the tfs build process has %ANT_HOME%\bin on it's %PATH% Setting ANT_HOME is necessary, but not sufficient.
Related
I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
We have a on prem installation of TFS (TFS 2017) and I am attempting to integrate SonarQube analysis into our build steps. I have installed the SonarQube extension on the TFS server and added a service endpoint to point to a server where I have SonarQube Server installed and configured.
When I attempting to trigger a build, I am getting an error "No agents could be found with the following capabilities: msbuild, java, visualstudio". Does my build server need JRE to be installed to get the SonarQube build steps to work? SonarQube website says this:
**Installation
Make sure the .NET Framework v4.5.2+ is installed
Make sure the Java Runtime Environment 8 is installed
Install the extension from the marketplace**
Both the error message and the documentation told you the same thing: You need Java installed.
I will be the third source of confirmation: You need Java installed.
First, the official document is very clear here: Make sure the Java Runtime Environment 8 is installed
Besides, according to your prompting error message:
No agents could be found with the following capabilities: msbuild,
java, visualstudio
You are also lacking msbuild, visualstudio. Not only need Java installed, but also need Visual Studio installed on your build agent, then restart the build agent. Restarting the build agent will capture the added Capabilities. If this not work, reconfigure the build agent should do the trick.
The build agent will not detect the environment changes after you installed it. It will only detect during the installation. If you are using vNext build agent, also try to manually add some capabilities in Settings- Agent Queues- Agent Pool - Agent- Capabilities. After this trigger the build again.
Note: if you are running on TFS earlier than 2017 Update 2, you will need to download and manually install the latest 3.x version of the VSIX to install SonarQube Extension.
I am grappling to understand how Tfs’s VNext build handles NuGet.exe versions under the hood.
I am running a Tfs 2018 (16.122.27102.1) on-prem server.
My agent is running (as a windows service) on my machine on the location “C:\dev\tfs_bld_agents\scully\”
If I understand it correctly the “Nuget tool installer” (1) will ensure that the NuGet.exe version specified in the build task (in this case 4.3.0), will be installed where this build definition is executed by an agent.
The subsequent build task “NuGet Restore”(2) will then run the NuGet.exe installed by the previous build task(1) and will execute the NuGet restore command.
If, however, I search through the build agent's root folder on disk “C:\dev\tfs_bld_agents\scully\” I find an array of different versions of NuGet.exe
3.3.0
3.5.0
4.0.0
4.3.0
Directories, where a version of NuGet.exe resides, are:
What is the reason for this behaviour i.e. having all these different versions within the build agent folder, seeing that the NuGet.exe version specified by my build definition was only version 4.3.0?
Assuming that we for instance do not (or cannot in older Tfs versions) run the “NuGet Tool Installer” build task, how will the Tfs build agent go about figuring out where to find a NuGet.exe on the machine?
These NuGet.exe versions are included in the NuGet Tool Installer task and NuGet task by default. When you queue a build, build agent downloads the tasks build needs, then you will see these NuGet.exe versions.
So I performed some tests attempting to track what happens when you use different versions of NuGet within the “Nuget tool installer” Tfs build task. For the baseline, a Tfs2018 (16.122.27102.1) build agent (of type service) was used, just extracted and configured.
After configuring the build agent, you will have the following NuGet.exe in your agent directory:
NuGet.exe version: 3.3.0 (3.3.0.0212) - Note: this is just after the agent was configured, no builds have been run here!
I then proceeded to set up a build definition that will be executed by agent mulder. The build definition contained the “NuGet Tool Installer” build task. My first try was to specify NuGet 2.8.6 and then run the “NuGet Tool Installer” build task.
After this task was completed, we find the following NuGet.exe artifacts within our build agent folder:
NuGetInstaller
NuGetToolInstaller
As well as the NuGet version we requested, provided on location ...\_tool\NuGet\2.8.6\x64\nuget.exe
From this point onwards, the content of the ...\_tasks\ folder seems to remain constant in regards to NuGet.exe versions, regardless of which version you specify.
The only obvious change being, the addition of every new version you select within this location ...\_tool\NuGet\{version requested}\x64\nuget.exe.
So if we painstakingly select each possible version in the “NuGet Tool Installer” build task and run it, we will end up with a spread that looks like this:
Regarding the logging produced by the agent running the “NuGet Tool Installer” build task, the thing that stands out is the fact that after each switch in the NuGet version, the following message appears: Prepending PATH environment variable. I assume the purpose being to point to the selected NuGet.exe version on disk. In the case of version 2.8.6 we see the following:
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
So what happens if we revert back to a specific version? Let say from v4.5.1 to v2.8.6 - does it clean up some versions?
No. It leaves everything intact but does modify the PATH variable again to point to the correct version you reverted to.
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
An interesting phenomenon is that you cannot see these "Prepending" changes in your PATH environment variable.
If you, however, run the build in debug (by flipping the system.debug variable to true) you see some interesting details. This time around I can see that the variable(s) are indeed slipped in front of the existing PATH variables (that are visible in the environment variables GUI), as well as 2 more at the end.
Debug logging looks something like this:
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
new Path:
C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64;
C:\TfsBuild\mulder\externals\git\cmd;
.
..
<The existing paths variables>
..
.
C:\TfsBuild\mulder\bin;
C:\TfsBuild\mulder\bin
It thus seems to retrieve the existing PATH environment variable, and then slot in the “new” required variables in front of them while running the build.
Clearly Tfs build is very good at ensuring that there is always a correct version of NuGet.exe at hand, but cleaning up old versions is not its strong suit :-)
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
I have a TFS 2017 Update 2 on-prem server with VS 2017 Enterprise installed. Our Build contains a Unit-Testing project which contains a Fakes assembly and works locally on the dev machines.
When build on TFS, the build fails with
The type or namespace name 'Fakes' does not exist in the namespace
'Our.Product' (are you missing an assembly reference?)
(i.e. misses/fails to generate the Our.Product.Assembly.Fakes.dll file)
I have additionally set up Fakes as suggested here.
What baffles me is that there are no mentions of Fakes in the build log (except for the error itself and the paths where MSBuild looks for the file), even with debug verbosity. He doesn't event try to generate the Fakes assembly.
Are there other steps I need to take? We use the vNext build definitions.
Update:
This is the build step that works now, before the /tv:15.0 /p:VisualStudioVersion=15.0 were not there.
Update
Use the latest version for msbuild arguments such as /tv:15.0 /p:VisualStudioVersion=15.0 could solve this issue.
First try to use build service account RDP to remote build agent and manually run the build to see if the assembly generated.
This will narrow down if it's related to your environment on the build agent. Make sure it's the same as your locally dev machines.
If the assembly is also generated, then the issue may related to your build definition settings. Check if you are using the right msbuild version. For vNext build, also enable verbose Debug Mode with system.debug=true