Updated pathtoCustomTestAdapters type to filePath #222
Conversation
|
It should be noted that I made this change on our on premise installation of Team Foundation Server 2015 RC several weeks ago and it 1) solved the relative path issue we were having, and 2) caused no other issues that we can detect. |
|
@Quantumplation can you please sign the contribution agreement here https://cla.microsoft.com/ thanks. |
|
Hi! I'd love to! Just to be sure, I checked with my employer, and they've informed me that (at least for now, while we rethink the existing policy), I should indicate the second option:
However, I'm concerned about the lack of granularity here. is there a separate CLA for each project, or can I change my CLA status after I've signed it, once we revise our policy? Should I create a separate github account for pull requests that result from work done for my employer and reopen this pull request under that account, and this account for any contributions to Microsoft projects I make outside of work? Regards, |
|
Hi Pi, I am not 100% sure how that works. Let me check with and I will find out. From: Pi Lanningham [mailto:notifications@github.com] Hi! I'd love to! Just to be sure, I checked with my employer, and they've informed me that (at least for now, while we rethink the existing policy), I should indicate the second option: I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or However, I'm concerned about the lack of granularity here. is there a separate CLA for each project, or can I change my CLA status after I've signed it, once we revise our policy? Should I create a separate github account for pull requests that result from work done for my employer and reopen this pull request under that account, and this account for any contributions to Microsoft projects I make outside of work? Regards, — |
|
CLA Can you help here? From: Pi Lanningham [mailto:notifications@github.com] Hi! I'd love to! Just to be sure, I checked with my employer, and they've informed me that (at least for now, while we rethink the existing policy), I should indicate the second option: I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or However, I'm concerned about the lack of granularity here. is there a separate CLA for each project, or can I change my CLA status after I've signed it, once we revise our policy? Should I create a separate github account for pull requests that result from work done for my employer and reopen this pull request under that account, and this account for any contributions to Microsoft projects I make outside of work? Regards, — |
|
There is one and only one CLA that needs to be signed by a contributor for contributing to any of Microsoft sponsored projects. GitHub users have the option to bind multiple e-mail accounts to GitHub Accounts. When they commit they may indicate a specific e-mail address. So if a user is making a personal contribution, user can use a personal mail bound to a GitHub account. Similarly, if a user is making a contribution on behalf of the user’s employer, user can use a corporate mail bound to a GitHub account. git commit --author= [see http://git-scm.com/docs/git-commit] |
|
@Quantumplation, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
|
I signed it with my work email. I'll amend the commit so that it has that email for the author instead. |
This field determines how the Build.vNext runtime treats the user entered value when passing it to a PowerShell script. As a string, it is passed through unchanged. As a filePath, Build.vNext corrects relative paths to be absolute paths in your solution directory. Thus, when entering a relative path (as is often common, ex. when the adapters are added as nuget packages, i.e. XUnit), as a String, it operates relative to the location of the PowerShell script! This is nowhere near where your solution files are stored, and so it can't find your custom test adapters. However, a field with type filePath gets the solution directory prepended to it first (if it's a relative path). Thus, it is possible to specify relative paths and have them look in the solution directory, rather than deep in the TFS internals.
|
Done, though I don't think you can see the difference on github: |
|
Any update on getting this? Anything else I need to do? |
|
No, thanks Pi. We will pull this set of changes in along with our next set of updates. |
|
Pi, Thanks, |
…osoft#222) - Added wrapper to wrap additional arguments to prevent errors when passing in unwrapped additional arguments that are not compatible with the executed command.
This field determines how the Build.vNext runtime treats the user entered value when passing it to a PowerShell script. As a string, it is passed through unchanged. As a filePath, Build.vNext corrects relative paths to be absolute paths in your solution directory.
Thus, when entering a relative path (as is often common, ex. when the adapters are added as nuget packages, i.e. XUnit), as a String, it operates relative to the location of the PowerShell script! This is nowhere near where your solution files are stored, and so it can't find your custom test adapters.
However, a field with type filePath gets the solution directory prepended to it first (if it's a relative path). Thus, it is possible to specify relative paths and have them look in the solution directory, rather than deep in the TFS internals.