When I queue my builds in VS 2013 using the "Hosted Build Controller"(Visual studio online) my build keeps saying:
![enter image description here][1]
Position In Queue = 1 (Waits in the Queue for more than half an hour)
It is not starting my builds inspite that fact that I have no other builds in queue or or running.
Sometimes it gives me the message saying the connection to the build server was lost.
Not Sure why this is happening because earlier when I initiated my builds using VS 2010, my builds used to start immediately.
Any help is greatly appreciated.
You're dealing with what can be a painful issue. Have you tried creating another agent? You can specify which agent to use when queuing the build. If other agents work and not this once, you may have encountered a bug that requires updates to your current version of TFS.
If new agents consistently fail or don't fail always, then you're dealing with a bigger issue that can be due to performance, cross-geography issues, or with too much latency loading your template. I believe one thing that can cause issues with this is having too many agents. I would also try clearing your build caches out. C:\users[user]\appdata\local\temp (i.e. BuildAgent/Controller). Also, definitely make sure your build software matches your TFS version (including the update). Slight differences there can cause issues.
Related
We are using the onPremise version of the DevOps Server 2019 (curently update 1) with self-hosted agents (agents have the last version available from gitHub) in combination with TFVC (2019).
The devOps server is running in a virtual machine and the tfvc server is running in a different virtual machine.
The communication between them is fast, i tested this already by simply copying big testdata from one to the other over network. There is no Problem.
On each and every run, at the very beginning, the workspace mapping from a previous run is getting deleted, a new one is created and than a new workspace mapping to every source paths defined in the repository is established. This is taking about 30-60 Minutes on each and every pipeline/run.
We dont have only one single path in the repository defined. there are a lot of mappings, so that the amount of code that gets taken from TFS stays little and only represents that source code, that is needed by this executed solution.
This can't be changed and has to stay as it is, also we can't simply move to github. (Just sayin in case someone would like to advice to move to github :))
Are there any people, that experienced the same behaviour in the past, that the repository paths mapping at the fist build step is taking about 30-60 minutes when a build is executed?
thanks for any hints in advance
The solution now was, installing everything from scretch on a new machine.
After that, the mappings are running in a 10th of the time it took before
I am running a new sonar server with one project and one quality profile.
I have a "runner" machine that continuously running full scans (after getting the latest code)
and the developers machines where they would like to run incremental analyses before checking-in.
when running an incremental on the "runner" machine without making any changes I get 0 issues as expected (but I am also getting a lot of "resolved" issues - what is the deal with that? I expected to get 0 new and 0 resolved since I changed NOTHING).
BUT, when running incremental on the developer machine (after getting the latest code) I am getting a huge number of new issues, even though they also made no changes to the code.
to make sure I am not making any mistakes, I used TFS to compare the two project directories (on the runner and on the dev local machines, the folders that the analysis uses) - and proved that both are the same (except for the sonar generated files)
so to sum it up:
what could be the cause for such a behavior?
why would I get resolved issues if I did not make any changes to the code?
could it have anything to do with machine clocks? (i am desperate...)
If you would tell me that there is no change in hell that such a problem can occur, then I would go back and check myself, but I am running such a simple configuration that I don't think that I am missing anything.
Thank you for your help.
I have been using the Build-Deploy-Test build workflow for TFS 2010 (see here http://msdn.microsoft.com/en-us/vstudio/gg131922.aspx) and would just like to know if there is a way you can queue one or more of these to run on the same lab environment?
I have come up with a brittle but (mostly) working solution to this by modifying the Build Template. I set the 'environment in use' flag whenever the workflow starts, and any subsequent workflows loop and wait for the flag to be cleared.
My solution works most of the time, but occasionally I experience race conditions and both workflows try to start at the same time, one 'winning' and reverting the environment to a test-ready snapshot first.
As you can tell, this is a poor solution but a quick one! Is there a proper way to queue Build-Deploy-Test workflows on an environment?
There is no way to do this out-of-the-box with TFS 2010; this confirmed by allen from Microsoft (see comments).
I solved this issue more satisfactorily by implementing a custom build activity that maintains an in-memory register of all builds using a particular lab environment. I interact with this activity using a modified version of the DefaultLabTemplate, waiting to start the build until the configured lab environment becomes available.
The solution is by no-means perfect, as it does not scale beyond a single build controller but works sufficiently for the needs of my organisation!
I've been using the Publish Wizard in VS2010 to deploy my MVC app and I've got no issues there but intermittently the publish will fail with the following error.
Error 23 Web deployment task failed.(Could not complete the request to
remote agent URL 'https://webserver:8172/msdeploy.axd?site=mysite'.)
Could not complete the request to remote agent URL
'https://webserver:8172/msdeploy.axd?site=mysite'. The request was
aborted: The request was canceled. COM object that has been separated
from its underlying RCW cannot be used.
It seems to happen at random but the longer I have VS open the more likely it is to occur and the guaranteed way to fix it is to restart VS but it occurs like clockwork if I leave VS open for prolonged periods of time (all day or overnight) and is starting to get very frustrating to have to restart VS every time it happens. I honestly don't recall if the error number is always 23 or not, I'll look for that next time it happens, but has anyone else had this problem or know what might be causing it?
Update:
The problem is still present when using VS2012 as well.
We discovered this bug shortly after finalizing the RTW components for web publishing. To give you a bit of background, the underlying issue was very difficult for us to uncover. After some through investigation we were able to pinpoint the issue to being related to how internet connections are managed by the singleton RCW object used by WPF and whether requests are coming in on an STA or MTA thread.
Fortunately we were able to workaround the underlying issue and have a fix ready. We are planning to update the web publishing bits in a few months which should resolve this issue once and for all. Until then the workaround is to close VS and then re-open it. I know that this is not an ideal workaround, but that is the best that we can do at this time.
According to http://www.asp.net/mvc/tutorials/deployment/deployment-to-a-hosting-provider/deployment-to-a-hosting-provider-creating-and-installing-deployment-packages-12-of-12
"COM object that has been separated from its underlying RCW cannot be
used." Scenario You have been successfully using one-click publish
to deploy your application and then you start getting this error:
Web deployment task failed. (Could not complete the request to remote
agent URL 'https://serverurl.com/msdeploy.axd?site=sitename'.) Could
not complete the request to remote agent URL
'https://url/msdeploy.axd?site=sitename'. The request was aborted: The
request was canceled. COM object that has been separated from its
underlying RCW cannot be used.
the solution is:
Possible Cause and Solution
Closing and restarting Visual Studio is usually all that is required to resolve this error.
I'm trying to work out an automated Build-Deploy-Test workflow using Lab Management/VS 2010 and everything is working ok... except for one small thing.
In my build definition, within the process>environment I set a snapshot that I want the environment to be reverted to before deploying, and this works fine, but when the snapshot is reverted to, the environment is stopped but not restarted.
What results is that the build waits indefinitely for the workflow capability to be available on the environment.
A temporary fix is to just watch and wait for the enivonment to be stopped, and then to start it manually and everything will proceed as expected... but this is hardly ideal.
This is happening to everyone on my team, and none of us have come across a solution. Has anyone else seen this and solved it?
You'll want to take the "Initial Snapshot" when the VM is actually turned on. You can do that, or you can customize the Lab default build process template and include a StartEnvironment workflow activity after the restore snapshot phase.
My suggestion would be to just take the snapshot when the VMs are turned on though. That's the way I have always ended up doing it.