Skip to content
This repository has been archived by the owner on Jan 17, 2024. It is now read-only.

How to use a connected service from a custom Azure Devops extension index.ts? #135

Open
patricknolan opened this issue Jun 3, 2019 · 2 comments

Comments

@patricknolan
Copy link

I've written a custom extension for Azure Devops which contains a custom Connected Service and Build task. I can use the Connected Service when configuring the task via the pipeline visual designer to select a service and then use that service to populate a picklist with data from my API.

However, how do I use the selected service when the task is executed. I need to access the service from the index.ts. The service tells me the endpoint and the API Key.

In the index.ts I can access the Guid of the service using something like the following code but can I use the Guid to get the service or it's details?

import tl = require('azure-pipelines-task-lib/task');
async function run() {
try {
const serviceString: string = tl.getInput('TestService', true);
if (serviceString == 'bad') {
tl.setResult(tl.TaskResult.Failed, 'Bad input was given');
return;
} ...

I've done lots of searching and reading (including the following articles) but haven't been able to find any examples.

https://docs.microsoft.com/en-us/azure/devops/extend/develop/add-build-task?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/extend/develop/service-endpoints?view=azure-devops

@patricknolan
Copy link
Author

Anyone know?

@JoshuaTheMiller
Copy link

Fancy finding you here as well, @patricknolan

It would be good to add this as an example if one does not exist quite yet, but to use a connected service, you can do the following (copied from my own SO answer in case the internet breaks):


The trick is to use some more functions from azure-pipelines-task-lib/task (in your case, tl):

If your custom Connected Service adds an authentication scheme of type ms.vss-endpoint.endpoint-auth-scheme-token, then the id of the token input would be apitoken, and the code you would need to add would look something like the following:

const endpoint = tl.getEndpointUrl(serviceString, true);
// The second parameter here is the name of the associated input 
// value(s) of the specific authenticationSchemes type (more on that later).
const token = tl.getEndpointAuthorizationParameter(serviceString, "apitoken", false)

How do I know this? Experimentation.

Other Authentication Types

My current experience echoes that of others' from the past: Azure DevOps does not play nicely with fully custom Connected Services. It does ship with a few that cover most bases. Depending on which one(s) you use, the value you pass for the second parameter of tl.getEndpointAuthorizationParameter changes:

ms.vss-endpoint.endpoint-auth-scheme-token

Ships with one standard input:

  1. apitoken

ms.vss-endpoint.endpoint-auth-scheme-basic

Ships with two inputs:

  1. username
  2. password

Example Plus Suggestion

Suggestion first: to make your code clearer, rename your serviceString variable to connectedServiceId (or some variation to be clear that is represents the ID of your connected service).

import tl = require('azure-pipelines-task-lib/task');

async function run() {
    try {
        const connectedServiceId = tl.getInput('TestService', true);

        if (connectedServiceId == 'bad' || connectedServiceId == undefined) {
            tl.setResult(tl.TaskResult.Failed, 'Bad input was given');
            return;
        }

        const endpoint = tl.getEndpointUrl(connectedServiceId, true);
        const token = tl.getEndpointAuthorizationParameter(connectedServiceId, "apitoken", false)
    }
    finally {
        // Probably report some failure here, right?
    }
}

Additionally, adding the connectedServiceId == undefined check allows for safe usage of connectedServiceId in later function calls.

Examples I found helpful/created

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants