You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am trying to use vstest.console, because I need to use the runsetting parameters. I am using the command prompt, because I am needing to call the runsetting file to grab the parameter, instead of getting the deprecated command that I can't think of right now.
Here is the command line script,
vstest.console.exe cit-xxx-automatedtesting.dll /settings:e:\development\cit\cit-xxx-automatedtesting\code\dev-default.runsettings /TestAdapterPath:e:\development\cit\cit-xxx-automatedtesting\packages\mstest.testadapter.1.4.0\build\_common (Executable is powershell)
This works on the server from any directory, because it is in the path. But when running from bamboo, it cannot find vstest.console. We are using the system user, not the localadminuser. Do we need to use the local admin user (and why?), or what can I be missing? Thanks for the help.
Hi @Greg Polito
I'm afraid that your PATH variable does not have the same value when Bamboo is running as LocalSystem account. You could check this through:
You need to make sure the PATH variable will have the needed reference to find the program you are trying to use.
⚠️ Please keep in mind that you need to restart Windows when a change in system variable is performed and you want it to show up for in the service environment.
Reference: Changes that you make to environment variables do not affect services that run under the Local System account until you restart Windows
We do recommend that Bamboo is run as a local admin account (Running Bamboo as a Windows service as the local user) to make sure apps running from it can have access to the user interface. Apps like Selenium have trouble to work when running with a LocalSystem account.
Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop because any other application that is running on the interactive desktop can interact with this window. This exposes the service to any application that a logged-on user executes. Also, services that are running as LocalSystem should not access the interactive desktop by calling the OpenWindowStation or GetThreadDesktop function.
I hope that answers your question.