We are unable to run any release becouse of the following message:
Your account has no free minutes remaining. Add a hosted pipeline to run more builds or releases.
I guess this happend becouse one of our build was using the hosted version and not the private pipeline.
The problem now is that we cannot run any builds. The builds are running fine (on local agents) but we're unable to run any releases.
How can we modify the release definition to use a local agent?
Thanks for any help
You can choose the agent queue to use for a release within the Phase view within an environment.
A release has environments. An environment can have multiple phases. Each phase can run on a different agent queue.
This sounds like a licensing issue to me. VSTS Release pipelines are a paid product. You get 1 hosted and/or private pipeline free each month, but after that you pay for each one. Hosted pipelines are also limited to the number of minutes you can execute them (You get 240 free minutes).
Check out this page for additional details and make sure you are licensed up.
Also, if you have Visual Studio Enterprise licenses, these will grant you extra pipelines per user.
Related
Is it possible to clone or copy an Azure Pipeline Hosted Agent for use as a Self-Hosted Agent?
I'd like to reuse one of the Hosted Agents simply to enable me recreate and reuse all of its
capabilities, saving me the headache. Is this possible and if so I'd really appreciate some help.
Thanks
This is not possible, but you can try to reuse what is already available here https://github.com/actions/virtual-environments
This repository contains the source used to create the virtual environments for GitHub Actions hosted runners, as well as the VM images of Microsoft-hosted agents used for Azure Pipelines. To file bug reports, or request that tools be added/updated, please open an issue using the appropriate template. To build a VM machine from this repo's source, see the instructions.
So you can use the same scripts which are used to create Microsoft Hosted agents.
There is no such build-in feature.
Azure DevOps provides free hosted agents that have a predefined set
of tools installed and configured for building and releasing your
apps.
There is another option where you set up and manage your own agents.
This can be done by simply downloading the agent package, and run it
either on your local machine or any other computing platform even on
Docker container. It also gives you more freedom to install specific
dependencies for your build and release.
If you want to build your own agent during the pipeline. I would suggest you use Docker container to handle the process.
Microsoft has already created pre-configured container images on Docker Hub for everybody to use. But they’re Linux based and don’t contain any additional applications and/or packages so you’d probably still need to add those every time you run your build.
This repository contains images for the Visual Studio Team Services
(VSTS) agent that runs tasks as part of a build or release.
VSTS agent images are tagged according to the base OS, an optional
Team Foundation Server (TFS) version, and tools that are installed.
When used with VSTS, the agent version is automatically determined and
downloaded at container startup based on the account to which the
agent is connecting.
More detail step, you could refer this article: Build your own Azure DevOps agents with pipelines
I'm fresh in the area of CD/CI and I need to implement it in an old project from my company. From what I have read we have a couple of options like Azure DevOps or Team City, I chose these two options because most of our projects are built in Microsoft technologies.
I have been reading for a while, but I cannot grasp the proper definition of a Build Agent; also, I found this old question, but the answer is unclear:
In Team foundation server what is build agent and controller?
Further, I read different documentation:
Azure Pipelines agents
Build Agent
And their definitions are the following ones:
An agent is installable software that runs one job at a time.
Microsoft
A TeamCity Build Agent is a piece of software that listens for the
commands from the TeamCity server and starts the actual build
processes. JetBrains
However, I cannot understand exactly their role or purpose, do they build the Test, UAT and Production pipelines in parallel to see if the compilations were successful? Like here:
Or what do they do? Since the solution has multiple projects inside maybe 8 or 10.
You can take the example that I gave in the comments below:
Let's suppose you create a project in Azure DevOps for your new CRM
for a Dentist with a Debug, UAT, and Release environments plus a team
of 5 devs. What would represent these agents?
Thanks for any explanation.
It's analogous to a human "agent" who has different skills. Think of Build Agent as computer process that has certain capabilities to perform a build.
Some agents can perform certain jobs (e.g. build Apple specific programs), while other agents are more general purpose. Sometimes a computer can have multiple agents that can work in parallel, other times computers only have a single agent assigned to them.
Edit - Added the following to address additional questions:
Agents can be "local" which means they are on the server where the build software (e.g., Azure Pipelines, Bamboo, Team City). They can also be "remote" or on a different computer. A remote agent may be needed to build Apple specific software as this software often needs a Mac to compile.
Extending the human "agent" with different skills analogy, agents can be assigned jobs. So one agent may be assigned building software in your pipeline while another agent is busy handling deployments to different environments. Since each "agent" can only do a single job at a time, more agents can speed up build pipelines by allowing parallel jobs.
In Azure Devops,there is a left Navigation called pipelines where you need to create a build pipeline(with certain tasks) which actually requires an agent to perform the tasks.
In general,build agent/agent is a hosted machine with necessary capabilities(in case of Azure devops) used to run the predefined tasks as per the build pipeline setup to build the source code and make it available for deployment
I am wondering how VSTS hosted agents provisioning works in terms of state. Does a hosted agent get reassigned from one job to another without being 'snapshotted' back to a 'clean' state? Or does it carry around the remnants from previous builds?
Thanks
There won't has any data 'leakage' between different subscriptions to use Hosted agent, even you build the same build definition for twice, you can not get any data from first build to second build.
That's why Clean option is not relevant when you use Hosted agent, and you can find Clean the local repo on the agent section:
Note
Cleaning is not relevant if you are using a hosted agent because you
get a new agent every time in that case.
Hosted agents are single-use only. They are not reused between builds.
I have a local VM that has successfully been running builds from VSTS.
After the builds are completed I have a deployment job that pushes my artifacts to a number of servers. This has been working fine for the past few months.
This morning, I received a message that I was out of "deployment minutes" and my deployments failed, however my builds completed.
Obviously it was building locally, but deploying in the cloud.
Is there a way I can configure my agent or my deployment job within VSTS to use my local agent?
You should just be able to switch your release definition to use the same agent queue as your builds. In each environment, click on each phase and change the agent queue it uses from "Hosted" to whatever you named your local agent queue.
You may need to install additional software (Azure PowerShell, if you're deploying to Azure, for example), but it will work the same -- the build and release agents are exactly the same software and use exactly the same tasks.
You should be able to add your agent to the pool (it requires some software installed there of course) and then select it instead of a hosted environment in the deployment step configuration:
Agent pools
At the bottom you can find:
The hosted pool provides all VSTS accounts with a single hosted build agent and a limited number of free build minutes each month. If you need more hosted build resources, or need to run more than one build concurrently, then you can either:
- Deploy your own on-premises build agents
- Buy additional hosted pipelines
Here is where I finally found the option to specify which agent the release should run on:
I have a Windows VM that hosts a VSTS build agent. Due to the number and length of builds that are running I would like to know whether multiple build agents can be hosted on one computer? That would allow a dedicated agent for slow builds, and a dedicated agent for quick builds.
https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows
Yes you can run multiple agents in a single VM.
Make two directories say Agent1 and Agent2, extract the agent in each one of them and configure them with different names against your VSTS/TFS account.
It should work out of the box.
We run 4 agent jobs per machine concurrently with no issues. As mentioned above, should work out of the box. Just make sure you clean up directories. We have a script to do it every night
Yes, this works, I did the following:
Created a PAT for agent installation needs
Downloaded agent binaries from the agent creation page
Unpacked the archive contents into 2 different directories ("c:\ado-build-agents\agent1" and "c:\ado-build-agents\agent2")
Ran "config.cmd" and followed configuration instructions, provided by it.
Updated pipelines to build the agent pool, which those agents reside in ("Default" in my case)
To test the setup - triggered all 15 pipelines, that I had. As the result I was able to see two pipelines running at the same time, while others were in the "Queued" state (according to my expectations).
I will be also testing out how resources are consumed by the agents to try to understand if I should deploy more agents on the build machine.