You shall not forget - reminding about pull requests in VSTS #1

Code reviews are one of the best ways to make sure, that everyone is aligned with recent code changes and allow a team to actually keep the codebase clean and well-maintained. The is one "meh" however - they require a developer to take a look and review changes. This require time and many people tend to postpone and forget about PRs(which I consider a bad practice, which discourage people from selecting different team members as reviewers). I'll show you a really easy way to remind people about waiting pull requests using VSTS REST API and Azure Functions.

Prerequisites

I won't go into details regarding authenticating REST API in VSTS in this post. If you're not sure how can you query it, check my other posts from VSTS category or read VSTS REST API basics.

Finding active pull requests

We'll start from a very easy task - we'll find active pull requests, which might require our attention. To do so we can use following endpoint:

/
GET https://{instance}/DefaultCollection/{project}/_apis/git/repositories/{repository}/pullRequests?api-version={version}[&status={string}&creatorId={GUID}&reviewerId={GUID}&sourceRefName={string}&targetRefName={string}&$top={integer}&$skip={integer}]

It's very flexible and allow you to specify many different parameters to return exactly what you wany. In our case we can simply use following version of this request:

/
https://{instance}.visualstudio.com/{project}/_apis/git/repositories/{repository}/pullRequests?api-version=3.0

It returns either an empty array of PRs(if none is active) or an array of active pull requests. In my case it returns a following result:

/
{
	"value": [{
		"repository": {
			"id": "...",
			"name": "LicznikNET vNext",
			"url": "...",
			"project": {
				"id": "...",
				"name": "LicznikNET vNext",
				"state": "unchanged",
				"visibility": "unchanged"
			}
		},
		"pullRequestId": 1,
		"codeReviewId": 1,
		"status": "active",
		"createdBy": {
			"id": "...",
			"displayName": "Kamil Mrzygłód",
			"uniqueName": "",
			"url": "...",
			"imageUrl": "..."
		},
		"creationDate": "2017-07-12T07:18:36.1561898Z",
		"title": "Merge branch ",
		"description": "Merge branch 'feature/LNETVN-204-data-should-not-be-collected-for-non-existing-locations' into develop",
		"sourceRefName": "refs/heads/develop",
		"targetRefName": "refs/heads/feature/LNETVN-204-data-should-not-be-collected-for-non-existing-locations",
		"mergeStatus": "succeeded",
		"mergeId": "...",
		"lastMergeSourceCommit": {
			"commitId": "...",
			"url": "..."
		},
		"lastMergeTargetCommit": {
			"commitId": "...",
			"url": "..."
		},
		"lastMergeCommit": {
			"commitId": "...",
			"url": "..."
		},
		"reviewers": [{
			"reviewerUrl": "...",
			"vote": 0,
			"id": "...",
			"displayName": "[LicznikNET vNext]\\LicznikNET vNext Team",
			"uniqueName": "...",
			"url": "...",
			"imageUrl": "...",
			"isContainer": true
		}],
		"url": "...",
		"supportsIterations": true
	}],
	"count": 1
}

It provides some information but there's no way to check how long we're waiting for reviewers. Let's try to find something, which will help us here.

Checking votes

Ok, let's try following approach - what if we go to our PR and try to actually mark it as Waiting for the author, as in real scenario?

I changed my PR status to "Waiting for the author"

Now let's query API once more and check results. This is what I got(I removed lines, which were not changed):

/
"reviewers": [{
	"reviewerUrl": "...",
	"vote": -5,
	"id": "...",
	"displayName": "[LicznikNET vNext]\\LicznikNET vNext Team",
	"uniqueName": "...",
	"url": "...",
	"imageUrl": "...",
	"isContainer": true
}, {
	"reviewerUrl": "...",
	"vote": -5,
	"votedFor": [{
		"reviewerUrl": "...",
		"vote": 0,
		"id": "...",
		"displayName": "[LicznikNET vNext]\\LicznikNET vNext Team",
		"uniqueName": "...",
		"url": "...",
		"imageUrl": "...",
		"isContainer": true
	}],
	"id": "...",
	"displayName": "Kamil Mrzygłód",
	"uniqueName": "...",
	"url": "...",
	"imageUrl": "..."
}],

As you can see we got some additional values for reviewers property. What is more interesting here is the vote property, which has changed from to -5. This is what will help us in the next post to make a working solution notifying team members about waiting pull requests - we'll try to find PRs with no votes, which are older than 24 hours and try to send a message to people involved in it, encouraging them to take a look at proposed changes.

Tips&Tricks - Adding a prefix to git commits automatically

This time I decided to write something, which is not Azure related, yet some people should find it interesting. To make a long story short - when working in a team using a git repository, we often agree on different kind of conventions, which help in keeping it clean and allow for easy integration with other tools(like issue trackers). The downside of such agreement is mainly a need to remember all structures and prefixes. In this post I show you how automate at least part of it - it's not something brand new, still I tried to present something elegant and easy to use.

git hooks

git has many cool features and hooks are one of them. If you haven't heards about them -  those are simple scripts written in shell(though you can use other languages like Python also), which are executed at the specific moment while working with your repository(like opening a commit message window). To make hooks working, they have to have a specific filename and must be stored in `.git/hooks` directory of your repository.

To start working with git hooks the easiest way is to initialize a dummy repository:

/
$ git init

and then go to `.git/hooks` repository and copy full content of the directory. When you open any file, you should see an example of a hook with some comments. Take your time and read them carefully since most of them provide some useful information.

Modifying a commit message

This time we'd like to modify a commit message. There are a few hooks, which could help here, but I decided to go for prepare-commit-message. I won't go into details here why this particular hooks has been chosen by me - commit-msg would fit here also. Personally I found it the most semantically correct for my purposes.

To modify a commit message you could use following shell script:

/
BRANCH=`git branch | grep '^\*' | cut -d '/' -f 2`
TASK=`echo $BRANCH | cut -d '-' -f 1,2`

echo -e "[$TASK] \n$(cat $1)" > $1

This script fetches a branch name, splits it and extracts two values from an array(which in my case are the project identifier and a task number). Let's say you have following branch name:

/
feature/TIMP-1-this-is-my-project-one

if you go to your git client and create a commit with a message This is my message!, you'll get following result:

/
[TIMP-1] This is my message!

How cool is that?

Enabling git hooks

All right, actually I lied a little - having only a script won't make, that a hook works. What you have to do is the following:

  • make sure a hook has a correct name(without .sample extension)
  • lies in .git/hooks directory

Using a script from an example your .git folder should contain following file:

  • .git
    • hooks
      • prepare-commit-msg

Now it should work flawlessly.

Summary

git hooks are great way to automate many things related to your daily work with a git repository. I strongly encourage you to dive deeper into this topic and automate as many things as you can.