I've followed this guide to have my TeamCity build running some JMeter tests, but I'm not seeing the "RemotePerfMon" tab for the server statistics. I have the "Performance Statistics" tab, and I can see that the statistics are definitely being collected, as there is a monitoring.csv file being created and populated in the build agent's work directory.
Any ideas on how I can get the tab to display?
I'm using TeamCity v9.1.6 with JMeter plugin version 83, everything running on Windows 8.
Additional Info:
I've found that there is an open issue on Github for this problem, so I'm obviously not the only one facing this issue.
Make sure TeamCity is NOT running as Administrator
After quite a while playing around with it, I discovered that the problem was that both the TeamCity Server and the TeamCity build agent were running on the same machine, but the Build agent was running as Administrator. Stopping both the services and restarting them as a regular user fixed the issue.
I believe the root of the issue was that the monitoring.csv file was created by the Build Agent as Administrator, then wen the non-admin server agent attempted to parse it, it failed. This error doesn't seem to get logged anywhere, and TeamCity responds to the error by simply not displaying the tab.
Related
I've recently installed TeamCity 2017.2.3 (build 541047) and Octopus Deploy 2018.1.5 and originally was having success running builds and creating packages in TeamCity, but now my build agent shows all of my build steps as incompatible after a service restart.
I've uninstalled and reinstalled the buildagent, plugins (I use Node.JS build runner, Octopus Deploy integration, and xUnit) and rebuilt each of the build steps, but still run into the same problem
Build Step List
Anyone know what would be causing this issue?
Each agent should have a list of global parameters that are picked up from the OS or manually configured from the agent properties file on the machine. These are things like the path, dotnet versions, npm etc.
http(s)://<tc root>/agentDetails.html?id=<agent id>&tab=agentParameters
(You can get to the above by clicking on the agent you want to inspect)
You can then override or add to these from the root project all the way up the project tree to the build configuration.
The message you are getting is saying is that in order for the build to run it needs to have an agent with those parameters configured. Could you give a screen grab of what your build agent parameters are.
Here is an example from one of my build agents which shows some of the configuration parameters that you need.
You should not need to add these, they should be picked up automatically by the agent.
First make sure these dependencies are actually installed.
If missing install and restart the agent service (required to pick up new configuration properties).
Possibly try a machine restart in case newly installed components require a reboot.
Failing that check to see what permissions the build agent service is running under. It might not have permissions needed to poll the system but I have never seen that.
I ran out of release/build minutes on VSTS, therefore I configured an on premise agent to run my builds. This is working fine, however I cannot select that agent to be used for deploying my releases.
I tried to follow the following tutorial, however it seems like it is a bit old:
http://vsts-deploy-guide.readthedocs.io/en/latest/
Does anyone have experience setting up on premise agents to do the deployment?
Refer to these steps:
Open release definition
Select Environments tab
Click Run on agent
Change Deployment queue in right panel.
I am trying to run SonarQube using Sonar runner in local dev box for pre-commit check. We have a central SonarQube server where a analysis is done every day and published to the dashboard. When we are running on local dev box everytime the the issue report contains all the issues as new hence incremental data is not available. I have also tried both incremental and preview mode but the result is some.
Please find below the version of the tools used.And also configuration files. Please let me know if some other data is required.
SonarQube version : 5.1
Sonar Runner version : 2.4
sonar-runner.properties
sonar.host.url=http://[central sonar server]:9000/
sonar.issuesReport.html.enable=true
sonar.login=admin
sonar.password=admin
sonar-project.properties
sonar.projectKey=myProj:myProj-master
sonar.projectName=MASTER_PROJECT
sonar.projectVersion=21.0
sonar.sources=./src
sonar.binaries=./bin/
sonar.issuesReport.html.enable=true
sonar.exclusions=com/**/test/*.java
sonar.skipPackageDesign=true
sonar.profile=SonarWay
sonar.preview.excludePlugins=devcockpit,buildstability,pdfreport,report,buildbreaker,views,jira,issueassign,scmstats
Command Used :
c:\sonar-runner-dist-2.4\sonar-runner-2.4\bin\sonar-runner -e -Dsonar.analysis.mode=preview -Dsonar.issuesReport.console.enable=true -Dsonar.issuesReport.html.enable=true
Updated with additional properties tried as well. in sonar-runner.properties
I believe your problem is tied directly to your use of a local server.
The purpose of preview analysis is to allow you to compare your local changes with what's on the remote SonarQube server. Since your remote server is update every night, running your preview against it will show you the issues you've introduced that day. Instead, you're running against a local instance which gets updated with a full analysis... never? Which (if true) would be why all your issues show up as new.
To execute a preview analysis against your remote server, you will need both the global Execute Preview Analysis permission and the project-level Browse permission for the project in question.
If for some reason you're unable to get those permissions (which is possibly why you're running a local SonarQube server?) Then you'll want to do the same full checkout and analysis locally every night that's being done for the official, remote server. I.e. you'll probably have to set up a second, parallel architecture. In short, it's probably easier in the long run to nag to get the appropriate permissions on the remote server.
Issue is resolved . 2 things fixed the issue.
Creating a user with the required permissions.
Installing "Issues Report" plugin
We're working on setting up a TFS server for our work, and I'm in charge of getting the build working. I have had no experience with TFS before, but setting the build controller and agents up using the wizards was easy enough. We have the TFS server on one machine, and a build controller and build agent on another machine registered to the TFS server.
When I start a build from my developer machine, the build reports as having started and the status of the controller changes to something like "running build vstfs://Build/Build/16". However, the status of the Agent never changes from "Ready" and the build hangs indefinitely. If I stop the build from my developer machine, it reports that the "build was forcefully stopped by the server because the build machine did not respond to a stop request", and the build controller still has the status of "running build". I need to restart the build controller in order to reset the status.
I've checked that port 9191 is unblocked, and I can telnet into the port from my developer machine. The server also seems to be able to communicate with the build machine, as the controller is receiving build requests, but I have no idea what to do from here. Any TFS experts have any idea what might be happening?
Thanks,
Zach
Found the problem.
Under the build service properties, We had the value "Listen for build agent communication on:" set to [BUILDAGENT.companydomain.com:9191/Build/v5.0/Services. We needed the value to be just [BUILDAGENT:9191/Build/v5.0/Services]
So we make use of TeamCity as a CI server (v 7.1.1). And we use MS' own web deployment tool as a means of publishing to our servers (standard ASP.NET fare). However, I've noticed that the batch files that are generated by web deploy seem to play badly with TeamCity.
This is what appears in the build log:
http://dpaste.com/826346/
The script clearly says an error has happened. However, TC seems unable to detect this, as no red lights come on. Is there a (good) way to fix and detect this, so we don't get incorrect build runner status reports? TC is currently setup so that the deployment script is executed by a Command Line runner.
To fix it, change the IIS site AppPool to .net version 4.0 - Your error message says that the app expects 4.0 but web deployment tool is finding 2.0
To detect it, I think you can configure the Build Failure Condition, to fail a build when "an error message is logged by build runner".