I have been having constant issues with the OpsHub Migration Utility erroring at different stages in setting up a migration, but when I finally get a migration going it fails after 15 minutes or so with the following error:
"Unable to get prject map for system : {my on-premise TFS url} to {my VSTS url}| TFS Source 1462312056714 Source TFS 1462312056719 due to :
OpsHub-014301: Error in getting project metadata for system :
TFS.OH-TFS-Connector-0048: Failed to login to Team Foundation Server : {my on-premise TFS url} with user : null.
Server Error : TF400324: Team Foundation services are not available from server {my on-premise TFS url}.
Technical information (for administrator):
The underlying connection was closed: An unexpected error occurred on a receive.. You may have given wrong credentials or are not valid now..."
I previously tried doing migration with ~6500 Changesets (our main project) and got a similar error after an hour, except that none of the changesets had passed. So, I tried migrating a smaller Team project with 182 changesets and it failed after 72 changesets.
This smaller migration then restarted on its own and was able to get to 148/189 changesets before failing again for the same error.
Eventually I was able to complete all 189 changesets, but it took a long time to do so (2 hours). I can't even begin to hope that a migration of 6500 will complete in a reasonable amount of time. It seems I shouldn't be having credential issues after starting a migration so why is this error happening intermittently? Why is the user null?
I will add that prior to starting the smaller migration, I did clear the following:
1)%localappdata%\Microsoft\Team Foundation\3.0\Cache
2)%localappdata%\Microsoft\Team Foundation\4.0\Cache
3)%localappdata%\Microsoft\Team Foundation\5.0\Cache
Related
Due to some reasons deleted the AWS s3 keys and replaced them. Unable to deploy the code in guthub actions due to the below errors.
"Resource is not in the state servicesStable"
In AWS events tab we are getting the below error.
"unable to consistently start tasks successfully".
If required let me know, I will share the task-def.json file.
I have developed the Azure Function App One year back and published successfully and it's running. Now I have made a changes on functionality which is build succeed.
When I am publishing it's throwing error unable to publish.
I went through the path which showing screen shot showing below error.
14-09-2020 10.49.31 PM
System.AggregateException: One or more errors occurred. --->
System.Exception: Publish has encountered an error. We were unable to
determine the cause of the error. Check the output log for more
details. --- End of inner exception stack trace ---
---> (Inner Exception #0) System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the
output log for more details. <---
System.Exception: Publish has encountered an error. We were unable to
determine the cause of the error. Check the output log for more
details.
===================
I am unable to figure out the error here. Any one help on this?
I think you shouldn't stop because of this. And for the error you give us we can not get anything useful from it.
You just need to use another way to deploy. And it will give you the details error if it has any error.(Although I say it is another way, in fact they are essentially the same. VS Studio is actually performing packaging and running commands when you try to publish the azure function.)
Just do the following steps:
1, create the function app on azure.
2, build your function app on local.
3, Go to the compiled folder on local, and zip the content:
4, install the Azure CLI, then run az login.
5, cd to the compiled folder, then run below command:
az webapp deployment source config-zip --resource-group yourresourcegroupnameonazure --name yourfunctionappnameonazure --src xxx.zip
After above steps, everything will be ok. This is the offcial doc:
https://learn.microsoft.com/en-us/azure/app-service/deploy-zip
I've seen similar errors in two cases: locked files and previously deployment executed by DevOps pipelines. I don't know if it applies in your case. In both cases, you have to modify your Azure Functions settings on portal:
case 1 : add MSDEPLOY_RENAME_LOCKED_FILES = 1
case 2 : remove WEBSITE_RUN_FROM_PACKAGE = 1
I'm am getting an error when deploying ADF pipelines. I don't understand how to resolve this error message:
Pipeline Populate SDW_dbo_UserProfiles from SDW_dbo_CTAS_ApptraxDevices is in Failed state. Cannot set active period Start=05/30/2017 00:00:00, End=05/29/2018 23:59:59 for pipeline 'Populate SDW_dbo_UserProfiles from SDW_dbo_CTAS_ApptraxDevices' due to conflicts on Output: SDW_dbo_UserProfiles with Pipeline: Populate SDW_dbo_UserProfiles from SDW_dbo_Manifest, Activity StoredProcedureActivityTemplate, Period: Start=05/30/2017 00:00:00, End=05/30/2018 00:00:00
.
Try changing the active period or using autoResolve option when setting the active period.
I'm am authoring and deploying from within Visual Studio 2015. All of my pipelines have the same values for Start and End.
"start": "2017-05-30T00:00:00Z",
"end": "2018-05-29T23:59:59Z"
How do I resolve this issue?
Visual Studio can be fun sometimes when it comes to validating your JSON because not only does it check everything in your solution it also validates against what you already have deployed in Azure!
I suspect this error will be because there is a pipeline that you have already deployed that now differs from Visual Studio. If you delete the affected pipeline from ADF in Azure manually and then redeploy you should be fine.
Sadly the tooling isn't yet clever enough to understand which values should take presedence and be overwritten at deployment time. So for now it simiply errors because of a mismatch, any mismatch!
You will also encounter similar issues if you remove datasets from your solution. They will still be used for validation at deployment time because the wizard first deploys all new things before trying to delete the old. I've fed this back to Microsoft already as an issue that needs attention for complex solutions with changing schedules.
Hope this helps.
I’m developing a VSTS extension with a build task which should create up to 20,000 work items in a single build. Work items are created using WorkItemTrackingApi/createWorkItem function of vsts-node-api package. In current implementation, extension sends a request to create each work item, VSTS starts to throttle after creating about 100 work items.
Following are the errors logged in the build console.
• (2017-01-08T12:35:13.1385597Z Error: connect ETIMEDOUT 11.11.111:111:111)
• 2017-01-08T12:36:45.0090704Z Error: Failed Request: Internal Server Error(500) - TF246020: Microsoft SQL Server encountered an error while processing the results from one of the Team Foundation Server databases. The error may be caused by insufficient resources on the server. Wait a few minutes and try the operation again. If the problem persists, contact a SQL Server administrator.
2017-01-08T12:36:45.0090704Z ThrottlingMode = Unknown, MildResourceType = None, SignificantResourceType = None
Is there a way to create a bulk of work item with vsts-node-api?
Please advise how to resolve this.
There are the VSTS REST APIs for creating batches of work items, but the vsts-node-api does not wrap them up yet as of January 2017.
You may want to leverage directly the work item batch REST APIs of VSTS with your preferred JavaScript based library.
Please refer Create Large Amount of Work Items in TFS Using Javascript REST API
You can use below for authentication,
httpntlm.patch(options, function(err,res) {
console.log("patch complete");
console.log(res.body);
})
My migration fails on the user mapping task with the following error :
OpsHub-014371: Could not instantiate metadata implementation for For User List | TFS Source 1412109029732 ALM TFS 1412109029738, due to (301)Moved Permanently
I am running on v1.0.1.006.
Thanks for help
If the machine that you are using the utility on behind a proxy then this issue will come, new version will be available on first week of November.