Since 2 days we have a really big issue on our TFS system.
After the build agent activity the build stay stuck undefinitely.
We have detected that the issue is linked to the NotifyBuildCompleted action in the closure part of the build event.
A timeout occured each time this part of the build process is reached.
At the end the build agent is available but the build controler is still busy with the closure and will not see anymore the agent as available.
On the Build overview panel I can see the build is still "In Process" and also it's in the completed tab . The duration, completed date and execution time have bad values. In the database the tbl_buildqueued stay with the build status 1 instead of the closed status.
We have CI build since 1 month and it's the first time we have this kind of issue.
Did someone have a solution or an idea to solve this issue ?
Run the BPA which can be downloaded from here and see if there are any issues with the accounts that are used for TFS, particularly the SQL and sharepoint accounts
After weeks of search and contact with microsoft it's something linked to the stored procedure.
To avoid this build stuck we add 1 GO memory on our SQL server .
Now build are correctly stoped / finished by the NotificationCompleted event.
Regards
Related
I am working on a project that uses Codeship to deploy builds. I got up today and saw:
Normally a build takes ~2 minutes, but I have waited on this one for half an hour. Codeship does not show anything being run. Not a single command. And my integration does not show the new application version, either.
How can I fix the hanging build?
Fixed! I just had to stop and restart the build as well as reset the dependency cache. Thanks #mlocher for the help.
If anyone came here from a search engine or something else with the same problem, try to restart the build, restart after resetting the dependency cache, or making another commit with a trivial / no change. This should fix the problem. Otherwise, send codeship a ticket at helpdesk.codeship.com.
My client has ~10 team projects in TFS 2013 that we are currently migrating to VSTS. During this last week, 9 of those 10 team projects (which are fairly small/medium in size/changeset numbers) migrated in a totally reasonable amount of time. However, the last (and most important) team project is large, and it appears to be stuck during migration. It has been stuck at migrating step 405/700 for us for ~9 hours now.
I am mainly concerned because the migration was churning along decently yesterday up until I left work for the night yesterday, but I had a (unrelated) computer crash overnight, and so I don't know if that has had an impact on the migration. Because of the computer crash I had to restart the migration this morning, and it seemed to pick up where it left off, but it has not budged (according to the UI) all day. The last changeset I see checked in to our VSTS was at 8:18pm last night, which means nothing has made it over to VSTS for almost 20 hours.
Upon looking at the logs, SOMETHING seems to be happening - it is still writing data to the logs. I'm just hoping that someone can tell me to have patience because it is still working (just slowly), or if it is truly stuck and I should start over and/or have a plan B.
Thanks in advance
The case has been resolved. The tool was running out-of-memory while processing a large changeset, since default allocation of memory to JVM was just 1 GB. Providing more memory did the trick and the migration completed.
Steps to increase the allocation.
1) Close application
2) Go to \OpsHub Visual Studio Migration Utility\OpsHubServer6.0.16\bin (Installation Drive may be: C:\Program Files)(Folder name might be OpsHubServer6.0.16 or just OpsHubServer depending on your version)
3) Open service.bat in NotePad. Find following string "-Xmx1024m". Replace -Xmx2048m to -Xmx4096m (or the appropriate number for the max memory size, if you have more available)
4) Save file
5) In same folder
Run unregisterservice.bat as administrator (Which will unregister OpsHub service. Verify by opening services.msc there will be no "OpsHub Visual Studio Online Migration Utility" service any more)
Run registerservice.bat as administrator (Which will register OpsHub service. Verify by opening services.msc and there will be "OpsHub Visual Studio Online Migration Utility" service with "Automatic" startup type)
6) Open services.msc, Right click on "OpsHub Visual Studio Online Migration Utility" , Click on properties, select startup type "Manual" click on "Apply"
7) Start application which will now use 4096m memory (4 GB) or whatever amount specified in step 3
We use Coverity's free scanning service for free and open source projects. We have not been able to utilize the service for the last two months or so. Prior to the service failures, we had half-a-dozen or so good analysis.
Submitting a scan results in:
Last Build Status: Failed. Your build has failed due to the following reason. Please fix the error and upload the build again.
Error details: :Failed to retrieve tar file
Coverity is very good about providing copy/paste directions, and we have copied/pasted them religiously. We verified there are no build errors, and we verified the build ends with "131 C/C++ compilation units (100%) are ready for analysis" and "The cov-build utility completed successfully".
We've tried to resolve the issue by verifying things from this generic solution provided in a "failed email" response from the service. We verified or performed all of them except number four.
We did not perform number four because Coverity's documentation is horrible (its the exact opposite of their awesome scanning service). Because there's no instructions or RTFM to read, we have no idea which knobs should be turned for bin/cov-configure. We don't want to mess with it since it worked in the past.
We also tried the following:
using the web submission form and browser
using curl from the command line
packaging cov-int/ in a tarball
packaging cov-int/ in a zip file
using all lowercase for the project name
capitalizing the first letter of the project name
We always get the same message ("Failed to retrieve tar file"), even with a ZIP file. Recall that prior to about 6 weeks ago, everything was working fine.
What is the secret to uploading a file to the service? What has changed in the last six weeks or two months?
After contacting the coverity support we just received the following answer and we could successfully submit a build. Seems there was some hickup on the coverity side.
"This was due to some behind the
scenes issues on our end – nothing interesting,, but it is back up and
running now. Thanks for your patience".
Situation in short:
Virtual Machine with Visual Studio 2013 installed. PowerShell script
runs on the VM to execute Get Latest, Build and Execute Coded UI
Tests. Windows Scheduled Task to execute PowerShell nightly.
auto-logon is enabled (or I'm doing something wrong?)
yes, I've read post Is it possible to run Coded UI tests without having to connect via remote desktop?
I've seen posts about TCM. Does this help and how can I use it in my
situation?
I made some tests in Microsoft Test Manager and I also executed and recorded them.
I've loaded these tests in a test project (and changed the script providing categories and custom checks).
I then categorized these (as Development or Acceptance).
I executed out using a PowerShell script on a VM (with Visual Studio 2013 installed) with following actions:
Get Latest
Build
Run latest build with a selected set aka category using mstest.exe
So far everything is going perfectly. All the tests pass.
However, when I create a Scheduled Task on my VM run the PowerShell script everything fails because of a missing session.
Do I have the VM (I have no knowledge of Virtual Machines) then unlock or something?
Side-Note:
I also tried to fix this with a Test Agent and Controller, but once I had installed these, all other users of TFS lost their rights, so I prefer not to do this again.
I would be very grateful if you know something that can solve this.
I spent hours on Google finding a solution for this issue, but no solution helped me.
Do I need to provide more information?
The problem you're seeming to have is that the testagent is not setup correctly. You need an active desktop session for Coded UI to be able to run (it needs it to perform all the actions such as clicks).
Microsoft has some nice info about setting up your test agent here.
But to tackle your exact problem of the test failing because of a missing session I'd suggest the following:
Run AutoLogOn.exe from the sysinternals suite (can be found at http://live.sysinternals.com/). It will automatically log in with specified user when the machine starts, and keeps the desktop session active.
Alright...I'm making progress.
I've installed test agent and controller. It's all running fine.
Next I've opened Lab Center on my own MTM to create a new environment.
Test Controller is found, but I receive the message in this post "Microsoft Test Manager cannot install test agent on these machines" when creating new Lab Center environment
File and Printer sharing exception is enabled. I don't get the other message.
I don't understand what is wrong.
Maybe I'm completely on the wrong track and it's not necessary to use the Lab Center.
Then the only remaining issue is the non-active desktop issue.
I am getting the following error when running a migration from TFS on-premise to Visual Studio Online
OpsHub-012010: Processing blocked - earlier event(s) for entity 11888 have to be processed first.
This is the second time i am trying to run the 'source control' migration on the same project.
I got the same error the first time after 3700 changesets. This time it happened after 5300 changesets.
I also tried to flag the Failure item for a retry and rerun the process, but I keep getting the same error.
use latest version 1.0.1.005
Also Can you please zip up and send us the log files from location :\Program Files\OpsHub Visual Studio Online Migration Utility\logs and email them to ovsmu#opshub.com
Please include a reference to this request in your email
so we will provide proper resolution to this thread.