I create custom task for tfs build 2017 that work on windows os, the task logic was written using powershell script and it's work ok.
When I try to implement the same logic for linux using node I have some problems:
pickList input type, I can't get value from this input
var tl = require('vso-task-lib');
let project = tl.getInput('project', true);
echo.arg(project);
Is there other way to read value from pickList?
multiLine input type, When I print the value I don't see the first line.
var tl = require('vso-task-lib');
var json = tl.getInput('json', true);
echo.arg(json);
if you know good Docomantation how to create custom task for TFS 2017/8,
How to debug custom task (set up environment) it will be very helpful.
Thanks
You could first go through Visual Studio Team Services Marketplace if there are some 3rd-party extension meet your requirement. Most of the extensions are open source, you could check and learn their source code.
VSTS and Microsoft also has created a GitHub repo with a number of samples and reading material to get you started, some tutorials for your reference:
VSTS Extensions Samples
Develop Extensions for VSTS
About how to debug and test in Linux environment, suggest you take a look at colin's blog: Developing a Custom Build vNext Task
Related
I am currently upgrading our XAML build definitions to the new build system. Already squashed a few errors, but now I am at a point where I can no longer tell what could be wrong. We use PowerShell scripts for most of the build process, and although all required data is available on the server, I get the following error when running the build:
Does anyone have any idea what could cause that error? Or at least where I should check?
Thanks in advance.
EDIT:
The script prepares build configuration that can not be done by external tools and are specific to our project. The error happens on the line $teamProjectCollection =...
Function Get-BuildNumberFromUri() {
<#
.SYNOPSIS
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.DESCRIPTION
Reads the build number from the current TFS build ($Env:BUILD_BUILDURI)
.NOTES
May fail if $env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI or $env:BUILD_BUILDURI
are not set
#>
[String] $CollectionUrl = "$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI"
[String] $BuildUrl = "$env:BUILD_BUILDURI"
if (-not $CollectionUrl -or -not $BuildUrl) {
return "0"
}
[void[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.VersionControl.Client")
$teamProjectCollection = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrl)
$buildServer = $teamProjectCollection.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
$buildDetail = $buildServer.GetBuild($BuildUrl)
$buildNumber = $buildDetail.BuildNumber
return $buildNumber
}
Here's the problem:
You're using a new build system. You need to step back and re-evaluate the existing scripts you have in context of the capabilities of the new build system.
You have this big PowerShell snippet that retrieves the build number. That's awesome, except for two things:
It's never going to work -- the SOAP object model does not have any awareness of "new" (e.g. non-XAML) builds. There is a REST API for them, instead.
You can retrieve the current build number by looking at the $env:BUILD_BUILDNUMBER variable. No special code necessary.
In previous versions of Team Foundation Server the Client Object Model was registered in the GAC and pre-loaded by the build agent when running XAML. In the new agent the build steps are independent of the client object model.
You have two options to locate the Client Object Model assemblies:
Ship the Client object model with the powershell scripts by referencing the Client Object Model Nuget package.
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.Client
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.ExtendedClient
Detect the location where Visual Studio is installed and loading the client object model from the Team Explorer extension folder. Examples can be found on the docs wiki.
There is also an easier, but officially unsupported option:
Do not use $(Agent.ServerOMDirectory). It is not safe for task authors to depend on the SDK bundled with the agent. Agent.ServerOMDirectory is a convenience variable that points to the latest SDK bundled with the agent. The SDK may have breaking interface changes between different versions. Depending on the latest version shipped with the agent will cause your task to be unreliable.
Getting at the buildnumber
There is a build variable being populated to set the build number in your script it can be referenced using $env:Build.BuildNumber.
To set the build number write a special statement to the console using
$value = "$($env:Build.BuildNumber)_US`
Write-Host "##vso[build.updatebuildnumber]$Value"
Alternatively you can use my Set Variable task from the VSTS Variable Toolbox extension.
Is it possible to develop custom task in tfs 2017 with c# code or only with powershell or nodejs.In xaml builds I can develop my custom activity with c#.But As I see in new tfs we can only develop scripts based plugins
public class MyCustomActivity : CodeActivity
You can write a custom activity in C# and package it in a PowerShell task. Just use PowerShell to call into the .NET assembly. Having some kind of static launcher class/method helps. You'd only need a very thin layer of PowerShell to extract the variables.
The old XAML activities are no longer supported though, you'd have to roll your own.
I'm converting our XAML build process to vNEXT build for our on-premise TFS 2017. One step I like to automate is the create a work item task for a specific user to execute after the release has been done. Is there a built in way to do this? I have a PowerShell script but I'd prefer not to use it if there is already a better way
No, there is still no out-of-the-box feature for this. Either using the REST api or the Client Object model in a powershell script just like you have done will do the trick.
You could also take a look at this similar question: How to have TFS automatically add certain tasks to new work items?, jessehouwing has provided a great answer.
Another way is using TFS Aggregator- a serverside pugin for TFS 2013
(update 2 and later) which has the ability to create new work items
based on rules. An example task can be found here:
https://github.com/tfsaggregator/tfsaggregator/wiki/Auto-Create-Children
Update
After go through the extension in VSTS marketplace (https://marketplace.visualstudio.com/) , there is also no existing task could do this. You may still use your powershell script or write your own extension.
I've recently developed custom build runners (plugins) to TeamCity and Jenkins. The plugins enable the users to start automated load tests as part of the build process.
To give you some idea here's the Jenkins plugin page with a lot of description:
https://wiki.jenkins-ci.org/display/JENKINS/Apica+Loadtest+Plugin
Here are a couple of screenshots of the TeamCity plugin:
The setup GUI: https://i.imgsafe.org/5221a01.png
Build log: https://i.imgsafe.org/c93f7f9.png
Custom tab with load test summary: https://i.imgsafe.org/f5b6937.png
Setup validation example: https://i.imgsafe.org/52cc9a2.png
These Continuous Integration frameworks allow a high level of customisation for plugin development: the UI, the output, client and server code etc. can all be tailored.
I've received a question whether we can develop a similar build runner for MS Team Foundation Build Service. I've completely new to TFS, I've never used it for anything. I've read through a couple of tutorials on how to install and set up TFS but there seems to be very little material available regarding custom build runners. The closest I've got are the following pages:
https://msdn.microsoft.com/en-us/library/bb130146.aspx
http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx
However, they don't provide any example on GUI extensions, validation, customisation etc.
Therefore I'd like to get the opinion of experienced TFS users before we get any more serious with the framework:
is it possible to develop plugins for TFS build?
what are the limitations? E.g. can I build a custom GUI with custom client/server actions?
can I include custom pages, show graphs etc?
Any advice is welcome.
Thanks for your help,
Andras
When it comes to TFS Build, you first need to know that there are two build systems: XAML Build and a new, now default, build system.
XAML Builds are based on Windows Workflow Foundation. You can create custom activities and add these to a Build Definition Template. XAML Build only run on Windows and extending them is not very easy.
The new Build system is based on Node, runs cross-platform and is very easily extendable. Microsoft has open sourced all the tasks they have for TFS Build (see GitHub for the repository).
Targeting the new build system means that you support on-premises installations of TFS 2015 and the cloud hosted version of TFS: Visual Studio Team Services (see visualstudio.com for more info).
The easiest way to get started is by creating a new VSTS account (free!), adding some code and running a build. If you have that working, you can start exploring the existing build tasks and learn what's possible. You can then easily create your own task and start experimenting.
One thing that might be of interest to you is that TFS/VSTS already support load testing. You can run a very simple load test with a couple of mouse clicks or configure more complex Web Tests and use these in TFS in combination with Application Insights. I'm not sure if that's what your customers are looking for but it's worth checking out (see Cloud-based Load Testing for more information)
I have generated my xml coverage file as part of CI build on the TFS server using vNext 2015 build definition. How would one display the results in the TFS 2015 summary ? Either using the xml report or the html generated using the ReportGenerator.
You need to convert the results produced by OpenCover to a format which can be parsed by TFS.
One way to do this would be to use the OpenCoverToCoberturaConverter NuGet package.
Once you have that, you can use the Publish Code Coverage Results build step.
I have described the whole process on my blog.
In “TFS 2015 - Update 2” this is possible by writing your own vsts extension (see here: https://www.visualstudio.com/en-us/docs/integrate/extensions/overview ).
I set up my own 'learning project' for building this as .vsix here: https://github.com/RobertK66/vsts-opencover.
My custom build step uses nunit3 console runner to execute tests under opencover.
I managed to upload the OpenCover xml result file as 'testrun-attachment' via REST-interface and got the pieces in place to show the summary values on both the build summary tab and on its own extended “build-results-view”.
Base for this first version were a lot of examples provided by MS on github: https://github.com/Microsoft/vsts-tasks and https://github.com/Microsoft/vsts-extension-samples
To get a first feeling what places on your TFS Web Portal can be extended/customized you can download and install this extension https://aha.gallery.vsassets.io/items?itemName=ms-samples.samples-contributions-guide from the Visual Studio Marketplace.
Hope this helps to get you started.
Currently, these customizations are not supported. You can't edit the displays in new build summary. However, you can customize Code Coverage Analysis.
You can submit it to User Voice site at:
http://visualstudio.uservoice.com/forums/121579-visual-studio
Instead of using OpenCover extension, it is very convenience for you to generate code coverage result and include it in the build summary page this way:
Select the Visual Studio Test step, check the Code Coverage Enabled option.
Then, the code coverage result shows on the build summary page: