I am currently setting up continuous integration using Visual Studio Team Services with onsite build agents, but I am having issues with my company's proxy.
I have tried adding the .proxy file but my company's proxy is still blocking it (it is a very old proxy).
Speaking to my infrastructure guys they can bypass the proxy but need all the urls that the build agent calls.
Unfortunately I can not find a list online of all the urls that it requires, I know it needs the following:
https://xxxxxxxxx.visualstudio.com
https://xxxxxxxxx.vssps.visualstudio.com
Does anyone know all the other urls that an onsite build agent calls?
It's hard to tell, the agent itself uses a number of URI's connect, the ones I know of are these at least:
account.visualstudio.com
account.vsrm.visualstudio.com
account.vssps.visualstudio.com
app.vssps.visualstudio.com
But then there are a number of tasks that need download access as well, e.g.
npm needs access to www.npmjs.com
Sonar Qube needs to download the sonar runner
NuGet needs access to www.nuget.org to restore packages
...
Then depending on which extensions you use, you may need additional ones
My Snyk task needs access to snyk.io for example
The easiest way to find them all is to setup a build agent outside of your company network and monitor the traffic with fiddler. To get an answer from the source I recommend to post an issue on the vsts-agent github repo.
Related
This is a not related to code fix, but a general approach for test automation.
I have a test automation written in javascript which runs perfectly on my machine as well as my local jenkins.
Now, i want to use my company's server(centOS) and jenkins so that it is accessible to everyone in my organization.
Issue: nodejs version in company's server need update to run my automation, but server team wont do it since they are not sure if any other functionality used be other teams may start to break because of the upgrade.
Have you faced this situation. Do you have different servers for core code and automation scripts. Please suggest.
This is a complex situation that really depends on many variables. I would recommend using an agent that contains the proper version of Nodejs. With this solution you can leave the current build server how it is but you can also use the exact version of node you need. This will require an extra server/VM with the Jenkins slave software but this will remove the need to change the master server.
The solution my company went with is using Jenkins 2.x with Declarative pipelines and ephemeral Docker containers for builds. This allows you to use any Docker image such as the official Node image. You can pin a version and build it with that. With this there is no need to worry about the version on the server. Jenkins Master doesn't even need to actually build.
I'm setting up TFS 2015 for my team to try out, and I'm having trouble getting it off the ground. It sounded straightforward, but things don't work and I can't find any diagnostics, and tutorials don't match what I'm seeing. Some highlights:
When I go to download a Build Agent from the server, I don't get a PowerShell file (ConfigureAgent.ps1), I get ConfigureAgent.cmd.
The images and description of setting up the build controller show me a nice picture of the TFS Admin Console with a Build Controller and Build Agent and their statuses underneath 'Build' (see Team Foundation Server 2015 Builds will not start or https://msdn.microsoft.com/en-us/library/ms181712.aspx.) On my system, I see this display under XAML Build Config (the old way,) but the Build item in the console doesn't have anything like that. It has a link to download an agent, but installing an agent doesn't change this.
Installing the agent appears to work. I get a service that's running, and the web portal agrees that I have an agent in the default queue and pool.
But, queuing a build just sits there. I've found the _diag folder for the agent, which has logs with a bunch of "Message received, no message retrieved" lines. I can't find anywhere else to check if the server knows about this build.
The service account is Network Service, and I've tried putting it in every TFS group mentioned online regarding permissions.
My setup is TFS and VS 2015 installed on our build machine, with it also hosting the build agent. I'm on port 8079, because port 8080 is taken. It's got to be something silly I missed, because everything looks like it's working. Has anyone gotten this beast off the ground without coming from a pre-existing install?
The configureagent.cmd is the correct file (it does pretty much what he ps script did)
Make sure the account that the agent is run under is in the "Agent Pool Service Account" role. It is better to use a domain/machine account not a local service account.
Make sure the queue is provisioned in the collection ( https://your-tfs-server:8080/tfs/your-collection/_admin/_AgentQueue ). If not - select "New queue.." and select the existing queue.
Make sure that when setting up the build through web access, the demands (on the general tab) is met by the capabilities of the agent.
If all this is in place, I have found that it facilitates testing by running the agent in interactive mode (not as a service). This gives you a bit better insight into what is happening. When it is working you can configure it as a service again.
Use an actual service account, not NETWORK SERVICE, and make sure that service account is a member of the Build Service Accounts group in your Team Project.
For me the issue was that the IIS's Team Foundation Server site setting's Authentication, "Windows Authentication" had to be enabled.
I was using a windows user as the log in credentials for the Build Agent running as a service.
Remember this new build system uses all http now.
It does not talk to any tfs build controller.
I'm attempting to move our internal builds to VSO. The kicker is that we have our own private nuget feeds that the builds will obviously need access to. Now I would rather not have to just open the feeds up to everyone and instead whitelist the ip(s) being used by the VSO hosted build agents.
Has anyone got any ideas as to how I go about getting th ip ranges used by these hosted agents?
Or is there a better way of achieving what I am after?
thanks
VSO Build Agents are hosteded in cloud, so there is no changeless IP range for them.
I would recommend you set a credential for your Nuget Server. And in the build definition, adding a powershell step to call Nuget restore instead of using the "Restore Nuget Packages" option provide by VSO.
Other option also might to be install your own agent service on machine which has access to yours Nuget Repo:
https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows
I'm wondering if there is an easy way to "publish" p2 update sites in Jenkins (built with Tycho) so that they can easily be accessed in downstreams jobs? Currently I'm doing it semi-manually using Jenkins support for copying artifacts between jobs, and then specifying a repository-mirror element in a job-specific settings.xml which refers to the artifacts copied into the job, but this is all a little tricky and requires configuring jobs and build settings in a number of different places.
Is there any nicer way short of using an external solution such as Artifactory?
The only solution involving a repository manager that I am aware of is to use a Nexus and the Unzip Plug-in. (Disclaimer: The Unzip Plug-in is provided by the Tycho project, of which I am a committer.)
With such a setup, you could have one job deploy an update site to Nexus, and the next job use the update site via the unzip URL of the deployed site. Example: If the site was deployed under the GAV project.abc:site:1.0.0-SNAPSHOT, you could then access it via http://<nexus>/content/repositories/<unzip-repo-name>/project/abc/site/1.0.0-SNAPSHOT/site-1.0.0-SNAPSHOT-unzip/.
Note that you are slightly less flexible with such a setup that with what you have set up now: You need to have a version number for what your upstream project is building, so this may become tricky if you have multiple feature branches developing towards the same release version.
If you don't need this, you have the benefit of getting a portable build of your downstream project, i.e. developers build the project in the same way as your Jenkins does.
We recently upgraded to TFS2012 and now we have an MVC app and a WCF Service both built in VS2012 that WILL compile and build but will NOT deploy. Any ideas on what I should research? I read that MS now only allows deployment of certain types of files and web files are not of that type. Thanks so much for your time.
The default build processes in a standard on-premises TFS2012 installation do not do any deployment out of the box. Therefore in answer to your question I would personally look at the custom deployment steps that are happening and maybe put some additional logging in to identify the problem.
Often being able to remote desktop into the build server and then perform the steps that your build process would have taken is a good way to check things like this.
As the upgrade process usually involves re-installing the build agent my guess would be that it could be a permissions problem, maybe the build agent was installed as a different user to how it was running in the TFS 2010 configuration and that process/user does not have permissions to deploy the build. But that is just a guess - digging into the deployment steps that you added to your build process should help you track it down. Good luck!