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);
})
Related
I am facing an issue while configuring Azure Key vault in Asp.net core Web API project .
Below is the code snippet as well as error for reference and I tried to find the root cause but no luck.
Error while Run() method execution.
Exception details
Please help me out in solving this issue .Thanks in advance.
It can be issue from .net end mostly ,in .NET Core 3.0.100 or 3.1. This seems to occur when running under the debugger in Visual Studio mostly and when long parallel calls are made and retrypolicy may help stop this from giving exception for sometime and tries again.
So Please try to Upgrade/Update the .NET Project SDK if any updates
available in Visual Studio.
Try running with command line
Also in the message of error you can see retry faild after 4 tries..
You can check ReloadInterval Property which is used in 3.0 and 3.1
builder.AddAzureKeyVault(
new Uri(Configuration["KeyVault:URI"]),
new DefaultAzureCredential(
new DefaultAzureCredentialOptions
{
ExcludeSharedTokenCacheCredential = true,
VisualStudioTenantId = Configuration["AzureAd:TenantId"]
}),
new AzureKeyVaultConfigurationOptions()
{
ReloadInterval = TimeSpan.FromMinutes(15)
}
);
You could try catching this exception and implementing a retry mechanism for your code if this exception is thrown so that it could try with retry time and delay required for next attempt.
Azure Key Vault throttling guidance | Microsoft Docs
SecretClientOptions options = new SecretClientOptions()
{
Retry =
{
Delay= TimeSpan.FromSeconds(2),
MaxDelay = TimeSpan.FromSeconds(16),
MaxRetries = 5,
Mode = RetryMode.Exponential
}
};
var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
//Retrieve Secret
secret = client.GetSecret(secretName);
Also see GitHub discussion
If still issue remains, it may be calling several times due to
network issue also.So please check the network , firewall and if there is any DNS issue for that endpoint.
Check URI if endpoint is incorrect or Managed Identity does not have
Data owner or Reader role.Please make sure that you have proper
permissions to access azure keyvault and give proper access
policies atleast get , list and create if needed .
Make sure to have one of the roles(RBAC) provided here to access the
keyvault .
References:
asp.net core - How to configure Azure KeyVault refresh interval
with the Azure.Security.KeyVault libraries - Stack Overflow
azure sdk .net issues(github)
All, when running a build pipeline using Azure Devops with ARM template, the process is consistently failing when trying to deploy a dataset or a reference to a dataset with this error:
ARM Template deployment: Resource Group scope (AzureResourceManagerTemplateDeployment)
BadRequest: The document creation or update failed because of invalid reference 'dataset_1'.
I've tried renaming the dataset and also recreating it to see if that would help.
I then deleted the dataset_1.json file from the repo and still get the same message so it's some reference to this dataset and not the dataset itself I think. I've looked through all the other files for references to this but they all look fine.
Any ideas on how to troubleshoot this?
thanks
try this
Looks like you have created 'myTestLinkedService' linked service, tested connection but haven't published it yet and trying to reference that linked service in the new dataset that you are trying to create using Powershell.
In order to reference any data factory entity from Powershell, please make sure those entities are published first. Please try publishing the linked service first from the portal and then try to run your Powershell script to create the new dataset/actvitiy.
I think I found the issue. When I went into the detailed logs I found that in addition to this error there was an error message about an invalid SQL connection string, so I though it may be related since the dataset in question uses Azure SQL database linked service.
I adjusted the connection string and this seems to have solved the issue.
I'm trying to connect the SPGo plugin in Visual Studio Code to a Sharepoint Online site. There are lots of guides for this, for instance this one: https://medium.com/niftit-sharepoint-blog/saying-goodbye-to-sharepoint-designer-ac939a0b79ba
In short, I'm doing it like this:
Open VS Code
Open a local, empty folder)
SPGO: Configure workspace (follow guide, ending up with spgo.json
looking like the one I pasted)
SPGO: Populate local workspace (asking me for credentials and I plot
it in O365 style (email and password).
Statusbar says "Populating workspace"
After about 10 seconds I get the pasted error in the output window (spgo)
I'm using newest versions:
Visual Studio Code 1.37.1
SPGo 1.4.3
I have tried various sites in my tenant and I know they are up. I am Site Collection Administrator for the sites. I know the credentials are correct, of course. the remoteFolders and publishingScope doesn't affect anything, when changed. I assume authenticationType should be "Digest".
SPGo.json:
{
"sourceDirectory": "src",
"sharePointSiteUrl": "https://domain.sharepoint.com/sites/SiteName",
"publishingScope": "Major",
"authenticationType": "Digest",
"remoteFolders": [
"/SitePages/"
]
}
I don't get any files in the local folder, instead I get an error in the output:
================================ ERROR ================================
<s:Fault>
<s:Code>
<s:Value>s:Receiver</s:Value>
<s:Subcode>
<s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-US">The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.</s:Text>
</s:Reason>
</s:Fault>
Error Detail:
----------------------
{}
===============================================================================
Sorry I missed this post for so long. First- thanks for the detailed write-up. This is the first time I've seen this specific issue with SPGo, so I do not know for sure what is the root cause.
Couple questions:
Are you using ADFS Authentication with your Office 365/SharePoint Online instance?
Are you able to use Addin-Only Authentication on this SP Site?
SPGo should be able to automatically work with ADFS in SharePoint Online but, as a fall-back, you could use Addin-Only Authentication. In this scenario you would create a ClientId and ClientSecret pair for the SharePoint Site Collection you are accessing and authenticate using those credentials. The ClientId would act as your UserName, and the ClientSecret would be your password.
Under the covers, I am using the node-sp-auth package for user authentication. Sergei (s-KaiNet on Github) has a great write-up on how to enable Addin-Only Authentication in SharePoint Online on his site, which you can find here.
Thanks for using SPGo!
I recently setup Proget to try its nuget and chocolatey servers. Now when I try to publish packages to nuget feed through a teamcity build, I keep on getting error "proget Failed to process request. 'There was an error processing the request: Invalid API key.'.". I've made 100% sure that the name and password are working fine and specified API key as per Proget doco (i.e. username:password ) . THat feed already has one package which I published on the day I installed Proget for trying out. What could have gone wrong?
I found a work around.
[1] I confirmed that my username:password combination is correct.
[2] Then I renamed that original feed to feed_old (or whatever you
want or even delete it if it doesn't have anything important in it) I
had created for trying out and which wasn't allowing publishing
through teamcity and giving the error message as per the question's
message.
[3] Created new feed with the name I wanted.
[4] Confirmed that the username I was using in API key had necessary
privileges to publish to this new feed I just created.
[5] Then tested the publishing to this feed through teamcity and
VOILA!! it worked.
I don't know why this happened in the first place though. It would be good to find out and be able to fix underlying reason rather than using the above mentioned workaround.
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.