Your final pipeline should look like the one below.
An additional issue you may face, could relate with the service connection authentication endpoint. The error indicates that the common endpoint cannot be used and the specific tenant-endpoint should be used instead.
##[error]AADSTS9001023: The grant type is not supported over the /common or /consumers endpoints. Please use the /organizations or tenant-specific endpoint.
Go and edit your service connection details
Endpoint URL:
https://login.microsoftonline.com/organizations
Be sure that your user has sufficient privileges and that prerequisites are met as documented from Microsoft.
LCS doesn’t support service-to-service authentication. Therefore, only regular user credentials (that is, a user name and password) can be used. Because the pipelines don’t run interactively, multifactor authentication must not be set up for the account that you use. We recommend that you set up a separate user account that has limited access and strong credentials that can regularly be rotated for security purposes.
Github has introduced a powerful feature to get complete view on your project dependencies. This feature is available per project but also for a whole organization which could contain hundred of projects.
You can get all your dependencies for your organization using the below link (ORG should be replaced with your GitHub organization name)
I was searching a method to get massively these dependencies exported as a file. I could obtain this information using the below code with the inspect element section of Chrome browser.
elements = document.getElementsByClassName("js-navigation-open");
for (var i=0; i <elements.length; i++ ){
var singleElement = elements[i];
console.log(singleElement.outerText);
The result is a list with the names of the dependencies.
Unfortunately this method will only get the dependencies that are present on each page that you are currently browsing.
In some cases you may need to schedule pipelines execution on nights but the schedules yaml feature cannot accomplish your needs. This could could happen if you have to provide parameters as inputs on the pipelines for a specific project export/import. In this case you could trigger your pipelines with REST APIs using ansible or another scripting tool.
In this article I will explain how you could trigger pipelines execution using the REST API of Azure Devops.
First things first you should create a personal access Token (PAT) in order to get the access required to run the pipelines on your organization. You can accomplish that by pressing your profile icon and selecting the sub-menu shown below.
You can specify the expiration of the token along with the access permissions. For the simplicity of deployment I gave it full access. You will need to copy the token somewhere as it will not be accessible after the creation.
In order to trigger a new build we would have to use the POST HTTP verb. Along with that we will need the repository name, the project name and the build pipeline ID. The below URL uses build API of version 6.1-preview.6 with the parameters
Using CURL we can get information of runs for a specific pipeline. For example in order to get the latest runs for pipeline with ID:11. In the below example you should replace PAT with your provisioned personal access token.
In order to implement a run of a build pipeline using REST APIs I will use Postman.
The selected verb is POST and the URL is the one mentioned above. By giving the URL on the input field, POSTMAN will automatically enumerate Query parameters.
In Authorization tab you should select Basic Auth. The username can be empty and the password will be your PAT.
On Headers tab, add Content-Type as application/json
In the body, you should specify the build pipeline ID in the JSON format that is shown in the picture. If you press Send, you will successful trigger your build pipeline with ID 11.
The next step is to edit the pipeline to include also input parameters.
In order to do that, I will use the latest version of the REST API that uses the runs URL instead of builds.
As shown in the picture the request URL will be pipelines/buildID/runs
When you need to pass parameters between your build and release pipelines it could be a real struggle if you do not want to use variable groups. Variable groups can accomplish the requested (to pass values between build and release pipelines) but this scenario is not useful for a parametric input which is a common case when deploying a project. You can accomplish that either by using a plugin from another publisher or by following the publish artifacts procedure that I will describe.
In order to pass variables between your build and release pipelines you can create/export a file containing your variable on your build agent. This file should be exported as build artifact and then downloaded on the release pipeline.
The below build pipeline implements the functionality I described. The exported file is named projectname.txt and will be located on artifacts folder on your build agent inside folder drop. For example C:\agent\1\a\drop
When you run the pipeline you will be asked for a parameter. I gave this entry my name which will be passed on release.
My release pipeline will download the build artifacts and get the value of the file. The release pipeline includes two steps.
The first one downloads the folder drop from build artifacts. The projectname.txt is located there.
Then the powershell will print the contents of the projectname.txt
You can check the result and verify you get the parameter input value from the powershell script.
Bonus content:
You can also write your input parameter as a variable on the build agent and reference this value on a later step. This should be again a powershell step on your release pipeline.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
