I'm running a TFS build controller and build agent on the same machine, and I noticed that I don't see the build agent service in the services console. Maybe this is how it is when they are both on the same server, but then according to the practices as outlined in the MSDN regarding TFS, there is supposed to be a TFSService (to run the controller) and TFSBuild (to run the build agent) service accounts, but I don't see a place on where I'm supposed to assign TFSBuild to a service. Where is the build agent service? According to this article, I'm supposed to have two different user accounts: http://msdn.microsoft.com/en-us/library/vstudio/ms253149.aspx
All TFS Build components (controller and agents) share the same windows service and service account. You can see this in the TFS admin console.
Related
I have a Git repository on the Azure Dev-ops server and use Jenkins for continuous integration build.
I want to know that how a specific branch like master Jenkins can automatically run the build and then notify the user via a shell log that the build was successful or not?
Microsoft seems to have the thing pretty well documented, Create a service hook for Azure DevOps Services and TFS with Jenkins
Set up the Jenkins job, set up the TFS / Azure DrevOps ServiceHook, off to the races.
We have it working fine for Jenkins 2.x and AzureDevOps on-prem. Best to use service accounts with limited necessary permissions on both sides.
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!
Trying to make my CI/CD work using TFS. Have to overcome some of this user role setup. Also not really getting my head around the terminology and the workflow (kinda different with how Jenkins works) and at the same time I have to figure the myriad of TFS versions(2010/2012/2013/2015/2017) and the online Visual Studio team services. I have to unlearn what I already know somehow, thus my basic questions:
What are agent queue? What are pools? (when i click create queue, it will ask me to create new pool)
What does "Download Agent" means? I thought this agent will be installed on the server side like a plugin that you install in Jenkins.
I think this might help clarify:
An agent pool defines the sharing boundary for all agents in that
pool. In TFS, pools are scoped across all of your Team Foundation
Server (TFS); so you can share an agent pool across team project
collections and team projects. In Team Services, agent pools are
scoped to the Team Services account; so you can share an agent pool
across team projects.
An agent queue provides access to an agent pool. When you create a
build or release definition, you specify which queue it uses. Queues
are scoped to your team project in TFS 2017 and in Team Services, so
you can only use them across build and release definitions within a
team project.
An agent in TFS / VSTS does work (like a build or a release). Microsoft offers agents they host if you are using VSTS. Alternatively, you can setup your own agents. For example, if you need to run your build on a particular machine because it has some needed items to do compilation or you're using TFS and can't use the hosted, you'd need to download the agent and configure it on a machine. You can have multiple agents on one machine. I'd recommend not installing an agent on the same machine as the TFS application tier if you're working with an on premise installation.
The official tutorial which involves a lot of aspects about Team Services and TFS. Most of the concepts is the same in /2013/2015/2017 and Team service. You just need pay attention to the support version under the topic such as below screenshot:
An agent queue provides access to an agent pool. When you create a
build or release definition, you specify which queue it uses. Queues
are scoped to your team project in TFS 2017 and in Team Services, so
you can only use them across build and release definitions within a
team project.
More details about agent queue and agent pool, you could refer this link: Agent pools and queues
each queue can use only one agent pool.
This is why when you click create queue, it will ask you to create new pool.
For TFS2015, you are using the private agent.
An agent that you set up and manage on your own to run build and
deployment jobs is a private agent. You can use private agents in Team
Services or Team Foundation Server (TFS). Private agents give you more
control to install dependent software needed for your builds and
deployments.
You could use the download agent to Deploy an agent on Windows. And one of the most commonly used scenes of the "Download Agent" is when you are installing multiple private agents on the same machine.
I'm trying to set-up a new build server for my TFS 2013 installation.
On a new machine, I've configured a build user:
On test, this approved the user fine; however, running the readiness checks reports:
My interpretation of this error is that build.user does not have access to TFS; which is correct. My question is: can I run the build server using a domain user, but with a separate user for TFS access?
Can I run the build server using a domain user, but with a separate user for TFS access? Yes, you can and the build service account do not need to have the access to TFS.
Suggest you use TFSBuild as the build service account as MSDN recommend.
TFSBuild, which can be a local account, a domain account, or Local
Service in a workgroup
This service account is used when builds are configured and when build
status information is communicated between the build controller and
the build agents. More info for you
reference:https://msdn.microsoft.com/en-us/library/ms253149(v=vs.120).aspx