So I think what I want is the opposite of this post: VSTS NuGet restore fails (proxy?)
We have an on-prem machine running a VSTS agent for builds. That machine has the http_proxy variable set so the agent process can talk to VSTS in the cloud.
I'm then trying to use the built in nuget task to do a nuget restore, but the feed I want to access is on an on-prem artifactory instance. To access this feed nuget needs to not use the proxy settings that the agent does (we have the 'bypass proxy for local addresses' option checked in Internet Options).
However, when I run the nuget task I see the following in my build log, it seems to set the nuget proxy to the agent proxy:
2017-10-17T14:02:14.4961204Z ##[debug]agent.proxyurl=http://X.X.X.X:8080
2017-10-17T14:02:14.4961204Z ##[debug]agent.proxyusername=undefined
2017-10-17T14:02:14.6992455Z ##[debug]agent.proxypassword=undefined
2017-10-17T14:02:14.7773706Z ##[debug]Adding environment variable for NuGet proxy: http://X.X.X.X:8080/
2017-10-17T14:02:14.7773706Z ##[debug]exec tool: C:\vsts-agent\_work\_tool\NuGet\4.0.0\x64\nuget.exe
(The 2 sets of X.X.X.X are identical in the real log)
I've tried setting a process variable of http_proxy="" and adding this line to my nuget.config <add key="http_proxy" value="" />, but it makes no difference.
Is there a way to run the nuget task without picking up the agent proxy?
If I just run nuget manually from a command line task in VSTS, it all works as expected.
The VSTS agent should be able to pick up the proxy exclusion settings from a .proxybypass file:
echo http://local.nuget.server >> .proxybypass
I'm not sure if the Nuget task will pick this up (it looks like it doesn't yet), but at least that's how you can tell the agent to ignore certain hosts. This was added in a very recent agent version, so you may need to upgrade your agent.
I'm guessing that if you use my VSTS Set Variable Task to temporarily set the value of agent.proxyurl to an empty string and restore it after calling the nuget task, that it should work for now.
PS the new configuration no longer uses the environment variable to set the proxy, the new default is to put that in a .proxy file in the agent root as well.
Related
I'd like to specify an environment variable, so I could verify whether it's a stage/production/development environment (either ASPNETCORE_Environment or a custom one). Does Octopus do it by default or do I have to set it up manually?
During the deployment the variable #{Octopus.Environment.Name} will resolve to the name of the Octopus Environment you are deploying to. Following the image below:
If you deploy to environment (1), #{Octopus.Environment.Name} will resolve to Development.
(2) -> Staging
(3) -> Test
OctopusEnvironments
But this variable will only be available within the context of the Octopus deployment. If you are looking to set something more persistent you're gonna have to Powershell your way through it using a script step in your deployment process with the below:
[System.Environment]::SetEnvironmentVariable("MyPassword","P4$$w0rd123", [System.EnvironmentVariableTarget]::Machine)
More info about the above command in this blog post
Octopus has a set of system variables. The one you asking about is:
#{Octopus.Environment.Name}
After being unable to clone a private github repo inside a TeamCity command line build step, even when making sure the ssh-agent was running with the correct key, I found this answer: Team City Git "Host key verification failed"
How to do what this answer suggests? How do I run my TeamCity job under a different account than "System"?
If you are running TeamCity agents as a Service on Windows, then go to Server Manager -> Configuration -> Services. Find your TeamCity agent there, right click to see Properties, and go to Log On tab, where you can change default Local System account to anything you want:
We have a team city server installed on a server named pluto. It's a Windows Server machine. There is a build agent on Pluto used to do VS related builds.
We have another build agent connected to this TeamCity server instance called YOSX, a build agent that is running on Mac mini Yosemite.
I've created a build to build a solution on YOSX with rake script. As a VCS Root Checkout option I've selected Automatically on Agent.
Ok, I am expecting that perforce p4 app will be called by TC agent on YOSX machine, but when I run a build, I get an error:
Collecting changes in 1 VCS root (2s)
[Collecting changes in 1 VCS root] VCS Root details
[VCS Root details] "eyeleo.mac.dev" {instance id=98, parent internal id=31, parent id=Desktop_EyeLeoMac_EyeleoMacDev, description: "perforce: p4.radacode.net:1666: perforce stream: '//EyeLeo.Mac/dev'"}
Failed to collect changes, error: Unable to find P4 command-line client at path '//Applications/p4' on pluto for user PLUTO$
Why is trying to checkout on pluto with user $PLUTO while I specifically set it to checkout on build agent's machine.
P.S. Yes, I've set the build requirements so that the build configuration in question is only compatible with YOSX build agent.
The server does not try to checkout the sources, but it still collects the information about changelists: modified files, commit messages etc.
This information will be used to display diffs, relevant issues, to track possible causes of test failures.
Please, install p4 on the PLUTO as well.
In my case p4 file on YOSX (build agent machine) was in PATH, but didn't have execute permissions. chmod +x p4 solved the puzzle.
I've been happily working with a TeamCity Build server for a while now, but all of a sudden things went wrong...
It seems the build agent no longer has anything in it's path. So, for example, if my build script (I use NANT) calls xcopy to copy files, this has suddenly started failing because xcopy can not be found - so the build will fail unless I change it to c:\windows\system32\xcopy.
I can manually browse to the build agent folder and run the nant script from there, and it all works (because the path is set correctly).
I've not upgraded TeamCity, so I'm baffled as to why this could have borked. I don't override anything in the environment parameters of the builds in TeamCity. I've not changed anything in the build settings either. The only thing I've done to this PC that contains the build agent is to install the RC of Visual Studio 2012.
Any ideas?
EDIT
Further investigation - I've found the agent settings in TeamCity - in there the environment variable called "path" is just set to C:\Program Files (x86)\Nmap (Recently installed). This is odd and quite possibly the cause of the issue. I just need to work out how to make TeamCity revert to the "real" path.
Figured it out - this may well be useful to someone else...
When I installed Nmap recently, it added a new "User Variable" for my account, which it called "path" and set to C:\Program Files (x86)\Nmap. This overrides the "System Variable" called path, and was causing all the havoc. Removed the user variable, and all working.
i'm using teamcity 5.1.5.. trying to build an MSBuild project with an AfterDeploy target which calls a java function..
i get the following error: 'java' is not recognized as an internal or external command
I've tested the java command on the build server and the agent servers and they all run the command..but it seems it fails when running through teamcity.
any ideas?
i've checked the build agent env vars and they seem correctly setup:
Environment variables defined in the
agent configuration file
JAVA_HOME C:\Program
Files\Java\jdk1.6.0_21
JDK_16 C:\Program
Files\Java\jdk1.6.0_21
TEAMCITY_JRE C:\TeamCity\jre
the only thing i notice is that the java.exe are actually in the bin folders here not the root folder.
Build Agent runs from the SYSTEM account by default. SYSTEM account environment variables differ from your normal account which you've used for testing. I suspect that java.exe is not in PATH for the SYSTEM account. Either adjust PATH by adding JDK_HOME\bin to it or configure the Agent service to run from a different account.
Remember you need to restart the build agent service before changes to PATH will take effect.
You can also run your build agent service under a local administrator account (this might be preferred for several reasons), but there is a bug in TeamCity where only the USER environment variables (for example the PATH) are used by the agent, not SYSTEM+USER as normal in Windows.
So if you have a path defined for the user, the system paths are unknown by the agent!
The workaround right now (verified) is to add the user path to the system path and delete the user path (under System/Avanced System Settings/Environment Variables).
Bug here and a (not solved as of 2012-01-29):
http://devnet.jetbrains.net/thread/276957
We run the agent under a normal user account. Java can be found in an interactive session, but not in the TeamCity builds. I had to add the java bin directory to the PATH variable of the user. After a log off/log in, the java command could then be found by the TeamCity builds.