I did some maintenance today in the agent folders and now continuous integration is no longer working. I removed the agents (2 of them), removed the directories, reinstalled the agents, repeat x2, rebooted both the TFS controller and build machine, but yet nothing.
Does anybody know where some logs are that can help? To trigger the builds I am editing a file in a directory that is monitored by many build definitions.
Any suggestions are appreciated!
Related
I think something in my TFS 2017 is locked. The builds will no longer be assigned to the build agents.
Build not starting:
Agents available:
Information:
- TFS2017 running on Windows 10.
- Build agents running on same machine.
- SQLEXPRESS Database was full (10G cap), since then no more builds.
- I backed the database up and migrated to SQL Standard to solve the full database.
What I tried:
- Unconfigured the agents and reconfigured them.
- Deleted the default agent pool and got a new one, reconfigured the agents again.
Problem:
- Though two build agents are available, the builds are still not getting build.
Any suggestions, please?
I can reproduce this issue when stop the service "Visual Studio Team Foundation Background Job Agent"
So, please check if the service "Visual Studio Team Foundation Background Job Agent" is running on TFS app tier.
If it's not running, just start it.
Did you reconfigure the capabilities of your new Agents so that the Demands can be met ?
The error seems German, so would be great if you can translate that.
I have a vNext build that is stuck at the step below. The VM (Windows 10) keeps being rebooted (even after the build is manually stopped). This agent needs to be configured as an "Interactive Process" (to run Selenium tests).
DistributedTests: Task 'ConfigureTestAgent' on machine 'DVDIP-W10-36.dev.jha:5985' is taking time. Please Wait
I see a lot of questions related to this problem that are unanswered. Can someone please help?
Thanks in advance.
When this happened to me and it was due to the fact there was a legal disclaimer that would appear prior to logging in that you had to click okay to dismiss.
To fix this, we had that legal disclaimer disabled for that machine.
UPDATE: Microsoft has addressed this in VSTS, TFS 2015.4, and TFS 2017.2 to cap the number of reboots at 3. See https://blogs.msdn.microsoft.com/devops/2017/07/03/deploy-visual-studio-test-agent-task-test-machine-rebooting-scenarios/
I'm administering an On-Premise TFS 2015 (Update 1) installation, and we've migrated almost all of our builds to the TFS Build vNext system. Everything was going great until recently when our builds will suddenly and without warning start failing with an error:
Access denied: Project Build Service does not have write permissions for orchestration plan xxxxx
This will even happen within minutes of a successful build on the same agent.
The first couple of times, I resolved it by just re-running the .\ConfigureAgent.ps1 with all of the same values and it would work from anywhere between a couple hours and a couple weeks.
Without any changes to anything permissions related or updates, this workaround has stopped working. The user for the build agents has not changed, and is the same user that runs the XAML build service which is still functional.
I have scoped the builds' Build job authorization scope to 'Current Project', I have confirmed that the build user is registered, a member of the Project Collection Build Service, and there are no non-default permissions.
I am completely at a loss as to why this area is so fickle and unstable.
Does anyone have any insight that could help me solve this issue?
You can check the instruction in this post to fix your issue: Access denied for orchestration plan on Build
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
We currently use TFS 2008 and have build agents on multiple build servers. I came across this article Configuring Multiple TFS Build Services on one Machine which details how to set up multiple agents on one machine and this is a route we'd like to take.
I've set up a new server with 3 agents on it based on the details in the link and each agent has it's own drive on the server to build to.
If I build a project using any one of the agents by itself then it works fine however if I build the same project on each agent at the same time then a very odd thing happens.
Basically two out of the three builds will fail. What I can see in the build output log file is that although the build starts out on the correct drive, at some point during the build it then swaps to the output drive the second agent is using. The build on the second agent will then change to the drive of the 3rd agent and ultimately the 3rd build succeeds.
Each of the build agent services have their own .config file, they all have different port numbers and the properties of the agents are all building to different drives.
Has anyone experienced anything like this before?
Many thanks
You are trying to do something that is not supported by default and I am not surprised that it does not work. You should upgrade to TFS 2013 and move to the Controller/agent model. In TFS 2010+ you can run multiple agents on one box by design.