I am trying to utilize the PublishBuildArtifacts task within a build definition that is designed to build some artifacts within a Linux environment.

1 2015-07-22T20:42:57.498Z: Cleaning staging folder: /home/msimons/BuildAgents/MultiDevTest/_work/build/ce2c019942eac2ab3e1bceb308a15a1f1789b1e89e2218e12a6aecbde54b4869/staging/CoreClr
2 2015-07-22T20:43:00.109Z: found 25 files
3 ##[Error] 2015-07-22T20:43:00.305Z: TypeError: undefined is not a function
4 ##[Error] 2015-07-22T20:43:00.389Z: Return code: 1

The inputs I have set are the following
Copy Root = ""
Contents = "bin/Product/**"
Artifact Name = "CoreClr"
Artifact Type = "Server"

I have also tried to user the File share type with the same result. My expected outcome would be for this to work or to have more assistance from the log output in determining the source of the failure.

After installing on a clean machine, attempting to install as a launch agent will fail if the LaunchAgents folder does not exist yet.

Fresh install of Xubuntu 14.04.3 on physical machine.
Followed the README.md literally.
installed curl, nodejs (v0.12.7) and npm (2.11.3).
Used FQDN of Team Foundation Server to startup agent, but it exits with:

Error starting the agent
connect ECONNREFUSED.

Connecting with Firefox to the same server with identical credentials works OK.
Installed Wireshark; shows connection between Firefox and TFS. Shutdown firefox, start vsoagent: no packet shown in Wireshark (no SYN sent....)

What am I doing wrong?
What can I do to debug this?

Firstly please accept my apologies if this is not the right place to ask this question...

We have some integration tests that relies on Azure Storage Emulator which fail when we run them using VSO Build with the following:

-------- System.Net.Sockets.SocketException : No connection could be made because the target machine actively refused it 127.0.0.1:10002

These test for fine on our local machine(s). I'm suspecting that it's something to do with loopback adapter or such like as I've had problems like this before with server's which have been hardened as I assume the environment hosting VSO build agent's are.

Does anyone have any ideas on how I could run the Azure Storage Emulator successfully using hosted VSO agent ?

I'm currently using a free VSO account I've successfully configured 2 Windows agents using Alternate Credentials. However, on Linux, I can create the agent and it shows up in VSO, but it cannot start. Any ideas why it would work on Windows but not Linux? Is it because Alternate credentials are deprecated?

We just upgraded our on-premise TFS server from 2013->2015 RC last week. I have done all of the setup steps on a Yosemite OSX build (Xamarin) server but when I attempt to configure the agent, I always get...

Error starting the agent
http://xxx is not a valid URL

FYI, I have tried a variety of different flavors of the URL - some with the 8080 port, some without, some with the default collection, some without.

What am I doing wrong?

Summary

After rebooting OSX 10.10.3, I'm getting an error message on service startup

cat /Users/username/Library/Logs/vsoagent.poolname.hostname/stderr.log
2015-06-22T15:32:44.516Z: Another agent process is running.  Exiting.

After removing the .lock file manually, the agent comes up on next restart.

Please pardon my frivolous issue if this is already planned to be addressed. I wasn't sure if this TODO in service.ts applied to this issue or was referencing something else...

Thanks,
Jeyan

Details

installed service via

./svc.sh install

service was shown as running

ps -ef | grep node

restarted Mac Mini running OSX 10.10.3

sudo shutdown -r now

service wasn't started

ps -ef | grep node

Log file showed error message

cat /Users/username/Library/Logs/vsoagent.poolname.hostname/stderr.log
2015-06-22T15:32:44.516Z: Another agent process is running.  Exiting.

Removed lock file & restarted

rm /path/to/installed/agent/.lock
sudo shutdown -r now

service was started

ps -ef | grep node

Hi, according to the documentation, the agent should only ask for a username/password the first time it is run, and save this information for future runs. In the example output from running node agent/vsoagent, there is a line that says Config saved. However I don't see this - I am prompted for the username/password every time. This means I cannot run the agent as a service.

Am I missing something?

Running Ubuntu 15.04

Here is the callstack in the agent window, the agent is now locked, because there is a dialog box open saying the following, which has locked the agent state. Ideally the agent should handle this and return to a state where it is ready to accept a new job.

Dialog Displayed

VsoAgent.exe has stopped working.

A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available

[Debug] [Close Program]

Callstack of error

ERROR:
Server stack trace:

ERROR:
at System.ServiceModel.Channels.CommunicationObject.ThrowIfDisposedOrNotOpen()

ERROR:
at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)

ERROR:
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

ERROR:
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

ERROR:
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

ERROR:
Exception rethrown at [0]:

ERROR:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

ERROR:
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

ERROR:
at Microsoft.TeamFoundation.DistributedTask.Agent.Logger.INetPipeWriter.Disconnect(Guid jobId)

ERROR:
at Microsoft.TeamFoundation.DistributedTask.Agent.Logger.ForwardingWriter.Dispose()

ERROR:
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseLogger.DisposeWriter(String name, ILogWriter writer)

ERROR:
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseLogger.Dispose()

ERROR:
at VsoWorker.Program.Main(String[] args)

ERROR:
There is not enough space on the disk.

WARNING:
Unable to process logging event:##vso[context.logissue type=error;]There is not enough space on the disk.%0D%0A

Unhandled Exception: System.IO.IOException: There is not enough space on the disk.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.FileStream.Write(Byte[] array, Int32 offset, Int32 count)
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.Write(String value)
at Microsoft.TeamFoundation.DistributedTask.Agent.Logger.FileWriter.WriteMessage(ILoggerScope scope, String message)
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseLogger.LogConsoleMessage(ILoggerScope scope, String message, LoggingVerbosity verbosity)
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseContext.LogConsoleMessage(ILoggerScope scope, String message, LoggingVerbosity verbosity)
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseContext.LogMessage(Boolean mask, LoggingVerbosity verbosity, String message, Object[] args)
at Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.BaseContext.LogMessage(String message, Object[] args)
at Microsoft.TeamFoundation.DistributedTask.Agent.WorkerRunner.WorkerProcessExited(Object sender, EventArgs e)
at Microsoft.TeamFoundation.DistributedTask.Agent.Common.ProcessWrapper.ProcessExitedHandler(Object sender, EventArgs e)
at Microsoft.TeamFoundation.DistributedTask.Agent.Common.ProcessWrapper.ReadStreamComplete(IAsyncResult result)
at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage msg)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()

The demo video and written instructions seem to assume that the client will use Alternate Authentication Credentials set by a user with a Windows Live ID from Profile -> Credentials. [Currently basic auth?]

Is it possible to use a Visual Studio Online service account instead? [We would like to avoid builds running under credentials of a named user and lock down access as much as possible.]

We were able to provision a service account using IAccessControlService.ProvisionServiceIdentity, but I'm not sure how to set Alternate Authentication Credentials for it...

Some posts elsewhere seem to indicate that it is impossible to authenticate as a service account via basic auth and Windows Authentication is required instead.
I.e. comments here

How to reconfigure on OS X?

There seems not to be a node agent/vsoagent --help to find how to reconfigure for another Visual Studio Online URL.

I get the following error when trying to run the xplat agent.
The agent is running on an updated Arch Linux box.
The agent can connect to the pool just fine.
My server has Basic auth and Windows auth enabled.
To check permissions, I had the agent connect using the server administrator account and it still got the error.

Preparing tasks

Running prepareWorkspace

preparing Workspace
cwd: /home/buildbot/_work/build/5e4d9fa0a08108dca09c3c958f6ffb51db2ab6879a225bb61bf84d22f55efd33
using source provider: tfsgit
loading: /home/buildbot/agent/scm/tfsgit
Using auth scheme: OAuth
running clean
skipping clean since repo does not exist
getting code
https://[server]:8080/tfs/[collection]/_git/[project]
srcVersion: 4bf89e336e69194e927dc078af9281d77683c7b3
srcBranch: refs/heads/dev
Using ref: 4bf89e336e69194e927dc078af9281d77683c7b3
/usr/bin/git arg: clone
/usr/bin/git arg: https://...@[server]:8080/tfs/[collection]/_git/[project]
/usr/bin/git arg: --progress
/usr/bin/git arg: repo
exec tool: /usr/bin/git
Arguments:
clone
https://...@[server]:8080/tfs/[collection]/_git/[project]
--progress
repo
Cloning into 'repo'...
fatal: Authentication failed for 'https://OAuth:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjN2Yjd3emNuY3dJZVRYclgzRFF2N3lOUjEyVSJ9.eyJuYW1laWQiOiI0Y2Q2MGZkZi1jN2I4LTQyZmUtYWRkOS0yNmQ1NTM4YzQ4ZTYiLCJzY3AiOiJhcHBfdG9rZW4iLCJhdWkiOiI1NzYwYWRlOS04NjZmLTRhZTAtYmExZi0wOTk4NDhjNGEzOTEiLCJpc3MiOiJkZXYuZGltZW5zaW9uYWxwaGEubmV0IiwiYXVkIjoiZGV2LmRpbWVuc2lvbmFscGhhLm5ldCIsIm5iZiI6MTQ0MDI2NDk1NSwiZXhwIjoxNDQwMjY4ODU1fQ.NSKfQiQWN8kMEQMxvI0uuzdOhDlfzbsoPMVJp0DHY33h1XkMDu1DwwKlclR-rIYy5n5-5rME1pXp7vuLtT73NjrTL7ghTLnmF...
rc:128
success:false
/usr/bin/git failed with return code: 128

This is almost assuredly not the right place for this, and I apologize for that, but I wasn't quite sure where else to send it so that the correct ears would hear it. Could you either pass along the word, or direct me to where I might open an issue / ticket to get his corrected?

In the Json file describing the VSTest task in Build vNext (TFS 2015 RC) the input for "path to custom adapters" is described as follows:

    {
      "name": "pathtoCustomTestAdapters",
      "type": "string",
      "label": "Path to Custom Test Adapters",
      "defaultValue": "",
      "required": false,
      "helpMarkDown": "Path to custom adapters.",
      "groupName":"advanced"
    }

Since the "type" is "string", it does not get the solution path prepended to it, and thus relative paths operate relative to the location of the ps1 script, not your solution. Changing tito type "filePath", as is done in the assembly search pattern, fixes this.

Thanks!

As an example:

ictfs-admin@IC-TFS-BA-02Lin:/usr/vsoagent$ node agent/vsoagent
Enter alternate username > [email protected]
Enter alternate password >
Enter server url > http://ic-tfs-at-01:8080/tfs
Enter agent name (enter sets IC-TFS-BA-02Lin) >
Enter agent pool name (enter sets default) >
Error starting the agent
http://ic-tfs-at-01:8080/tfs is not a valid URL

"ic-tfs-at-01" is not a FQDN. This is caused by line 184 of configuration.ts:
throwIf(!check.isURL(settings.serverUrl), settings.serverUrl + ' is not a valid URL');

The validator library has options for controlling this behavior.

when starting the agent all appears fine and then i get and it gets all the env variables and then i get a 500 error.

output:
Enter alternate username > [email protected]
Enter alternate password >
Enter server url > http://tfs.mydomain.com:8080/tfs
Enter agent name (enter sets lx-server) >
Enter agent pool name (enter sets default) > test
successful connect as undefined
Retrieved agent pool: test (2)
...................................... /// bunch of env vars
Error starting the agent
Failed Request: Internal Server Error(500) - http://tfs.mydomain.com:8080/tfs/_apis/distributedtask/pools/2/agents

Shutting down host.

Hello!

We are trying to preview this build agent, for use with our On Premise installation of Team Foundation Server 2015 RC. It seems to rely on the VSO feature for "Alternative Credentials", but this tab is not available from the "Profile" dialog in TFS On Premise. Is there something we need to do to enable this, or some other work around?

Regards,
Pi Lanningham

I started getting the following error when running node agent/vsoagent.js on OS X (10.10)
Node: 4.1.1
NPM: 2.14.1

Jeppes-MacBook-Pro:agents jeppe$ node agent/vsoagent.js 
Enter alternate username > [masked]
Enter alternate password > 
Enter server url > https://[masked].visualstudio.com
Enter agent name (enter sets Jeppes-MacBook-Pro.local)  > goto-osx-build-01
Enter agent pool name (enter sets default)  > 
successful connect as Jeppe Andersen
Retrieved agent pool: Default (1)
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap SHELL=/bin/bash
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap TMPDIR=/var/folders/nc/80xlnfl53zn_nzp_dns741480000gn/T/
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.hIWASLMb7j/Render
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap TERM_SESSION_ID=9FFD9560-AD28-4382-A646-19407F967A01
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap USER=jeppe
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.TxxYJhBQga/Listeners
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap PATH=/Library/Frameworks/Python.framework/Versions/3.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap PWD=/Users/jeppe/agents
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap XPC_FLAGS=0x0
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap XPC_SERVICE_NAME=0
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap HOME=/Users/jeppe
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap LOGNAME=jeppe
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap LC_CTYPE=UTF-8
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap _=/usr/local/bin/node
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap OLDPWD=/Users/jeppe
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : PATH=/Library/Frameworks/Python.framework/Versions/3.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap ant not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap clang=/usr/bin/clang
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap cmake not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap curl=/usr/bin/curl
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap git=/usr/bin/git
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap jake=.
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap java=/usr/bin/java
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap make=/usr/bin/make
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap mdtool not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap mdtool not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap mvn not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap node.js=/usr/local/bin/node
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap nodejs not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap npm=/usr/local/bin/npm
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap gulp not found
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap python=/usr/bin/python
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap python3=/Library/Frameworks/Python.framework/Versions/3.4/bin/python3
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap sh=/bin/sh
Sat Sep 26 2015 09:59:36 GMT+0200 (CEST) : cap xcode=/Applications/Xcode.app/Contents/Developer

Jeppes-MacBook-Pro.local
Error starting the agent
Failed Request: Bad Request(400) - https://[masked].visualstudio.com/_apis/distributedtask/pools/1/agents

Hi,

I know you are working on this, but would like an issue here so that we can track when that is fixed, since we can't use test report publishing without that.

I added a Publish Build Artifacts step, but it always fails with an error:

2015-07-31T12:58:53.920Z: Cleaning staging folder: /vso/work/build/e77e2255f478cdc1bc5f4775e7d7cc6c159410e4c8bda1b698b41a91d1bfaec1/staging/Editor
2015-07-31T12:58:56.303Z: found 323 files
2015-07-31T12:58:59.740Z:  
2015-07-31T12:58:59.740Z: Start: Upload a build artifact
2015-07-31T12:58:59.740Z: End: Upload a build artifact
2015-07-31T12:58:59.740Z:  
##[Error] 2015-07-31T12:58:59.741Z: No container folder specified.
2015-07-31T12:58:59.741Z: Failing task since command failed.

Here's the configuration:

It feels like there's something missing in the UI, especially since the code goes looking for a containerfolder property.

The Azure cloud service deployment script fails the second deployment if the service uses the diagnostics extension and is swapped from staging to production.

ConflictError: The extension ID RoleName-PaaSDiagnostics-Staging-Ext-0 is already in use for this deployment.

It seems possible to use the Set-AzureServiceDiagnosticsExtension instead to set the diagnostics, but it is pretty slow

Using sudo npm install vsoagent-installer -g (as the README.md states) installs an older version of vsoagent which does not support TFS version control.

I pulled latest source and tried to build and got this error:

[16:01:46] Using gulpfile ~/git/vso-agent/gulpfile.js
[16:01:46] Starting 'clean'...
[16:01:46] Finished 'clean' after 5.06 ms
[16:01:46] Starting 'copy'...
[16:01:46] Finished 'copy' after 22 ms
[16:01:46] Starting 'build'...
[16:01:46] Compiling TypeScript files using tsc version 1.5.3
[16:01:48] [tsc] > /Users/derenebdon/git/vso-agent/src/agent/scm/tfsversioncontrol.ts(33,26): error TS2305: Module '"/Users/derenebdon/git/vso-agent/src/agent/api/interfaces"' has no exported member 'JobEndpoint'.
[16:01:48] [tsc] > /Users/derenebdon/git/vso-agent/src/agent/scm/tfsversioncontrol.ts(38,37): error TS2305: Module '"/Users/derenebdon/git/vso-agent/src/agent/api/interfaces"' has no exported member 'JobEndpoint'.
[16:01:48] [tsc] > /Users/derenebdon/git/vso-agent/src/agent/scm/tfsversioncontrol.ts(316,44): error TS2305: Module '"/Users/derenebdon/git/vso-agent/src/agent/api/interfaces"' has no exported member 'JobEndpoint'.
[16:01:49] Failed to compile TypeScript: Error: tsc command has exited with code:2

events.js:85
throw er; // Unhandled 'error' event
^
Error: Failed to compile: tsc command has exited with code:2

I am building on Mac OS/X Yosemite.

I've set up the xplat agent on a Mac Mini server and succesfully connected it to my on-premise TFS. However, when I run a build that is using a Git repo (TFS hosted Git that is) I'm getting the following output:

preparing Workspace
cwd: /Users/Shared/BuildAgents/Agent1/_work/build/8f606dfb41c4926101422d0198a9c955169bafb520042a138beeaec27c5ce25f
srcVersion: 8ed6808d0ef4b950182ffb3c6513dbd87fc2c1df
srcBranch: refs/heads/master
selectedRef: 8ed6808d0ef4b950182ffb3c6513dbd87fc2c1df
Using auth scheme: OAuth
Repo: http://zeustfs02:8080/tfs/DefaultCollection/WMS%20Git/_git/DeVries.WMS.Analytics
Repo path: /Users/Shared/BuildAgents/Agent1/_work/build/8f606dfb41c4926101422d0198a9c955169bafb520042a138beeaec27c5ce25f/repo
Using ref: 8ed6808d0ef4b950182ffb3c6513dbd87fc2c1df
repo location:http://zeustfs02:8080/tfs/DefaultCollection/WMS%20Git/_git/DeVries.WMS.Analytics
cwd: /Users/Shared/BuildAgents/Agent1/_work/build/8f606dfb41c4926101422d0198a9c955169bafb520042a138beeaec27c5ce25f
running: git --version
git version 2.3.2 (Apple Git-55)

+++++++Git clone http://zeustfs02:8080/tfs/DefaultCollection/WMS%20Git/_git/DeVries.WMS.Analytics 
Cloning into folder: repo
running: git clone --progress http://zeustfs02:8080/tfs/DefaultCollection/WMS%20Git/_git/DeVries.WMS.Analytics repo
Cloning into 'repo'...
fatal: Authentication failed for 'http://zeustfs02:8080/tfs/DefaultCollection/WMS%20Git/_git/DeVries.WMS.Analytics/'

Seems that it is unable to authenticate to my TFS server. Is this unsupported?

Hi, we're trying to use VSO for xcode builds, where we are using a tool called OCJunit2JUnit that generates JUnit test reports (XML) from xcode builds.
However, there are two problems with the vso-test-publisher. First of all, it doesn't handle the <testsuites>-tag, which is in the JUnit specification. We've created a way around that though.

The problem we're facing now, are that we are getting 400 from the API when it tries to publish the test results. (Still using the built in JUnit test reporter)
I logged the payload, but I can't find any specification from the API on the keys that are mandatory.
Here are a gist of what we are sending:

{ state: 'Completed',
    computerName: '',
    resolutionState: null,
    testCasePriority: 1,
    failureType: null,
    automatedTestName: 'testDecompressData_WhenEmptyData_SomeDataIsReturned',
    automatedTestStorage: 'EncodingUtilsTests',
    automatedTestType: 'JUnit',
    automatedTestTypeId: null,
    automatedTestId: null,
    area: null,
    owner: 'Martin Jensen',
    runBy: 'Martin Jensen',
    testCaseTitle: 'testDecompressData_WhenEmptyData_SomeDataIsReturned',
    revision: 0,
    dataRowCount: 0,
    testCaseRevision: 0,
    outcome: 'Passed',
    errorMessage: '',
    durationInMs: 0.4 },
  { state: 'Completed',
    computerName: '',
    resolutionState: null,
    testCasePriority: 1,
    failureType: null,
    automatedTestName: 'testDecompressData_WhenNilData_NilAndErrorIsReturned',
    automatedTestStorage: 'EncodingUtilsTests',
    automatedTestType: 'JUnit',
    automatedTestTypeId: null,
    automatedTestId: null,
    area: null,
    owner: 'Martin Jensen',
    runBy: 'Martin Jensen',
    testCaseTitle: 'testDecompressData_WhenNilData_NilAndErrorIsReturned',
    revision: 0,
    dataRowCount: 0,
    testCaseRevision: 0,
    outcome: 'Passed',
    errorMessage: '',
    durationInMs: 0.077 },
  { state: 'Completed',
    computerName: '',
    resolutionState: null,
    testCasePriority: 1,
    failureType: null,
    automatedTestName: 'testEncodeDataWithBase64_WhenDataInitializedEmpty_ReturnsEmptyString',
    automatedTestStorage: 'EncodingUtilsTests',
    automatedTestType: 'JUnit',
    automatedTestTypeId: null,
    automatedTestId: null,
    area: null,
    owner: 'Martin Jensen',
    runBy: 'Martin Jensen',
    testCaseTitle: 'testEncodeDataWithBase64_WhenDataInitializedEmpty_ReturnsEmptyString',
    revision: 0,
    dataRowCount: 0,
    testCaseRevision: 0,
    outcome: 'Passed',
    errorMessage: '',
    durationInMs: 0.075 },
  { state: 'Completed',
    computerName: '',
    resolutionState: null,
    testCasePriority: 1,
    failureType: null,
    automatedTestName: 'testEncodeDataWithBase64_WhenNilData_ReturnsNil',
    automatedTestStorage: 'EncodingUtilsTests',
    automatedTestType: 'JUnit',
    automatedTestTypeId: null,
    automatedTestId: null,
    area: null,
    owner: 'Martin Jensen',
    runBy: 'Martin Jensen',
    testCaseTitle: 'testEncodeDataWithBase64_WhenNilData_ReturnsNil',
    revision: 0,
    dataRowCount: 0,
    testCaseRevision: 0,
    outcome: 'Passed',
    errorMessage: '',
    durationInMs: 0.063 },
  { state: 'Completed',
    computerName: '',
    resolutionState: null,
    testCasePriority: 1,
    failureType: null,
    automatedTestName: 'testEncodeDataWithBase64_WhenNonEmptyData_ReturnsEncodedString',
    automatedTestStorage: 'EncodingUtilsTests',
    automatedTestType: 'JUnit',
    automatedTestTypeId: null,
    automatedTestId: null,
    area: null,
    owner: 'Martin Jensen',
    runBy: 'Martin Jensen',
    testCaseTitle: 'testEncodeDataWithBase64_WhenNonEmptyData_ReturnsEncodedString',
    revision: 0,
    dataRowCount: 0,
    testCaseRevision: 0,
    outcome: 'Passed',
    errorMessage: '',
    durationInMs: 0.081 },

Any ideas what are causing these 400s?

Please let me know what I'm missing to enable the TF client to get the source down to our build server.
Below is the output I get using the TFSVC support on master at the present time.

Preparing tasks

Running prepareWorkspace

preparing Workspace
cwd: /home/ssdrive/agent1/work/build/1d6ffba4b3cd8b528ee7a99e3bf162a879774a1546f914315526215f77afdc11
using source provider: tfsversioncontrol
loading: /home/ssdrive/agent1/agent/scm/tfsversioncontrol
Using auth scheme: OAuth
workspace name: ws_1d6ffba4
getting code
Creating workspace ws_1d6ffba4
/home/ssdrive/TEE-CLC-14.0.1/tf arg: workspace
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "-new"
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "-permission:Private"
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "-location:local"
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "ws_1d6ffba4"
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "-collection:http://ets-tfs:8080/tfs/DriveMateCollection/"
/home/ssdrive/TEE-CLC-14.0.1/tf arg: "-login:OAuth,*****************"
exec tool: /home/ssdrive/TEE-CLC-14.0.1/tf
Arguments:
workspace
-new
-permission:Private
-location:local
ws_1d6ffba4
-collection:http://ets-tfs:8080/tfs/DriveMateCollection/
-login:OAuth,_*************
An error occurred: Access denied connecting to TFS server http://ets-tfs:8080/ (authenticating as OAuth)
rc:100
success:false
/home/ssdrive/TEE-CLC-14.0.1/tf failed with return code: 100

I have VSO set up to automatically build my pull requests. Sometimes this will fail with "reference is not a tree", even though the same branch will build fine when triggered with it's real branch name and not the pull request's merge commit "branch".

E.g.:

2015-08-24T12:22:59.192Z: preparing Workspace
 2015-08-24T12:22:59.193Z: cwd: /usr/share/vsoagent/_work/build/2fd9ef7606b6283b55c47697acc7639b86e0ee56016b888311aba2a7c0050d9f
 2015-08-24T12:22:59.193Z: using source provider: tfsgit
 2015-08-24T12:22:59.193Z: loading: /usr/share/vsoagent/agent/scm/tfsgit
 2015-08-24T12:22:59.223Z: Using auth scheme: OAuth
 2015-08-24T12:22:59.223Z: running clean
 2015-08-24T12:22:59.246Z: HEAD is now at a822afa UI tweaks and server details.
 2015-08-24T12:22:59.246Z: 
 2015-08-24T12:22:59.247Z: getting code
 2015-08-24T12:22:59.247Z: https://foo.visualstudio.com/DefaultCollection/_git/Sandbox.git
 2015-08-24T12:22:59.249Z: srcVersion: 944ebab1163f60f01ab8954f0bf9e06ed9559444
 2015-08-24T12:22:59.249Z: srcBranch: refs/pull/13/merge
 2015-08-24T12:22:59.249Z: Using ref: 944ebab1163f60f01ab8954f0bf9e06ed9559444
 2015-08-24T12:22:59.821Z: fatal: reference is not a tree: 944ebab1163f60f01ab8954f0bf9e06ed9559444
 2015-08-24T12:22:59.821Z: 
 ##[Error] 2015-08-24T12:22:59.824Z: /usr/bin/git failed with return code: 128

The 944eba ref is the autogenerated "Merge pull request 13 from apiretry into master" commit.

Thanks for the clarification, now the agent started.

But now, I get this:

Preparing tasks

Running prepareWorkspace

preparing Workspace
cwd: /home/XXXXXXX/myagent/_work/build/573660dfef5a6fd833ad7433f6934387b698f979dd7311701c49868c971c8e55

[Error] Unsupported repository type:TfsVersionControl

Please be so kind and tell me, whats going wrong.

Regards
Thomas

I've setup the xplat agent on a Mac Mini and ran it as a service. Now if I run ps aux I see the following:

Administrator   22836   0.0  0.6  3050388  23788   ??  Ss   10:30AM   0:00.19 /usr/local/bin/node /Users/Shared/BuildAgents/Agent1/agent/host.js -u ZEUSTFSService -p somerandompassword

Obviously somerandompassword isn't the actual password for that account, but the point is that what I'm actually seeing on the screen is the correct password in clear text. This looks to me as a severe security problem since as long as I can access the machine I can see the password the agent is using to connect to TFS.

Every couple of days I see this error. Happens on both OS X and Linux.

The job has been abandoned because agent tb-lnx2 did not renew the lock.
Ensure agent is running, not sleeping, and has not lost communication
with the service.

I am using the new build engine in TFS2015 to build my Microsoft Dynamics NAV database (using powershell) and want to publish result of the NAV Tests using NUnit file format. When I generate the NUnit file with the results of 15000 tests, the :publish test results" step takes only 2500 tests and than it fail.

Part from the log:

2015-09-14T18:52:27.4989056Z Starting task: Publish Test Results TEST-nav*.xml
2015-09-14T18:52:27.5770438Z Executing the powershell script: C:\agent\tasks\PublishTestResults\1.0.5\PublishTestResults.ps1
2015-09-14T18:52:28.1239267Z Publishing Test Results...
2015-09-14T18:52:30.0943647Z Test results remaining: 15507
2015-09-14T18:52:30.8287571Z Test results remaining: 15007
2015-09-14T18:52:31.4061370Z Test results remaining: 14507
2015-09-14T18:52:32.0165126Z Test results remaining: 14007
2015-09-14T18:52:32.5076258Z Test results remaining: 13507
2015-09-14T18:52:33.1595380Z Test results remaining: 13007
2015-09-14T18:52:33.5234259Z ##[warning]Failed to publish test results: One or more errors occurred.
2015-09-14T18:52:33.5703029Z Finishing task: PublishTestResults

If I divided the result into more files (max 2000 tests per result file), it again import only first 2500 tests (first file import ok, second is leaved in state "Running"). When publishing less than 2500 tests, all is ok.

Is there some hard limit, how much test results could be attached to the build? 2500 is too low for big projects. Or is it some problem with NUnit test result import?

Where I can find description e.g. for VSTest file format? I need to generate the file by own tools...

Thanks for any help

Kamil Sacek

MVP for Microsoft Dynamics NAV since 2004

Hello.
There is a nodejs library which allows to connect to server side using ntlm auth https://github.com/SamDecrock/node-http-ntlm

We have the issue related to linux agent connecting to TFS 2015 on prem and we have to change auth mode in IIS http://blogs.teamfoundation.co.za/2015/05/installing-and-configuring-tfs-2015-on.html

But this is not good from security perspective.

Is it possible to add NTLM support to Agent?

Thanks!

After a fresh git clone, a plain gulp invocation does not build an installable npm package.

When an xplat agent is registered against an account that does not have enough private agent slots purchased, it simply shows a 400 Bad Request error and does not log out the exception message.

/Users/ticino/Desktop/joao/vsobuild/node_modules/vso-task-lib/lib/toolrunner.js:48
for (var i = 0; i < args.length; i++) {
^
TypeError: Cannot read property 'length' of null
at ToolRunner._argStringToArray (/Users/ticino/Desktop/joao/vsobuild/node_modules/vso-task-lib/lib/toolrunner.js:48:33)
at ToolRunner.arg (/Users/ticino/Desktop/joao/vsobuild/node_modules/vso-task-lib/lib/toolrunner.js:60:47)
at Object.<anonymous> (/Users/ticino/Desktop/joao/vsobuild/_work/tasks/ShellScript/1.0.9/shellscript2.js:9:6)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
at node.js:814:3
Return code: 1

It happens when executing a shell script in a build definition.

Hallo, how could i ignore this error? bash script run's, but vsoagent tells me orange not green!

Running ShellScript

running: bash /xxxxx/copynas.bash anynodemon-1.15.1 > out.log 2> /dev/null

[Error] Domain=[YYY] OS=[Unix] Server=[Samba 3.6.24]

[Error]

[Error] putting file zzzzzzzzzzz-1.15.1-debian8-x64-release.deb as \cds\anynode\debian\zzzzzzzzzzz-1.15.1-debian8-x64-release.deb (12778.9 kb/s) (average 12778.9 kb/s)

[Error]

[Error] Failed with Error Output

For the time being Linux.js service installer is absent form the svcinstall project, which makes it impossible to install a service on Linux.
If there's anything (pre-alpha :)) ) available, would be glad to test it.

I would like to connect to a TFS API from a build task. vso-node-api provides a method for the call I want to make and I can make the call if I explicitly require vso-node-api in my task and pass it a new authentication handler, with username and password for the TFS server.

There are clearly better way to do this but I can't figure out the best way. I can see that the PublishBuildArtifacts task uses "tl.command("artifact.upload", data, "Uploading artifact");" but I can't find a reference for how 'commands' line up with the WebApis.

Alternatively, is there a way to connect to use a token from the vso-agent itself to get the WebApi or connection to the TFS Server?

ps. the call from vso-node-api I am making is "buildApi.getBuildCommits(project, build, callback)"

Any direction or help would be wonderful.

The build on my vsoagent (on Linux) fails due to a tf error while getting the sources:

/home/lnxbld/myagent/_work/build/49a59345fbf5ecea51a2a59c98b55ff13a318a565bf31a0ea33ae974b6180524/repo/$/Perception/Main/Embedded/Plaza/Projects/Vx_Genesis_Minimum_DigMod1M:
Getting .tfignore
Getting Genesis_Minimum_DigMod1M.wpj
Getting linkSyms.c
An error occurred: com.microsoft.tfs.core.exceptions.TECoreException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Mmmh: Linux supports long pathnames, Windows doesn't....
Why use a 64-char hash as path element?
By-the-way: Linux does not like the $ within the path.

Am attempting to put xplat agent on a mac mini running OS X Yosemite (Server) against an on-prem install of TFS 2015 (release, no RC or RTM).

$ node -v && npm -v
v0.12.7
2.11.3

I have basic auth turned on for the TFS site to which I am connecting.
The mac mini is not joined to the AD domain that is hosting TFS - but TFS, DB, and SharePoint servers involved are.

Here is a redacted transcript of my attempt to configure the agent on first run:

$ node agent/vsoagent
Enter alternate username > tfsBuild
Enter alternate password >
Enter server url > http://myTFS:8080/tfs
Enter agent name (enter sets OSXBox) >
Enter agent pool name (enter sets default) >
Error starting the agent
Failed Request: Unauthorized(401) - http://myTFS:8080/tfs/_apis/connectionData

Here is the funny thing. If I fire up Safari (or even Edge on my Win10 workstation) and plunk the above "unauthorized" URL into the address bar, I will get the prompt for login. If I then enter the exact same service account credentials used above, I get back a nice json response...no 401 error. So, clearly, the basic auth is working and the service account has all the permissions it needs to get past this point. Any thoughts on what is special about the agent "builder" ?

Experiments I have already done:

1. Use my own (Site Collection and everything else admin) creds - same behavior.
2. Turn off ALL other forms of authentication on the IIS server for TFS and restart the server - same behavior.
3. Fired up Xcode the the mac in question, connected to TFS, pulled main from an app and built it from within Xcode using the tfsBuild credentials for connecting to TFS - success.
4. Pitched ALL of the cached passwords in the mac keychain related to my TFS server - no change.

When running a build, my agent periodically logs errors about failed requests, e.g:

build-agent-1 | 2015-08-18T20:39:16.868117245Z 2015-08-18T20:39:16.865Z: Running job: Build
build-agent-1 | 2015-08-18T20:40:19.770424389Z ##[Error] 2015-08-18T20:40:19.770Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:40:34.511671612Z ##[Error] 2015-08-18T20:40:34.511Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:40:43.435022329Z ##[Error] 2015-08-18T20:40:43.434Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:41:45.495968966Z ##[Error] 2015-08-18T20:41:45.495Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:42:12.674945165Z ##[Error] 2015-08-18T20:42:12.674Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:42:58.950493698Z ##[Error] 2015-08-18T20:42:58.950Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:43:48.514867858Z ##[Error] 2015-08-18T20:43:48.514Z: Failed Request: Internal Server Error(500) - https://foo.visualstudio.com/DefaultCollection/26433ada-b2c7-4446-b81d-4f8810b6d296/_apis/distributedtask/hubs/Build/plans/a1653ef3-5c98-4de5-a395-f06872979a3b/timelines/904223cb-cacc-418a-b9d0-d700484c0fc9/records/a046120d-bd95-47ee-a0c7-79dd5caf66c0/feed
build-agent-1 | 2015-08-18T20:43:51.715116681Z 2015-08-18T20:43:51.714Z: Job Completed: Build
build-agent-1 | 2015-08-18T20:43:53.341348259Z 2015-08-18T20:43:53.341Z: Job Finished: Build

The build itself run fine though and finishes without issues.

If I create a build agent at /agent, it will use a child of that directory as a working directory.

I want to use a separate directory as a working directory, for performance reasons. I edited the .agent file and changed it to /work.

Build steps now fail with

##[Error] 2015-07-30T22:27:10.941Z: module.js:338
##[Error] 2015-07-30T22:27:10.943Z:     throw err;
##[Error] 2015-07-30T22:27:10.943Z:           ^
##[Error] 2015-07-30T22:27:10.943Z: Error: Cannot find module 'vso-task-lib'
##[Error] 2015-07-30T22:27:10.943Z:     at Function.Module._resolveFilename (module.js:336:15)
##[Error] 2015-07-30T22:27:10.943Z:     at Function.Module._load (module.js:278:25)
##[Error] 2015-07-30T22:27:10.943Z:     at Module.require (module.js:365:17)
##[Error] 2015-07-30T22:27:10.943Z:     at require (module.js:384:17)
##[Error] 2015-07-30T22:27:10.943Z:     at Object.<anonymous> (/work/tasks/NpmInstall/0.1.2/npminstall.js:2:10)
##[Error] 2015-07-30T22:27:10.943Z:     at Module._compile (module.js:460:26)
##[Error] 2015-07-30T22:27:10.943Z:     at Object.Module._extensions..js (module.js:478:10)
##[Error] 2015-07-30T22:27:10.943Z:     at Module.load (module.js:355:32)
##[Error] 2015-07-30T22:27:10.943Z:     at Function.Module._load (module.js:310:12)
##[Error] 2015-07-30T22:27:10.943Z:     at Function.Module.runMain (module.js:501:10)
##[Error] 2015-07-30T22:27:10.943Z: 
##[Error] 2015-07-30T22:27:11.811Z: Return code: 1

Is this not supported?

I read your instruction and I had created two accounts before.

Did you have any suggestion?

Regards
Thomas

Question as per title - I'd like to use an azure VM as my build agent for VSO! 👍

Happens once in a blue moon. Logs zip is empty. If you have access to our project, here are a few of those.

existsSync is deprecated, and it seems the repoDirName passed in here has some environment variables that aren't being expanded properly or something along those lines. Should probably switch to accessSync() and make sure to not take environment variables for granted as node interacts with file system directly.

2015-06-19T18:56:24.1590665Z ##[error]Failed to make directory 'C:/users/spcusage/Build': Cannot create a file when that file already exists.

if (!fs.existsSync (repoDirName)) {
    ctx.info('Creating repo dir: ' + repoDirName)
    shell.mkdir('-p', repoDirName);
    …

I'm following this article here and I'm getting an issue with this which suggest the build conditions are no longer valid for VSO in order to detect it's running on VSO.

http://blogs.msdn.com/b/davidhardin/archive/2013/01/18/building-and-packaging-virtual-applications-within-azure-projects.aspx

Is it possible to detect that a build is running in VSO in a way I can modify the work in the article to make sure the logic works ?

hi there,

I get the following err when I install agent as service. could you help on this?
@ubuntuAgent:~/ubuntuAgent/agent$ ./svc.sh install
serviceName: vsoagent.vsoagent.192.ubuntuagent

module.js:340
throw err;
^
Error: Cannot find module './installers/Linux'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at new SvcInstall (/home/haxu/ubuntuAgent/node_modules/svcinstall/lib/svcinstall.js:13:20)
at Object. (/home/haxu/ubuntuAgent/agent/service.js:32:18)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)

Regards,
Hao Xu

I followed the steps to build this xplat agent. I am getting the following error and hence not able to proceed further. Is this a known issue. Let me know if there is any workaround for this?

Error log:

[09:23:51] Using gulpfile ~/agents/vso-agent/gulpfile.js
[09:23:51] Starting 'clean'...
[09:23:51] Finished 'clean' after 6.64 ms
[09:23:51] Starting 'copy'...
[09:23:51] Finished 'copy' after 30 ms
[09:23:51] Starting 'build'...
[09:23:51] Compiling TypeScript files using tsc version 1.6.2
[09:23:55] [tsc] > /home/azureuser/agents/vso-agent/src/agent/context.ts(8,21): error TS2307: Cannot find module 'feedback'.
[09:23:55] [tsc] > /home/azureuser/agents/vso-agent/src/agent/filecontainerhelper.ts(6,23): error TS2307: Cannot find module 'context'.
[09:23:55] [tsc] > /home/azureuser/agents/vso-agent/src/agent/vsoagent.ts(48,9): error TS2345: Argument of type '{ env: any; execArgv: undefined[]; }' is not assignable to parameter of type '{ cwd?: string; env?: any; encoding?: string; }'.
[09:23:55] [tsc] > Object literal may only specify known properties, and 'execArgv' does not exist in type '{ cwd?: string; env?: any; encoding?: string; }'.
[09:23:55] Failed to compile TypeScript: Error: tsc command has exited with code:2

events.js:72
throw er; // Unhandled 'error' event
^
Error: Failed to compile: tsc command has exited with code:2

registration of build agent fails with HTTP/1.1 400 Bad Request returned from proxy.
Not sure if request should include :443 for https requests.
currently request looks like this
GET https://apps-munichre.visualstudio.com/_apis/connectionData HTTP/1.1\r\n

but should be
CONNECT https://apps-munichre.visualstudio.com:443 HTTP/1.1\r\n
and doing some SLL handshake.

I have now updated one of my agents to 0.2.28 and a previously transient issue now seems to be permanent:
As part of my build definition, I am calling a shell script. This script relies on a parameter being passed down so it can then build a path where this parameter is part of the path. In my case, the parameter value contains whitespace.
Previously, most of the time the parameter got passed down like this (as can be seen in the logs)
2015-08-27T09:22:02.228Z: [command]/bin/bash /script.sh 'name parameter'

Now with 0.2.28 it seems that it gets always passed like this:
2015-08-27T09:22:02.228Z: [command]/bin/bash /script.sh name parameter

The quotes are missing, so inside the script $1 is now 'name' instead of 'name parameter', which causes significant irritation when constructing paths ;-)
This problem sometimes occured also with previous versions, but then canceling the build and queuing it again always helped.

I am passing down the parameter as $(nameparameter) in the build definition, having it defined as name parameter (without quotes) in a variable called nameparameter and receiving it in the script as $1.
Am I doing something wrong there?