I was using vsts private agent vsts-agent-win7-x64-2.123.0.zip with my proj1 on Computer1 with agent name Computer1. After some period of time I removed a whole project from VSTS. Then I was trying to remove agent config like that 'config remove', but had got error
VS800075: The project with id 'd2df8515-d69b-4a5d-96bf-93872a837d25' does not exist, or you do not have permission to access it.
So I decided to setup agent without removing config. ofcause it wasn't succeed.
Then I installed new version of vsts private agent 'vsts-agent-win7-x64-2.126.0.zip'. It didn't help. Same errors with configuring and removing. After all of this I comletely delete all files in folder and install new agent. I register new agent with same name to new project proj2. Console output was succeed, service started, everything seemed to be ok. But agent didn't appear in VSTS after 30 minutes.
It was strange. I tried to remove agent again, but got this:
Сбой: Удаление агента с сервера
Moved Temporarily
Service has been deleted, but register agent still not available. It tells me to remove agent before.
Does anyone know how to delete agent and register it again in such situation?
In the agent folder, make sure you can see hidden files, delete the .agent and .credentialsfile, then call config remove again. This should remove the service from your local machine and will allow you to reconfigure the agent.
You can also extract the agent to a new folder and perform a clean installation after the service has been de-registered
If the agent is still registered int he agent pool, you can use the little X button to the right of the agent int he Agent Pool screen on VSTS (may need to maximize screen for it to become visible) to remove the agent from VSTS as well. be sure to remove it from the Agent Pool as removing jus from the Agent Queue will not delete the agent from the account completely.
If you go to settings of your account --> Agent Pools you can then view the configured agents per pool. Your private agent is probably in the Default pool if you didn't specify a custom pool. Behind the agent name is a X that you can use to remove the agent.
After successfully removing the agent, you can reinstall it on your local machine. Make sure to run your PowerShell window as an Administrator since that's required to configure a Windows Service.
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 a local Jenkins server running on one of my spare computers (win10). Note that it is not behind any sort of a server and hence is only available within my local network. I have set it up so that it does the continuous fetch from my remote git repo and builds the artifacts and archives them for a successful build. I would like to publish these archives to my AzureDevops Release pipeline. How do I do this? (And yes I have looked through all the tutorials but they assume that I have Jenkins running on a VM somewhere on the cloud).
So far I have had no luck with the tutorials on the web since I donot really have a URL to this instance of Jenkins since it is only available on my local network. I cannot really build these artifacts on a remote Jenkins server, so I am really restricted to using this solution for running the builds.
I am looking to have these archives that Jenkins builds be directly available within my Azure DevOps release pipeline, on every successful build. Thanks for the help!
So since nobody else has answered this I am going to detail what I ended up doing (maybe not the best of the approaches but it works for my setup, suggestions are welcome!).
To interface with the Azure DevOps platform from a local machine you will need to configure a self-hosted agent (based on your specific OS), which will allow you to trigger builds, archive and upload the build artifacts to the Azure DevOps platform. This way you also donot have to poll for SCM changes too (which I think is not that elegant sometimes).
1. So you will need to go through the setup as outlined here for you local self-hosted agent:
Windows: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
Linux: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops
MacOS: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=azure-devops
NOTE: I have chosen to run the agent as service on windows for my setup
2. Next setup your Jenkins build job how you normally would, with your usual repo access setup. Things to keep in mind are following:
Under "Build Triggers", select the Poll SCM option, but make sure that the schedule is blank, this will make sure that the trigger from your post-commit hook from the agent works. Example setup shown below:
Under "Post-build Actions", make sure that you are archiving the artifacts as required. Example shown below:
3. Now time to setup your project's "Jenkins Service Connection", this can be accessed from the Project Settings tab on the bottom left of you project view in Azure DevOps. Note that this basically helps you self-hosted agent to locate and communicate with the Jenkins instance running locally (or an other network accessible location!). Go under Pipelines -> Service Connections and a new service connection for Jenkins. Note that the trick here is to use the URL for the connection as seen by you local self-hosted agent, which means it can be just any IP (including localhost) that the agent can access normally. Username and password are the same as the ones you setup in Jenkins. Example shown below:
NOTE: You can try to do "Verify and Save" but it will throw an error, so ignore the error or just go ahead and "Save without verification". Also you will have to do this per project, unlike the self-hosted agent setup which is per machine.
4. Now you just need to configure your build pipeline to give jobs to the right agent and pointing to the right service end-point. Now under you build pipeline settings use the agent pool that has the self-hosted agent(s) which can access your build servers. And choose the Jenkins connection that you just created in the above step. The rest of the setup is identical to how you would normally setup your project's build pipeline. An example would be as follows:
NOTE: The key here is the correct "Job name" (this should be the same as the one you have setup in you Jenkins build server instance) and the correct "Jenkins service connection".
5. The rest is straight forward in the sense that you just now need to make sure that you have a step to "Download artifacts" (NOT necessary if you donot want the artifacts on the DevOps platform) & "Publish Artifacts" (this is needed for your release pipeline to see that build artifact and to trigger it too if you want), after your jenkins queue job step. Make sure to setup the correct job directories for download from you local self-hosted agent. Example setup for both the steps:
NOTE: If you are having trouble with the paths for download and publish refer to this link for predefined variables for the self-hosted agents: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
6. Now in your release pipeline you should be able to add the artifact sources from you build pipeline. Example shown below:
Now you should be able to get the local artifacts in the cloud on the Azure DevOps platform, in case you cannot use the build agents provided by Microsoft for any reason!
I noticed that all of my builds suddenly got stuck. If I click the build I get the following error: All eligible agents are disabled or offline
When I check my agent pools I get the following:
How can I bring them online/determine why they are offline?
Try logging into the VM, and run the run.cmd from an elevated powershell prompt in your agent directory.
Source: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
Login to powershell.Navigate to the agent folder where it contains run cmd prompt and config cmd prompt.
Execute the following command
.\run.cmd
Check the date and time on your VM. If it's wrong, correct it.
Then run powershell as administrator and cd into the azagent folder that contains the run.cmd file (most likely C:\azagent\A4).
Execute the following command:
.\run.cmd
For me, issue was suddenly agents were reporting offline on the portal.
Restarted the agent service in the VM - didn't help
Removed config file also didn't help because logs were showing that dev.azure.com wasn't connecting
Simply just restarting VM helped, but still couldn't able to find the cause.
The VM that host the build agents can have a auto shut down time. Make sure your build vm is running by going to Virtual machines in the azure portal
My agent stopped going live when I updated our Azure Devops to the latest version 2019.1.3 iirc.
To solve this I did the following:
Went to services.msc on the agent machine. Stopped the existing service.
Went to agent folder and removed the existing configuration via "config.cmd remove"
Downloaded latest agent code from the Azure Devops Agent Pools portal page.
Replaced contents of old agent with new agent files.
Went back to agent folder and configured a new agent via "config.cmd". Told it to start as a service.
Voila! Service back running again.
One of my Azure agents started showing as offline. As a test, I ran curl https://dev.azure.com/{organization} and got back an error "curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed".
I fixed the issue by downloading IISCryptoCli.exe from https://www.nartac.com/Products/IISCrypto/Download and then running "IISCryptoCli.exe /template default /reboot".
I solved this by connecting to the agent via Remote Desktop Connection and running the "Run Puppet Agent" application.
Please check the agent from agent tab under releases.
There should be a server listed for the agent under agent tab.
Now connect to that server and check weather the agent batch file or cmd window is open or not.(this agent for is the same file which is downloaded while configuring the agent.if you are struggling to find the file then follow new agent steps and download zip again and search with that file name.)
Now open the(filename -run) file on that server with admin right if it is already not running. This will make agent online in devops portal.
Now check the agent tab again in devops portal under releases.
This
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
Recently I was able to configure a build agent on my laptop and queue a successful build on TFS.
Then I tried to switch to a build server VM. I created a service account with the same rights as my account I was using from the laptop and configured a new build agent on the machine to use the service account and the same pool and started the agent.
When I log into TFS I can see the agent running in the correct pool, and it is green. So I disabled the agent from the laptop, so it would use the new agent on the build server. However, when I queue a build to the pool, the message displays "all possible agents have been disabled". So my new agent is in the pool and enabled, but when I queue a build it is not seen as a possible agent.
How do I make the new agent pick up the request to queue a new build? I verified it's running as a service on the build machine.
Please make sure the service account is a domain account and is part of “Agent Pool Service Accounts” group in TFS under your Agent Pool.
Then check the capabilities, and make sure the agent capabilities match the one set in the build definition. In addition, private agents give you more control to install dependent software needed for your builds and deployments. You can compare with you laptop, to check if there are any necessary dependent software misinstalled.