We detached one of our main collections and it failed to detach so we restarted it and everything appeared to be fine. But we found this morning that the Build pipelines are not picking up new builds. The build servers are communicating and showing online but nothing is queuing. Anyone ever experience this during a detach/reattach process?
Update
Customer quiesced and unquiesced TFS and that fixed the pipeline issues.
Detach/reattach collection usually will not effect build related.
First, suggest you to take a look at Event View if there are some useful logs for troubleshooting.
If you are using vNext build, check the agent pool and agents which should all be green.
Make sure in your build definition, you have selected the right agent queue. Also try to create an empty build definition with no build task to see if the issue is related to the definition. And also restart your agent service on your TFS server.
Also check if the service Visual Studio Team Foundation Background Job Agent is running. If not, start it manually and try the build again.
Note: The service is running in TFS server, not build server.
For logs to troubleshooting , check the event view and the log in \agent_diag on build agent to see whether there are some useful information.
If you still get this issue, then deploy and configure a totally new build agent. This will help to narrow down the issue.
Related
I just created a new Build server and added it to an existing Queue, I turned off the other agents in the queue so that this new build server would get the job. I sent a very simple .NET build but the build window says "Waiting for an available agent"
So I get it, I must have missed installing something on the build server. So when the job is submitted it's looking for an agent that can satisfy the "capabilities" How can I see that what capabilities the job needs so I can see why it's stuck?
As far as I know, if the agent capabilities couldn't meet the build demands, it will show the warning message at the build result or queue time.
For example:
You could try the following points to troubleshooting:
Navigate to Local machine->Service and check if the Visual Studio Team Foundation Background Job Agent is running on the TFS application tier server.
You could start or restart this service.
Make sure the account that the agent is run under is in the Agent Pool Service Account role or Project Collection Build Service Accounts and the account is a domain account.
TFS2015 -> Agent Pool Service Account
TFS2017 TFS2018 ->Project Collection Build Service Accounts
Change another available account for agent service, restart the service.
3.Restart the whole TFS server and check if this do the trick. Need some time to wait.
Here is another ticket with the similar issue, you could refer to it.
Hope this helps.
I have 20 agents and a couple of them are offline after we run on out of space on the tfs. I cleaned the _work folder to have more space, and it allowed me to bring at least the 80% of the agents back without doing nothing just clicking on the Update option over the application pool
Unfortunately as you can see I have a couple of them offline. I went through the tfs server and launch the cmd with the run command for the agent15
The funny thing here is that the agent is online now, BUT if I close the cmd on the tfs server it goes offline again. Can any one help me how to bring the agent online having the cmd opened?
A workaround is to reconfigure the agent and that's all, but I want to avoid that step, sure there is a better way than reconfiguring all my offline agents again.
When you do the manually update all agents, all build agents within the selected pool will go offline temporarily and then come back online as soon as they are updated.
There are multiple reasons if a build agent is offline. The simplest and effectively way is reconfiguring the offline agent.
In your case, you could also try to restart the Visual Studio Team Foundation Background Job Agent in services, and if you run your agent as a service, also restart the agent service VSTSAgent(machinename.xx). If it's not work, still recommend you to do the reconfigure option.
As #Patrick-MSFT said, I would like to expand more the details. When you download the content of an agent and you try to establish the configuration, you need to do the following steps
Download the content
Run on the cmd as admin the config.cmd
Connect to the tfs address
Establish the agent pool
Name of the agent
Enter work folder(just
press enter and by default you will get a _work folder created
inside the agent)
7. Enter run agent as service? (Y / N)
If you select Yes then you specify the credentials that the agent should use. At that point you have on your windows services as many services as agents you created. All of them with the prefix VSTS Agent(tfsserver.NameOfTheAgent)
Probably for some reason you had the services stopped. Just right click and restart or start the agent
I am using an TFS agent to schedule some Build using triggers. My issue is that when the build starts it wants to get latest version (sync repository). But I get an unusual error:
I have literally no ideea where to begin, it's like it could reach the server or something.
I could not comment. Hence providing an answer.
Does the account your agent is running under, has rights to the TFS repository mapped in the build?
For more logs check the logs in D:\Kits\agent_diag folder.
We're running TFS 2015 update 2. When a build starts, it says "Waiting for an agent" then, 2 seconds after, the build fails. I looked whether the agent pools were running, and all of them were on green (as I understand this is expected). Also, I looked whether the TFSJobsAgent was running, and it's ok. If I download the zip log from de build process, it is empty, so i don't know what i'm doing wrong. i tried to create a new agent pool, and run the build process on that agent, but i got the same result.
Any ideas on how to tackle/solve this?
PS: All the builds were working fine a week ago.
The build service account needs to be a member of the Build Service Accounts group.
You also need to check whether the build agent service is running.
There are two machines with Jenkins: one for building, second for testing. If some job is successful on 1st machine, it triggers testing job on 2nd machine via http request. For example:
http://<2nd_jenkins_ip>:8080/job/<job_name>/buildWithParameters?BUILD_NUMBER=167
The problem: It seems that there is something, which launches some of the testing jobs automatically, but it shouldn't. I have deactivated nightly builds, but it happened again. And I can't find out the reason.
Question: Is there any possibility to display the IP/url of the machine, which started the build (e.g. into console output)? If not, can I find this information elsewhere (e.g. jenkins/linux logs)?
EDIT1:
Console shows:
Started by user anonymous
Building on master in workspace <my_workspace>
Cleaning local Directory ./test_data
Checking out ...
Following svn checkout and other build steps.
In the Jenkins_HOME directory on the server, look under jobs/<jobname>/builds/<select the last build you want by date>
In there, open log file (no extension) with any text editor. It will usually provide a more detailed cause at the top of the file.
There are many ways you can prevent unwanted builds. One way is to configure Authentication Token under Job's configuration -> Build Triggers -> Trigger builds remotely. Once a token a set, other (rogue/old) scripts could not trigger the job without providing this token.
This however does not prevent manual triggering through the UI or other projects triggering through Jenkins' methods (not URL).
I've also had some inconsistent issues regarding jobs that were configured on a schedule/timer to the effect that changes wouldn't take effect until Jenkins restart.