Posted on 5 Comments

Trigger Azure Devops build pipelines using REST API

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

Organization: GeralexGR
Project: test-project

https://dev.azure.com/GeralexGR/test-project/_apis/build/builds?api-version=6.1-preview.6

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.

curl  --user '':'PAT' --header "Content-Type: application/json" --header "Accept:application/json" https://dev.azure.com/GeralexGR/test-project/_apis/pipelines/11/runs?api-version=6.1-preview.1

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

https://dev.azure.com/GeralexGR/test-project/_apis/pipelines/11/runs?&api-version=6.1-preview.1

The logic of the pipeline will only print the parameters that has been provided as input on the REST API.

trigger:
- none

pr: none 

pool:
  vmImage: ubuntu-latest

parameters:
  - name: name
    displayName: Tell me your name.
    type: string
    
steps:
- script: echo ${{parameters.name}} "succesfully triggered this build from a REST API call"
  displayName: 'print message from automatically created pipeline'

You can see in the result that my name is printed.

Azure Devops Rest API documentation:

https://docs.microsoft.com/en-us/rest/api/azure/devops/pipelines/runs/run-pipeline?view=azure-devops-rest-6.0

Youtube video:

Posted on Leave a comment

Connect to power platform – Azure Devops pipelines

In this article I will explain how to create a Power platform environment and connect on it through Azure Devops pipelines. Power platform is a low code environment provided by Microsoft that can implement services and functionality quickly with a GUI.

In order to follow the tutorial you will need an Azure subscription and a power platform subscription which will be connected.

First things first, you should create a power platform environment. You can do this, by logging in the Power Platform admin center and pressing the New button.

Then you should select the type and region and also the database connection. I chose a sample database so that I get automatically data to test.

By choosing the trial subscription the environment only works for 30 days. This is good enough for the purposes of this article but not for production environments. After the provision of the environment you will get the environment URL and also some sessions details that will be needed for Azure devops.

You can find the sessions details on the right upper corner.

The you will need to create an app registration on your Azure subscription.

Press New registration

Give a name and select which accounts could access this application.

After the provision of the application, you will have to set the API permissions. Select Dynamics CRM -> User impersonation

Then you will have to create a secret for the application. Go to certificates and secrets and create a new client secret. Copy the value, as it will be needed later.

On Azure Devops you should create a service connection. Go to project settings -> Service connections and add a new connection. Select power platform on the connection type.

You should then add the connection details gathered on previous steps. Client secret and application ID from the Azure application that you created. The server URL and tenant ID can be gathered from power platform admin center.

Then go and create a new Pipeline on Azure Devops and add the below two steps. The power platform tools installer is required any time you want to connect on power platform. This will instruct the build agent to download the necessary tools for the deployment. The WhoAmI task will authenticate with the instance and verify if the connection is working.

Edit the WhoAmI step and include the service connection

Check the result of the task, as it should be successful (Green)

Posted on Leave a comment

Create a release pipeline and deploy to local Kubernetes cluster with Azure Devops

On a previous article I described how you could create your self hosted agent to run your pipelines on Azure Devops. In this article I will explain how you can use this agent to deploy resources on your local Kubernetes cluster. As a prerequisite you should already have a kubernetes cluster locally. You can do that by installing Docker and enable the option for a kube cluster.

First things first you should connect your local Kubernetes cluster with Azure devops. For that reason you should go on Project settings -> Service connections and select Kubernetes

You can select between three different options. I selected kubeconfig

Get the output of the below command and paste it on the box. Then select untrusted certificates and add press verify and save.

kubectl config view --raw

Then you should go and create a release pipeline. Go on releases tab and press create release.

In the setup of the release pipeline you can change the trigger from automatic to manual. You should select your build pipeline that will trigger the release. In my case I selected the one I created on a previous article.

On the tasks of the release pipeline you should select the agent pool, as a result your self hosted agent. Depending on which pool you placed your agent you should add it appropriately. In my case it was on the default pool.

Then you can go and create the tasks of the release.

I chose two tasks, one for a deployment creation through kubectl commands and another one for a service exposure. You could also apply a .yml config file.

In this deployment I selected a sample image I created on a previous article, selected the namespace, added the requested parameters and selected create as the command. KubernetesConnection is the service connection that you will create and add on the first steps.

When you run the release pipeline you should see that the self hosted agent will be prepared for the run.

The job will start on your locally deployed agent.

The stages will start running.

Taken into account that everything is correct with your commands and configuration the job will be successful.

The green button of result indicate the win of your try.

Posted on Leave a comment

Create a build pipeline and push Image to external repository with Azure Devops

Azure Devops is the powerful Microsoft product for Devops solutions. In this article I will explain how you can create a build pipeline using predefined actions and tools provided in order to push an image to an external repository like Docker hub.

As a first step you should create two new service connections. As I am using Github, the one will be a github connection and a docker hub connection. To accomplish that you should go to project settings -> service connections and connect your accounts with your password credentials.

When you complete this step, the connected accounts will appear.

Then you should go to pipelines menu and create a new one. My pipeline has the name main-pipeline.

Azure Devops provides a large list of predefined tasks that will make your implementation easier and quicker. In my case I selected the build of a Dockerfile that will be listed in the Github repository.

In more detail the code will be checkout from the repository and the image will be created using a building machine that Azure provides from a shared pool of agents.

You can find the pipeline code below:

# Docker
# Build a Docker image
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- master

resources:
- repo: self

variables:
  tag: 'latest'

stages:
- stage: Build
  displayName: Build image
  jobs:
  - job: pushToDocker
    displayName: pushToDocker
    steps:
    - task: Docker@2
      displayName: Build an image
      inputs:
        containerRegistry: 'geralexgr-docker-repo'
        repository: 'geralexgr/aksjavarepo'
        command: 'buildAndPush'
        Dockerfile: '**/Dockerfile'
        tags: latest
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
        publishLocation: 'Container'

A successful run of the pipeline is shown below. As the code indicates the tag of the image should be the latest.

The created image will be stored on docker hub as indicated in the instructions.

You can then go and pull your image locally to test the result. In my case I would use:

docker pull geralexgr/aksjavarepo:latest