Makes Your Laptop Becomes A Build Agent Of VSTS

You are a developer and working on some open source projects. You are using VSTS to maintain your source code. As you know the free version of VSTS is giving 240 minutes every month for the build. What happens if your free minutes have gone? You need to wait for until to next month to build and deploy your projects?

You are using the preview version of Visual Studio (currently is 2017 preview 3) to develop some projects on .Net Core 2 and .Net Standard 2 preview 2. However, the is no available build agent on VSTS for the preview framework yet.

I have a crazy idea why don’t use our laptop as a build agent for VSTS so that you can install whatever you want on your laptop worry less about the host compatible? If you are facing some difficulties above then this post I will show you how to makes your laptop becomes a build agent of VSTS.

1. Download Agent Package

Login to your VSTS and navigate to the Agent Queues and then click download agent. There is three package available for Window OS X and Linux. You shall able to download a zip package around 83MB for your window. This package contains all needed components for a build agent host.

 

2. Generate Personal access tokens

Click on you account icon at the top right and navigate to security then Personal access tokens. Create a new token named build-agent with the Authorized Scopes as below.

After clicking the save button, you will have a token look like this:

khyppjfxamx6sjjrmhfdefthbdxzssltvoevxp56rn5ezdrunkcoding

Refer here for details of Personal access token creating and revoking.

3. Agent Installation

  • Right click on the downloaded zip package -> properties and check the unblock checkbox then click ok.
  • Unzip the package into C:\vsts-agent.
  • Create a folder C:\vsts-build for the build this one will be used to contain the source code from VSTS when executing a build definition.
  • Run the PowerShell with administrator privilege and point the unzipped package (by using cd command).
  • Run the ./config.cmd to start the installation:

  • When running agent as service it will ask for the service account, I’m using Network Service as the service account for the agent. The reason to run the agent as service is whenever you start your laptop/Pc up the agent will be available in the VSTS immediately without any configuration needed.

Run the command .\config.cmd remove to un-install the agent on your laptop if need.

I like the way Microsoft develop the agent, your laptop doesn’t need a static IP for it, The agent will work whenever the laptop is up and connected to the internet care less about the IP and location. Bring your laptop everywhere you want and execute the build anytime you need.

4. Agent Configuration

Now navigate to the default agent pool on your VSTS your laptop name should appear. Before executing the build, you need to define the capabilities of the new agent as below. The Java capabilities on the below screenshot are needed if you are using some Java build tasks example Sonarqube tasks.

 

Here is the full text of the capabilities of my laptop for your reference purpose.

  • java: C:\Program Files\Java\jdk1.8.0_131
  • jdk: C:\Program Files\Java\jdk1.8.0_131
  • jdk_8: C:\Program Files\Java\jdk1.8.0_131
  • MSBuild: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\Bin
  • VisualStudio: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise
  • VSTest: C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow

Now you can execute your build without the limitation. However, please note that this one for personal use only. I don’t recommend to use this on your company as exposing a server to the internet is not compliance and dangerous.

If your company is using VSTS, then should purchse the agents from Micrsoft or hosting everything (TFS and Agents) on the premises to maximize the flexibility is also a case.

This is the screenshot to prove that my laptop is working fine with VSTS.

Nuget Packager Unsupported Framework Issue on VSTS

I was facing an Unsupported Framework issue with Nuget packager on Visual Studio Team Service Online (VSTS) when porting my HBD Framework to the .Net Standard.

I had been mad with this issue in a couple of days, and eventually, I found a solution to fix it. Let me explain about the problem and the solution. So it might help for those who are facing the same problem.

1. Build and Deployment Process.

First, I would like to share my Nuget Publishing Automation Process. I have using VSTS as primary source codes repository sin last few years. In there, I created a few auto build and auto release processes that help to publish my packages into Nuget.org continuously.

Internally, I’m using the Package Management for VSTS as my test environment. So all beta versions of my packages have been published into this tool for testing purposes. Once the package is stable, I just simply trigger the other release to put it to Nuget.org.

Below is the illustration of the publishing process that had been implemented on my VSTS.

I will show you the details of the continuous deployment in difference post as the purpose of this post is fixing the Nuget Packager issues.

Continuous Deployment

2. The Issue.

When ported my HBD framework to the .Net Standard, the Nuget Packager was showing the below warning message when packaging my binaries on VSTS.

After then The .Net Standard had displayed as the Unsupported framework on my package. Hence, my package was not able to publish to Nuget.org as it is not allowed an Unsupported framework to be deployed.

Furthermore, if open the nuspec file with Nuget explorer the frameworks is displaying properly.


Here is the configuration of my nuspec file.

3. The solution

After spending a lot of times on this issue, I realized that the problem is the version of default Nuget.exe file in Nuget Packager is old (3.x), and it is not supporting the .Net Standard.

So, to fix this issue, I downloaded the latest version of Nuget.exe here and replaced the default version of Nuget packager by the following configuration of the build definition on VSTS.

  1. Put the Nuget.exe file in the Shared location on VSTS.
  2. Map the Shared location to the Build Definition.
  3. Replace the Nuget.exe of Nuget Packager with the version in Shared location.

 

Then execute a new build and re-deploy the package to Nuget.org again, here is the result.

  • Hopefully the issue of the Nuget Packager will be fixed soon. However, ai this time if you are facing the same problem then just apply this as the work around solution for your build.
  • VSTS online is free tool. Register here if you want to learn about the auto build, auto deployment.

You can download the latest source code of HBD.Framework here.

Sync The Source Code From TFVS to Github Automatically.

If you are using Team Foundation Visual Studio Online (TFVS) as your primary source control and your Github repositories as a public, sharing hub, that everyone can view and download the source code of your NuGet libraries and you want to keep your Git repository up to date with your TFS source code. Then this post may help.

In this post, I will show you how to create a build on TFVS that help to sync a particular source code folder on TFVS to a repository on Github.com.

I. Generate Github Personal Token Key.

The personal token key on Github as an OAuth access key allow TFVS download and submit your source code to Github without your username and password.

You can generate a new token key here by login to Github -> Account Setting -> Personal access tokens under Developer Setting. The permission of this token should be in repo scope. That allow to download the source code from Github and commit the changes back to the repository.

Token permission
After generated a token your token will look like as below. Note down this token as you won’t be able to view it again after closed this page.

The generated Token
The URL format that will be used to pull and commit the source code to Github look like this https://[token]@github.com/[yourUserName]/[yourRepositoryName].git

II. Create a TFVS build definition.

Now, go to your TFVS and create a new build definition with following tasks.

1. Get sources task.

This is default task of the build definition will help you to download specific source code folder from TFS repository.

 

2. Config the variables.

As the URL format above will be used in many tasks below.In case if you want to changes your token key or repository name you need to go through all the tasks and changes one by one.

To make the life easier, I will create 2 variables in the Variable tab of the build definition as below.

  1. githubtoken with value is the token key had been generated in step 1.
  2. GitRepo with value is the name of the Github Repository that you want to sync the source code to.

So following is my new URL format with token and git repository now are the name of variables. Please remember to replace by username (baoduy) with your account.
https://$(githubtoken)@github.com/baoduy/$(GitRepo).git

3. The Git clone Task.

Now go back to the Tasks tab and Add new Command Line task and config the parameters as below. This task will help to clone a Github repository to the $(Build.SourcesDirectory)\GitRepo location.

  • Display Name: Run git clone
  • Tool: git
  • Arguments: clone https://$(githubtoken)@github.com/baoduy/$(GitRepo).git

4. The Delete files from GitRepo Task.

As the purpose of this build definition is sync the source code from  TFVS to Github. So that, the current source code in Github can be considered is the out of date code and will be clean up before copying the latest source code from TFS folder.

Add a new Delete File task and config the parameters as below.

  • Display Name: Delete files from GitRepo
  • Source Folder: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)
  • Contents:
                      **
                     !.git/**

5. The Copy Files Task.

This task will copy the file from TFS source code folder to the Github repository folder. The parameters will be configured as below

  • Display Name: Copy Files to: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)
  • Source Folder: $(Build.SourcesDirectory)
  • Contents:
                      **
                    !$tf/**
    !GitRepo/**
  • Target Folder: $(Build.SourcesDirectory)\GitRepo\$(GitRepo)

6. The Run git add Task.

This command will help to detect all changed files in the Github repository and prepare the changeset for the upcoming commit statement.

  • Display Name: Run git add
  • Tool: git
  • Arguments: add -A .

7. The Run git commits Task.

This task will execute the commit command on the local Github repository.

  • Display Name: Run git commit
  • Tool: git
  • Arguments: commit -m”Sync from TFVS”

8. The Run git push Task.

This is the final task to upload the changeset to the remote Github repository.

  • Display Name: Run git push
  • Tool: git
  • Arguments: push https://$(githubtoken)@github.com/baoduy/$(GitRepo).git –force

After done the task’s configuration your build definition will look like this:

Now save and queue your build. The results of the run should be as following screen shots.

1. The build ran successfully.


2. The source code had been synced to the Github Repository.

III. Trigger a new build from the Release process.

So example, you have a Release process that uploading your binaries to Nuget and when the upload task is done you want to execute the above build definition to sync your code to Github automatically.

There is an extension named Queue Build(s) Task that provides a nice feature for your release process that able to launch a new build of the build definition. You can install this extention and add 1 more task for your Release process as the configuration below:

 

If you want to clone the build definition for the other Github repository. Only 2 setting had been highlight with red color need to be changes the all tasks configuration will be work without any amenment required.

Hope this help.