Coder Social home page Coder Social logo

azure-devops-node-api's Introduction

Build Status

Azure DevOps Client for Node.js

Integrate with Azure DevOps from your Node.js apps.

Install the library

npm install azure-devops-node-api --save

News

vso-node-api has been renamed and released as azure-devops-node-api

Get started

Samples

See samples for complete coding examples

Install the library

npm install azure-devops-node-api --save

Intellisense

Create a connection

import * as azdev from "azure-devops-node-api";

// your collection url
let orgUrl = "https://dev.azure.com/yourorgname";

let token: string = process.env.AZURE_PERSONAL_ACCESS_TOKEN;

let authHandler = azdev.getPersonalAccessTokenHandler(token); 
let connection = new azdev.WebApi(orgUrl, authHandler);    

Please note that some API's (e.g. ProfileApi) can't be hit at the org level, and has to be hit at the deployment level, so url should be structured like https://vssps.dev.azure.com/{yourorgname}

Get an instance of a client

import * as ba from "azure-devops-node-api/BuildApi";

let build: ba.IBuildApi = await connection.getBuildApi();

Available clients

These clients are available:

  • Advanced Security Alert
  • Advanced Security Management
  • Build
  • Core
  • Dashboard
  • ExtensionManagement
  • FeatureManagement
  • FileContainer
  • Git
  • Locations
  • Notification
  • Policy
  • Profile
  • ProjectAnalysis
  • Release
  • SecurityRoles
  • TaskAgent
  • Task
  • Test
  • TestPlan
  • TestResults
  • Tfvc
  • Wiki
  • Work
  • WorkItemTracking
  • WorkItemTrackingProcess
  • WorkItemTrackingProcessDefinitions

Use the client

Coding is easy using linear coding with async/await in TypeScript

import * as bi from "azure-devops-node-api/interfaces/BuildInterfaces";

async function run() {
    let project: string = "myProject";
    let defs: bi.DefinitionReference[] = await build.getDefinitions(project);

    defs.forEach((defRef: bi.DefinitionReference) => {
        console.log(`${defRef.name} (${defRef.id})`);
    });    
}

run();

APIs

To see what APIs are available, see the appropriate client interface. For example, GitApi.ts

More detailed information for the endpoints of each API can be found at https://docs.microsoft.com/en-us/rest/api/vsts/?view=vsts-rest-4.1

Running Samples

Pre-reqs: Node >= 4.4.7 LTS and typescript (tsc) >= 1.8

Run npm install first

Set environment variables using set or export:

API_URL=https://dev.azure.com/yourorgname

// use your token
API_TOKEN=cbdeb34vzyuk5l4gxc4qfczn3lko3avfkfqyb47etahq6axpcqha  

API_PROJECT=myProject  

Run samples:

$ npm run samples

Run a specific sample:

$ npm run samples -- projectAnalysis

API and TFS Mapping

Below you'll find a quick mapping of azure-devops-node-api versions and their corresponding TFS releases. All API versions will work on the TFS version mentioned as well as later TFS versions.

TFS Version Node API VERSION
Azure DevOps Server vNext 8.0.0
Azure DevOps Server 2019 7.0.0
TFS 2018 Update 2 6.6.2
TFS 2017 Update 2 6.2.8-preview
TFS 2017 Update 1 5.1.2
TFS 2017 RTW 5.0.0
TFS 2015 Update 2 0.7.0

Contributing

To contribute to this repository, see the contribution guide

Issues

Feel free to file an issue in this repo.

Do you think there might be a security issue? Have you been phished or identified a security vulnerability? Please don't report it here - let us know by sending an email to [email protected].

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

azure-devops-node-api's People

Contributors

ankitgo avatar annich-ms avatar bryanmacfarlane avatar daniilshmelev avatar denisrumyantsev avatar dmitriibobreshev avatar eps1lon avatar hashtagchris avatar icnocop avatar implausible avatar kimsey0 avatar lszomoru avatar max-zaytsev avatar mjroghelia avatar nuthanmunaiah avatar pabrams avatar peterblazejewicz avatar rarkins avatar saikrishnav avatar scottdallamura avatar scottdallamura2 avatar seanfisher avatar starkmsu avatar stephenmichaelf avatar t-hugs avatar tedchamb avatar tingluohuang avatar tingluohuang-test avatar triptijain2112 avatar willsmythe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

azure-devops-node-api's Issues

Error when querying the release API

I have tried to use the vsts-node-api to create a new release definition. However I always get the same response:

Error: Failed to find api location for area: Release id: d8f96f24-8ea7-4cb6-baab-2df8fc515665 statusCode undefined.

The api endpoint I'm targeting is createReleaseDefinition using the promise interface.

I've succesfully used the BuildApi and was able to create a build definition using this API.

installExtensionByName doesn't work in [email protected]

Error: No api-version was supplied for the "POST" request. The version must be supplied either as part of the Accept header (e.g. "application/json; api-version=1.0") or as a query parameter (e.g. "?api-version=1.0").
    at RestClient.<anonymous> (/Users/youngp/ci/vsts-test/node_modules/typed-rest-client/RestClient.js:173:28)
    at next (native)
    at fulfilled (/Users/youngp/ci/vsts-test/node_modules/typed-rest-client/RestClient.js:6:58)
    at process._tickCallback (internal/process/next_tick.js:109:7)

looks like extension install Rest API doesn't have 3.2-preview.1 version which [email protected] uses.
it is working with 3.0-preview.1 api-version in [email protected]

Work item creation issue in TFS 2015.2

I'm getting following error when creating bug item in TFS 2015.2 (On permise) via vso-node-api package, however the same code is working perfectly in my VSTS (online) subscription.

[Error: Failed Request: Bad Request(400) - TF401349: An unexpected error has occurred, please verify your request and try again.] statusCode: 400

I'm using the WorkItemTrackingApi/createWorkItem function in vso-node-api library to create the work item.

I have raised following stackoveflaw thread with further info,

http://stackoverflow.com/questions/40147345/work-item-creation-issue-in-tfs-2015-2-with-vsts-node-api

vso-node-api 5.0.0: node cannot find module

package.json declares WebApi.js in the root of the package, but it's not there. The package seems to contain a copy of the source, rather than the javascript in a npm-consumable structure.

Cannot find name 'Promise'

I'm getting error "Cannot find name 'Promise'"error for all the promises in the module. How to resolve this?

Passing dates to the vsts api as Date objects breaks

The samples/build.ts file has a commented out example of passing a Date object to the vsts api. Uncommenting that code and passing a Date object causes the api to return a 400 error.

Sample Code:

        let builds: bi.Build[] = await vstsBuild.getBuilds(
                        project, 
                        null,                       // definitions: number[] 
                        null,                       // queues: number[]
                        null,                       // buildNumber
                        new Date(2016, 1, 1),       // minFinishTime
                        null,                       // maxFinishTime
                        null,                       // requestedFor: string
                        bi.BuildReason.All,         // reason
                        bi.BuildStatus.Completed,
                        bi.BuildResult.Succeeded,
                        null,                       // tagFilters: string[]
                        null,                        // properties: string[]
                        //bi.DefinitionType.Build,
                        10                          // top: number
                        );

Error Returned:

Error: Error: Failed request: (400) 
    at RestClient.<anonymous> (c:\source\vsts-node-api\samples\node_modules\typed-rest-client\RestClient.js:173:28)
    at Generator.next (<anonymous>)
    at fulfilled (c:\source\vsts-node-api\samples\node_modules\typed-rest-client\RestClient.js:6:58)
    at process._tickCallback (internal/process/next_tick.js:109:7)

If I change the compiled BuildApi.ts file to pass the minFinishTime as a string using .toISOString() it works.

Original:

let queryValues: any = {
                ...
                minFinishTime: minFinishTime,
    ...

Updated:

let queryValues: any = {
                ...
                minFinishTime: minFinishTime ? minFinishTime.toISOString() : null,
 ...

The bug is most likely in the lower level typed-rest-client package but I'm still trying to get better visibility of the actual network calls being made to see how it's breaking.

If someone has an idea of where this can be fixed I'd be happy to see if I can fix it and submit a PR but the actual place where this Date object is being messed up still eludes me.

Always getting wrong version of api when using the build api

I am trying to access build info from a TFS 2017 server. When I call the getBuilds functions the following:

this.vsoClient.getVersioningData("3.0-preview.3", "build", "0cd358e1-9217-4d94-8269-1c1ee6f93dcf", routeValues, queryValues)

always return 3.0-preview.3, and that doesn't return any build. If I change the apiVersion to the hardcoded 2.0 value ( the latest build api version), I get the builds I was expecting.

I haven't touch this code for a while, and I am pretty sure it used to work with TFS 2015.2 server.

Tests or Examples - Documentation

Are there any examples or tests available for this project?

It's very straightforward so far, but getPullRequestsByProject appears to differ from the API. VsoClient.prototype.getRequestUrl is appending a querystring parameter searchCriteria={value} instead of status=active when passing { status='active' } into getPullRequetsByProject as the searchCriteria.

For example:

var gitClient = vsoWebApiClient.getGitApi();
gitClient.getPullRequestsByProject("MyProj", { status: 'active' }, null, null, null, handleSomething)

produces querystring MyProj/_apis/git/pullRequests?searchCriteria=[object Object] instead of RadarBot/_apis/git/pullRequests?status=active.

Release management should not require specific url

I encounted the same problem mentioned in #85. It seems very odd that I need to specify different urls for different areas of the api. For example, to access the "build" apis, I need to supply a url like this:

Access to build apis:
https://{mydomain}.visualstudio.com

However, to access RELEASE apis, I need to supply the following url:
https://{mydomain}.vsrm.visualstudio.com

Shouldn't the SDK handle this complexity for the user?

Include a more specific user agent string in HTTP calls

Need to include a more descriptive user agent string in calls from this client. This will help us better understand how/where people are using the library.

The user-agent string should always include information about the client library, but also information about the tool/app/service using the library (optionally). This might be specified like this:

var requestSettings: IWebApiRequestSettings = {
 
    productName = "MyTool",
    productVersion = "12.322"
   
};

var webApi  = new WebApi(connectionUrl, creds, requestSettings);

if product name is specified ...

   {ToolName}/{ToolVersion} (vsts-node-api {VstsNodeApiVersion}; {osname} {osversion})

Otherwise ...

   vsts-node-api/{VstsNodeApiVersion} ({osname} {osversion})

Examples:

  • vsts-node-api/6.1.1-preivew (Windows 10.01232)
  • tfx-cli/0.3.49 (vsts-node-api 14.1223.2; Windows 10.1232)

Should WIT `createAttachment` encode filenames?

Hi,
Within the WIT client, createAttachment directly passes through the filename when creating an attachment. We have filenames that may contain characters that are not valid URL components, such as "a filename with a commit hash # xyz.xlsx".

We can use encodeuricomponent to encode the filename before passing it to the client, but I wanted to open an issue to understand whether the onus for encoding parameters such as this should fall on the client library or not.

Should the underlying library's getVersioningData method look to URI encode query values?

To reproduce:
With the client library, upload a file with a filename such as "magical#file.txt", without uri encoding the filename.

Expected: the file appears the same as if a user of VSTS uploaded a file with the same name, preserving the filename in tact. The client library takes the input value, prepares it to safely send to the REST API. The filename is preserved.

Actual:
The file receives the name "magical", truncating the rest of the filename, including the file extension.

Getting test results using VSTS rest API

I am using Nodejs for consuming rest API of VSTS
Getting Builds and work items is working fine.

But I am confused about the endpoint which will return me the test results of particular build.
Kindly help me with this.

Issue in getClassificationNode function

I'm getting following error when using getClassificationNode() function

[Error: Failed Request: Bad Request(400) - https://xxxxx.visualstudio.com/MyFirstProject/_apis/wit/classificationNodes/MyFirstProjectArea1Test] statusCode: 400

Following is the code sample,
var areaPath = "MyFirstProject\Area1Test";
this.vstsWI.getClassificationNode(this.projName, wi.TreeStructureGroup.Areas, areaPath).then((nodex: wi.WorkItemClassificationNode) => {
console.log(nodex);
}).catch((e) => {
console.error(e);
});

VSTS work item creation throttling issue

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 throttling after creating about 100 work items.

Following are the two 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

Package installed from npm still has Q in d.ts file

Hi,
I am now writing an tfs web application. When I compile my application, tsc complains:
node_modules/vso-node-api/FileContainerApi.d.ts(1,20): error TS2307: Cannot find module 'q'. node_modules/vso-node-api/VsoClient.d.ts(1,20): error TS2307: Cannot find module 'q'.

In FileContainerApi.d.ts:

import Q = require('q');
import VsoBaseInterfaces = require('./interfaces/common/VsoBaseInterfaces');
import FileContainerApiBase = require("./FileContainerApiBase");
...

If I remove the import and replace Q.Promise with Promise, compilation is good.

Here are my question:
Is it safe for me to remove them?
Do I need any special setting for tsconfig? Current I have "target": "es6".

Thanks!

createWorkItem fails with "Failed Request: Internal Server Error(500) - TF400898: An Internal Error Occurred

I am trying to create a new work item but it fails with an error 500. I believe that this is due to the fact that the team project, and the work item type is not added to routeValues when we are retrieving the location of the REST API. I was able to get it working with the following version of the method. I am more than happy to submit a pull request with these changes.

    WorkItemTrackingApi.prototype.createWorkItem = function (customHeaders, project, document, type, validateOnly, bypassRules, onResult) {
        var _this = this;
        var routeValues = {
            project: project,
            type: type,
        };
        var queryValues = {
            validateOnly: validateOnly,
            bypassRules: bypassRules
        };
        customHeaders = customHeaders || {};
        customHeaders["Content-Type"] = "application/json-patch+json";
        this.vsoClient.getVersioningData("2.2-preview.2", "wit", "62d3d110-0047-428c-ad3c-4fe872c91c74", routeValues, queryValues)
            .then(function (versioningData) {
            var url = versioningData.requestUrl;
            var apiVersion = versioningData.apiVersion;
            var serializationData = { requestTypeMetadata: VSSInterfaces.TypeInfo.JsonPatchDocument, responseTypeMetadata: WorkItemTrackingInterfaces.TypeInfo.WorkItem, responseIsCollection: false };
            _this.restClient.create(url, apiVersion, document, customHeaders, serializationData, onResult);
        })
            .fail(function (error) {
            onResult(error, error.statusCode, null);
        });
    };

Release API doesn't work against vsts but does against on prem

Version: 5.1.2

Repro code:

    let token: string = tl.getEndpointAuthorizationParameter("SystemVssConnection", "AccessToken", false);
    let collectionUrl: string = tl.getEndpointUrl("SystemVssConnection", false);
    let authHandler = vsts.getPersonalAccessTokenHandler(token);
    let connect = new vsts.WebApi(collectionUrl, authHandler);
    let releaseApi: ra.IReleaseApi = connect.getReleaseApi();

    await releaseApi.getReleases(this.teamProject);

I get the error: Error: Failed to find api location for area: Release id: a166fde7-27ad-408e-ba75-703c2cc9d500

other apis work fine. What am I doing wrong?

HTTPS support through proxy

When I set the HTTP_PROXY to an HTTP URL (http://:8888) and a request is made to an HTTPS URL (https://.visualstudio.com/DefaultCollection), the traffic is routed through the proxy but it doesn't properly initiate the connection with a CONNECT request. This causes all requests to fail.

It looks like this is a deficiency in your HttpClient implementation.

Tests failing with recent commit

Trying to debug #123, I've been trying the samples and then tests but no luck. npm test fails with:

> [email protected] test /Users/alain/Documents/workspace/vsts-node-api
> node make.js test

> tsc --outDir /Users/alain/Documents/workspace/vsts-node-api/_build
typings/globals/underscore/index.d.ts(3760,34): error TS1122: A tuple type element list cannot be empty.
/Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/src/common.js:417
      if (config.fatal) throw e;
                        ^

Error: exec: internal error
    at Object.error (/Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/src/common.js:128:27)
    at _exec (/Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/src/exec.js:292:12)
    at /Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/src/common.js:350:23
    at run (/Users/alain/Documents/workspace/vsts-node-api/make.js:14:14)
    at Function.target.build (/Users/alain/Documents/workspace/vsts-node-api/make.js:29:5)
    at Object.global.target.(anonymous function) [as build] (/Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/make.js:36:40)
    at Function.target.test (/Users/alain/Documents/workspace/vsts-node-api/make.js:41:12)
    at Object.global.target.(anonymous function) [as test] (/Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/make.js:36:40)
    at /Users/alain/Documents/workspace/vsts-node-api/node_modules/shelljs/make.js:48:27
    at Array.forEach (<anonymous>)
npm ERR! Test failed.  See above for more details.

Seems like the break came with #64 as d60e4b7 works fine.

Debugging API failures is difficult because response body is discarded

In RestClient if the call to httpClient.send fails then the response body is discarded and is unavailable to the caller which significantly hampers debugging.

For example, if you use the updateWorkItemTemplate API to update a work item and one of the field values is invalid the err object you get back from RestClient only contains a status code and no additional information. The only way to determine the actual failure is to set a breakpoint in _sendJson and examine the value of the "contents" variable (which isn't practical when debugging a production issue).

If the contents were passed to the onResult callback or attached to the err object that would help significantly.

Generated API interfaces should include /* doc comments

For TypeScript developers that do something like this:

let vstsBuild: ba.IBuildApi = connection.getBuildApi();

Intelli-sense should work, but doesn't because the generated interfaces are missing doc comments. These comments are included on the classes that implement the API interfaces.

Version without typescript

The project I am working on does not use typescript. Is there a version of this code that is not in typescript?

Question: How to access interfaces in ReleaseInterfaces.d.ts (npm)

Occasionally I need to define a variable to hold a vsts object, but I'm struggling with how to import the correct module/types. Can I import types from ReleaseInterfaces.d.ts? It seems like typescript only sees "top-level" types (ones that are exported from Index.d.ts). Is there another way to reference these types? If not, a nice update might be to export them from Index.d.ts?

Support for crossing VSTS service boundaries via the Location Service

I'd like to write API clients for Feed and NuGet APIs (and probably contribute them to this repository eventually). However, these APIs live in the Packaging service and we often only have the TFS service URL (e.g. in the build agent). We can do hacky things like assume that if the url ends in .visualstudio.com, the packaging service is at .pkgs.visualstudio.com, but VSTS already has a mechanism for determining the correct URL for an API area on another service: the Location Service.

In the C# client, the VssConnection class handles all that magic. When you ask it for a NuGetHttpClient, you get back one initialized with the Packaging service URL, no matter which service's URL you originally gave to VssConnection.

ServiceHooks - api location error

I'm successfully accessing the Build API on VSTS. Now trying to use the ServiceHooks one I'm getting the following error:

 Promise {
    <rejected> Error: Failed to find api location for area: hookssvc id: 4431ee3f-13e3-4b41-b62e-47289e90d3dc
      at beginGetLocation.then (/Users/alain/Documents/workspace/vsts-octobot/node_modules/vso-node-api/VsoClient.js:84:27)
      at <anonymous>
      at process._tickDomainCallback (internal/process/next_tick.js:228:7) }
  --
  Error: Failed to find api location for area: hookssvc id: 4431ee3f-13e3-4b41-b62e-47289e90d3dc
      at beginGetLocation.then (/Users/alain/Documents/workspace/vsts-octobot/node_modules/vso-node-api/VsoClient.js:84:27)
      at <anonymous>
      at process._tickDomainCallback (internal/process/next_tick.js:228:7)

Here is the code I'm using:

let authHandler = vsts.getPersonalAccessTokenHandler(vstsToken)
let webApi = new vsts.WebApi(collectionUrl, authHandler)

let vstsBuildApi = webApi.getBuildApi()
vstsBuildApi.getDefinition(buildDefinitionId, project).then((def) => {
    // That works
    console.log(def)
})

let vstsServiceHookApi = webApi.getServiceHooksApi()
vstsServiceHookApi.listSubscriptions()

I did successfully used the REST API directly though (using Postman), so I'm sure my token is valid. Any idea anyone?

gulp fails due missing tsconfig.json

I am trying to contribute to this project and the gulp command fails

Error: ENOENT: no such file or directory, open 'E:\Github\vso-node-api\tsconfig.json'

It is missing the tsconfig.json file.

Thanks

error TS2503: Build: cannot find namespace 'NodeJS'.

Using the VS2015 VSTS extension project template from here:
https://visualstudiogallery.msdn.microsoft.com/a00f6cfc-4dbb-4b9a-a1b8-4d24bf46770b

plus vso-node-api (because I need impersonation as service account in my extension)

  1. npm i vso-node-api in my project folder
  2. typings i dt~node --global --save

vso-node-api seems not to know NodeJS typedef:

<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(8,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(32,113): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(35,64): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(39,89): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(83,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(299,113): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(323,64): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\BuildApi.d.ts(351,89): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\FileContainerApi.d.ts(6,31): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\FileContainerApi.d.ts(10,31): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\FileContainerApi.d.ts(11,75): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(11,159): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(12,128): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(13,141): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(17,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(28,136): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(29,183): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(87,159): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(95,128): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(103,141): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(122,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(184,136): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GalleryApi.d.ts(194,183): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(7,122): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(8,104): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(9,118): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(23,306): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(25,303): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(26,302): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(77,139): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(100,122): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(109,104): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(119,118): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(247,306): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(275,303): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(289,302): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\GitApi.d.ts(712,139): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\HttpClient.d.ts(1,23): error TS2307: Build:Cannot find module 'http'.
<projectpath>\node_modules\vso-node-api\HttpClient.d.ts(11,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\HttpClient.d.ts(12,115): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(15,100): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(29,116): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(30,58): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(31,130): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(39,105): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(44,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(121,100): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(207,116): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(212,58): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(220,130): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(269,105): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\ReleaseApi.d.ts(314,93): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\RestClient.d.ts(16,80): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskAgentApi.d.ts(5,84): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskAgentApi.d.ts(23,114): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskAgentApi.d.ts(45,84): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskAgentApiBase.d.ts(55,116): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskAgentApiBase.d.ts(338,116): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(7,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(9,159): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(12,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(43,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(63,159): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TaskApi.d.ts(89,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(9,125): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(11,121): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(13,96): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(15,92): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(126,125): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(143,121): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(157,96): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TestApi.d.ts(172,92): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(15,102): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(17,239): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(19,236): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(20,235): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(120,102): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(144,239): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(166,236): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\TfvcApi.d.ts(178,235): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(7,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(8,66): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(9,62): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(70,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(77,66): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\WorkItemTrackingApi.d.ts(84,62): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\interfaces\common\VsoBaseInterfaces.d.ts(58,57): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\interfaces\common\VsoBaseInterfaces.d.ts(59,115): error TS2503: Build:Cannot find namespace 'NodeJS'.
<projectpath>\node_modules\vso-node-api\interfaces\common\VsoBaseInterfaces.d.ts(71,88): error TS2503: Build:Cannot find namespace 'NodeJS'.

HttpClient is assuming json

HttpClient should not assume the content type of the body by forcing a JSON.stringify

if (objs) {
            reqData = JSON.stringify(objs, null, 2);
            options.headers["Content-Length"] = Buffer.byteLength(reqData, 'utf8');
        }

Let the user serialize the body themselves, or provide an option to not stringify the content. Unable to use this to perform my oauth2 request due to my x-www-form-urlencoded content being corrupted by the json stringify.

401 when using api in on-prem TFS 2017

I am attempting to create a Build task in node, that leverages this api. I have looked through the samples, and I am attempting to use much of the code in the common.ts for getting the WebApi object.
My code looks like this:



export async function getWebApi(pwd:string): Promise<vm.WebApi> {
    return new Promise<vm.WebApi>(async (resolve, reject) => {
        try {
            console.log("in the common getter");
            let serverUrl = 'https://mylocalserver/tfs/mycollection';
            let token = ' my PAT on the server, that has full access ';
            let authHandler = vm.getPersonalAccessTokenHandler(token);      
            let option = {
            ignoreSslError: true
             };
            
            let vsts: vm.WebApi = new vm.WebApi(serverUrl, authHandler,options);
            console.log("got web api?");
            let connData: lim.ConnectionData = await vsts.connect();
            console.log('Hello ' + connData.authenticatedUser.providerDisplayName);
            resolve(vsts);
        }
        catch (err) {
            console.log("error in get api " + err.message);
            reject(err);
        }
    });

The code ends up erroring with "Invalid Resource".. not the most helpful message.. Debugging locally through VSCode, I found that the status coming back to the REST call was a 401-Unauthorized. I put some debug messages in the javascript of rest client to verifiy that the same error was coming when running on the server, and indeed that's the same result. I tried switching out the PAT Handler for the Ntlm Handler, but the same results.

Not sure why the 401? If I hit the URI that the Rest call is making in my browser window, it comes back with the Json successfully.

any help would be super appreciated at this point.

Switch to common version scheme

The .NET client libraries, VSS web extension SDK, etc follow a MajorVersion.Milestone.Patch-preview (e.g. 15.113.0-preview) versioning schema that aligns with on-premises releases and our overall API versioning.

  • 15.112.0 // API version 3.1, 2017 Update 1, M112 deployment
  • 15.104.0-preview // API version 3.0-preview, 2017 pre-release, M104 deployment
  • 14.102.0 // API version 2.3, 2015 Update 3, M102 deployment

The Node client should follow the same versioning scheme so consumers know how/where the package can be used (in general). Developers shouldn't have to try and figure out how "5.1" maps to our products/API versions.

At the same time, it would be good for the NPM package name to match the library name (vsts-node-api).

installExtensionByName returns error "invalid resource"

The same code that works correctly with vso-node-api v5.1.2 doesn't work in v6.0.0.

The API is IExtensionManagementApi.installExtensionByName and the extension is publisherName: ms-devlabs, extensionName: FolderManagement. I tested the other extension but it also received the same "invalid resource" error.

error: Failed to install extention error : { Error: invalid resource
    at RestCallbackClient._sendJson (vso-node-api/RestClient.js:120:19)
    at RestCallbackClient.create (vso-node-api/RestClient.js:72:14)
    at vso-node-api/ExtensionManagementApi.js:582:30
    at _fulfilled (q/q.js:854:54)
    at self.promiseDispatch.done (q/q.js:883:30)
    at Promise.promise.promiseDispatch (q/q.js:816:13)
    at q/q.js:624:44
    at runSingle (q/q.js:137:13)
    at flush (q/q.js:125:13)
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9) statusCode: undefined }

Make interface types nullable/optional

Some interfaces, like GitPullRequest, contain a lot of members that are not mandatory according to the API docs.

For example, when creating a pull request, we need a GitPullRequest object. This has a lot of mandatory members but the API has only 4 or 5 parameters.

Is it possible to make them nullable?

401 while getting build definitions or builds

For one of the TFS server, I am getting 401 during getting builds
But for other TFS its working. I am having same level of access for both servers.
One server is running on https(401) and other is on http(working)
Both TFS are having different domains
What could be the possible reason for that?

Request option typedefs should be marked optional

When specifying options for a request, the tyepdefs like GitInterfaces.GitQueryCommitsCriteria require every single parameter to be filled out. Instead these should all be marked as optional.

For example, if I wanted to get the first git commit on a certain day this is all I need to specify:

const commitQueryOptions: any = {
    $top: 1,
    fromDate: "2017-01-03T00:00:00.000Z",
    toDate:   "2017-01-03T23:59:59.999Z",
    itemVersion: {
        versionOptions: GitInterfaces.GitVersionOptions.PreviousChange,
        versionType: GitInterfaces.GitVersionType.Commit
    }
};

vso.getGitApi().getCommits(repo.id, commitQueryOptions).then(() => {
  //do stuff...
})

At first I tried to provide empty strings and null for the options I didn't care about, but that wouldn't compile since it didn't line with twith the typedefs. TFS also gave me back 400 errors saying that certain data was required to be set to null

However, the above code works for now but I'm not a fan of being forced to use the any type (weak typing) when the real typedefs exist. It just seems silly to require the dev to fill out 20+ options that they don't care about, especially since it actually works just fine when you don't.

Use this lib with TFS on-premise

I can't find how to implement login in my Electron angularjs application with username, password and URL for the server. I want to connect to both services: TFS on-premise and VSTS. How can i achieve it with this lib? or i have to use some other thing?
I know i can use basic authentication, but i guess I can't get user profile name using it

Uses blacklisted node module (gulp-tsc)

You are using gulp-tsc, which is actually blacklisted by the gulp folks

kant2002/gulp-tsc#8

I tried to build this repo but it gloms onto the globally installed Typescript that comes with VS, which is sadly 1.0 on my machine.

You should use gulp-typescript instead as it uses the official MS (typescript based) typescript compiler.

Sending a PR.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.