Blog

Keeping your dependencies updated with Azure Pipelines and Dependabot

Regularly updating your package dependencies is one of the recommended ways of ensuring your software is up to date and secure. As developers, we feel that manually going through this process is quite a tedious and sometimes painful experience. Dependabot is a component that can be included as part of your development processes to handle these package updates automatically.

 

When using Github, Dependabot is natively integrated so it is as easy as creating a Dependabot Github Action in your repository to trigger the version updates automatically. Depending on your customization, this action can be triggered at a pre-set interval and it will create pull requests to keep your dependencies up to date. You can even go as far as automatically merging your pull requests without manual intervention. However it is generally recommended to also manually check Dependabot pull requests because sometimes package updates include breaking changes so your application code needs to be modified as well. For more details on how to use Dependabot in Github, see Automating Dependabot with Github Actions.

 

Dependabot is not natively integrated with Azure DevOps at the moment.  There is currently an unofficial Dependabot extension available developed by Tingle Software: Tingle Software Dependabot. Because it is unofficial, this might not be approved by your Azure DevOps project administrators. However, there are other approaches you can consider to include Dependabot in Azure DevOps.

 

There are 2 Dependabot repos that are key to the dependabot implementation: dependabot-core  and dependabot-script. Dependabot-core repo contains the Dependabot source code written in Ruby and in order to use it, you will have to do the implementation yourself. The alternative is dependabot-script repo that contains a reference implementation developed in Ruby and this is the repo used in this guide.

 

When using the dependabot-script repo, you have 2 approaches: either running the Ruby scripts interactively or non-interactively or simply using the docker image. For simplicity,  this guide uses the docker image.

 

The dependabot-script repo contains an example of how to get started with using the docker image: Azure Pipelines Sample

 

The steps included are:

Clone repo:

 

– script: git clone https://github.com/dependabot/dependabot-script.git
displayName: Clone Dependabot config repo

 

Build dependabot image using the available Dockerfile:

 

– script: |
cd dependabot-script
docker build -t “dependabot/dependabot-script” -f Dockerfile .

 

 

Run dependabot container:

 

– script: |
docker run –rm -e AZURE_ACCESS_TOKEN=’$(PAT)’
-e PACKAGE_MANAGER=’$(PACKAGE_MANAGER)’
-e PROJECT_PATH=’$(PROJECT_PATH)’
-e DIRECTORY_PATH=’$(DIRECTORY_PATH)’
-e BRANCH=’$(BRANCH)’
dependabot/dependabot-script

 

In order to give the right permissions to dependabot, you will need to acquire PAT tokens. When using PAT tokens, there are 2 approaches: using user’s PATs or using the job access tokens.

 

PAT tokens can be created if you go to the User Settings tab and click on Personal Access Tokens.

 

Personal access tokens

The key permission here is to make sure the Code scope is checked so Dependabot has the right access to raise any PRs:

 

PAT permissions

 

The generated PAT token can be stored in a variable group  and can be referenced in your pipeline.

 

variables:
– group: Dependabot-pipeline

 

 

If you follow this approach, you will create a set of Personal Access Tokens that belong to you which means that when Dependabot raises a PR, it will be on your behalf:

 

Dependabot PR on behalf of user

This will also mean that if you have strict branching policies, you won’t be allowed to approve the Dependabot PR if it comes on your behalf:

Sample branch policies

As you can see here, allowing requestors to approve their own changes is not approved and this setting would be recommended in a team.

An alternative to using PAT tokens is to use the available System.AccessToken which is a special variable that carries the security token used by the running build:

 

– script: |
docker run –rm -e AZURE_ACCESS_TOKEN=$SYSTEM_ACCESSTOKEN
-e PACKAGE_MANAGER=’$(PACKAGE_MANAGER)’
-e PROJECT_PATH=’$(PROJECT_PATH)’
-e DIRECTORY_PATH=’$(DIRECTORY_PATH)’
-e BRANCH=’$(BRANCH)’
dependabot/dependabot-script
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
displayName: Run Dependabot

 

A pre-requisite for this step is to make sure that the build service account has the right permissions to contribute to your pull request. If you go to Project Settings => Repos => Choose your repository.

Repo configuration

 

On the right hand side, you will be able to select the security tab for this repo and see the details for your repo:

 

Repo User permissions

What you need to look at is the build service account which will be under users and has the format : Project Name Build Service (Org Name). Here, make sure that the pull requests permissions are set, such as: contribute, contribute to pull requests, create branch and create tag. 

One final pre-requisite is to also set the job authorization scope job authorization scope.

Job authorization scope

Once the pre-requisites are met, your dependabot Azure DevOps pipeline can now use the System.AccessToken. Pull requests are coming now on behalf of your project build service account, which means anyone in your team can approve them:

Dependabot PR on behalf of Project Build Service

 

No Comments

Leave a Reply

Collect Thread Dump and Heap Dump on Linux App Service (Java/Tomcat)Working with API management DevOps resource kit

Contact Us

We are always here to help. Please reach out to us and we'll get back to you as soon as possible.

Address:

Maruti Court, Ground Floor
Mvuli Road, Nairobi, Kenya

Phone:

+254716973110

Hours:

Mon-Fri 8am – 5pm
Sat 9am – 1am
Sun & Holidays Closed




    Generated by Feedzy