Building feature branches on VSTS automatically

Currently VSTS lacks(see edit below) really handy feature, which lets you trigger a build based on a branch wildcard. For instance, I'd like to run my build definition only for refs/heads/feature/* branches. While it's super-easy when using e.g. TeamCity, with VSTS it requires us to prepare a smart workaround.

Service hooks

VSTS provides us a wide collection of different service hooks. They can be used to command builds, analyze logs or trigger any kind of an event. In fact the list of available services is already impressing and gets bigger - I strongly recommend you to take a look when you have a minute.

Besides integrating with third-party services like Slack, Bamboo or Trello, it allows us to use a simple Web Hook, which can send a specific event to a specific endpoint. Because we can send any event to any endpoint, the sky is the only limit - you can create a "lambda" using Azure Function(like me), a simple WebAPI or old but still reliable MVC application using technology stack of your choice. Whatever solution you'll create, it will work as long as it can process HTTP requests.

Kick it back!

Retrieving an event from VSTS is cool but gives information only. What we really need is to orchestrate VSTS to schedule a build using a specific build definition on a specific branch. Once again REST API provided by VSTS comes to the rescue:

POST https://{instance}/DefaultCollection/{project}/_apis/build/builds?api-version={version}

The important part of this request is its body:

  "definition": {
    "id": 25
  "sourceBranch": "refs/heads/master",
  "parameters": "{\"system.debug\":\"true\",\"BuildConfiguration\":\"debug\",\"BuildPlatform\":\"x64\"}"

There're two things which are required to make it work: build definition ID and source branch. You can obtain the former from the URL when you go directly to the definition you choose, once the latter is being passed along with the whole request in data.resource.refUpdates[0].name field.

Code example

An example of a Azure Function which can handle the functionality:

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
    log.Info("C# HTTP trigger function processed a request.");

    // Get request body
    dynamic data = await req.Content.ReadAsAsync<object>();

    if(data.eventType == "git.push" && data.resource.refUpdates[0].name.Value.Contains("refs/heads/feature")) {
        using(var client = new HttpClient()) {
            var branch = data.resource.refUpdates[0].name.Value;
            log.Info($"Build will be scheduled for {branch} branch.");

            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", "yourToken");
            await client.PostAsync("https://{yourInstance}{projectId}/_apis/build/builds?api-version=2.0", 
                new StringContent($"{{\"definition\": {{\"id\": {definitionId}},\"sourceBranch\": \"{branch}\"", Encoding.UTF8, "application/json"));

            log.Info($"Build scheduled successfully!.");
            return req.CreateResponse(HttpStatusCode.OK, "Build scheduled");

    return req.CreateResponse(HttpStatusCode.BadRequest, "Error occured");

Combining it all

To summarize steps needed here:

  1. Go to Service Hooks tab in VSTS and create new Web Hook pointing to your service endpoint using Code pushed as event
  2. Create a service, which will handle requests sent by VSTS and call its API to schedule a build
  3. Enjoy builds including only filtered branches


After this was pointed I checked recently updated docs and it seems wildcard are now officially supported! You can treat this post as an inspiration for building new features around VSTS. You can find new documentation here ->

Reporting issues in YouTrack automatically


When working on my side-project for my client, I often require some specific data to address reported issue. It could be a specific request with its body, logged exception with a stack trace or authenticated user's context. I've learned, that expecting someone to paste all necessary data when reporting an error, always fails - remembering each time what you have to include is both tiresome and burdersome. Fortunately there's a possibility to automate things.


Currently I am using YouTrack so I'll stick to this issue tracker only. YouTrack exposes a REST API, which allows you to easily create, delete and manage reported issues. A reference to this API can be found here. Although it is possible to write your own client, I decided to use YouTrackSharp library - for my expectations it is a reasonable choice.

For now I've been missing following data in most issue reporting cases:

  • lack of full request's body - how to reproduce a problem without knowing what was sent to the server, especially when Jil sometimes goes crazy during deserialization
  • lack of user's context - how to reproduce problem without knowing who exactly performed a request
  • lack of headers sent and all request related data

Because I've already been catching all unhandled exceptions to log them, finding a place to call my "CreateYouTrackIssue" method is a piece of a cake. To be honest, I could take advantage of using EventStore and just raise an event, which will be further proceeded - maybe in the future I recreate it this way.

Whole method could look like this:

private static void CreateYouTrackIssue(Exception ex, Stream body)
      using (var reader = new StreamReader(body))
            var conn = new Connection("host", 8080);
            conn.Authenticate("user", "password");

            var json = reader.ReadToEnd();

            dynamic issue = new Issue();
            issue.ProjectShortName = "SOME_NAME";
            issue.Summary = "API error - " + ex.Message;
            issue.Description = string.Format(
                    "An API error occuredd: :\r\nJSON: {0}\r\nStackTrace: {1}",
            issue.Assignee = "root";
            issue.Type = "Bug";
            issue.State = "New";

            var im = new IssueManagement(conn);


This is just a sketch so it doesn't contain all mentioned features but note few things:

  • I'm passing stream to read its content - to get all necessary data passing some request's context would be more practical
  • I'm not handling HTTP connections - YouTrackSharp takes care of it
  • I'm assigning each feature to the root user - you can select whatever user you want

Because Issue() is dynamic, you can pass every custom field you created in YouTrack.


Above solution has already saved me some time when trying to reproduce reported error. What is more, it makes my client happy - he knows, that each time he sees a red error alert, issue has been created and I have been notified about it.