We are running Azure DevOps Server and we have our own, locally hosted build agents. I'm trying to get a WhiteSource scan to run on one of our build agents. The WhiteSource task "demands" node.js. But none of our projects use node.js at all, so whether the agents have node.js installed is totally irrelevant. I can't identify an option that could be used to stop the WhiteSource task making this demand.
Is there a way to cancel the demand? A way to tell ADO "this task/pipeline is going to demand node.js, but in fact I know better; you may disregard that demand and run the pipeline even on a build agent that doesn't have node.js installed"?
The build pipeline is a YAML pipeline. I would like a YAML-only solution if possible.
I would like to avoid actually installing node.js on our build agents, given that the dependency on it is entirely spurious; it would never actually be used.
Is there a way to cancel the demand?
The demand of some agents is automatically added according to the needs of the task.
In this case, we cannot cancel these demands.
For a workaround to solve this issue, you can manually set the node.js in Agent Pools -> Target self agent -> Capabilities -> User-defined capabilities.
It can also meet the demand of the pipeline without actually installing node.js.
Related
I am unable to find any documentation on wiki which details approach for SSH/RDP into the ADO agents. Will be good to know the approach for both BTL/ATL agents.
The Microsoft hosted agents? You don't. You can't. They are assigned when the pipeline is queued and immediately deprovisioned after the pipeline finishes running.
Your own on-premise/self-hosted agents? The same way you'd SSH/RDP into any other machine. If you're having trouble with that, that's something for you to discuss with your networking / infrastructure team.
If you are using a Microsoft hosted then you can not per the documentation. The agent is created on a one-time instance and then torn down as soon as the build is completed.
Microsoft-hosted agents do not offer:
The ability to remotely connect.
The ability to drop artifacts to a UNC file share.
The ability to join machines directly to your corporate network.
The ability to get bigger or more powerful build machines.
The ability to pre-load custom software. You can install software during a pipeline run, such as through tool installer tasks or in a
script.
Potential performance advantages that you might get by using self-hosted agents that might start and run builds faster.
The ability to run XAML builds.
If you are using a self-hosted machine running the agent, then you'd just SSH/RDP into the server like any other and check the work folder.
I am trying to create a release pipeline in Azure DevOps. We already have a functioning build pipeline that works well, it is able to package the build with VSBuild and publish it as an artifact. Then in the release pipeline I am using an IIS Deployment job (which includes IIS Manage and IIS Deploy tasks) and it gets that artifact to deploy.
The problem is that we already have a publish profile (.pubxml) that should take care of pretty much everything the IIS Deployment is doing (at least as far I as I understand it). So to me it seems I have two options that don't require me to refactor the project configuration itself.
I can try to mimic the settings on the IIS Deployment job to match our .pubxml as closely as possible and manually applying any changes that aren't doable through the task settings. Obviously this is not ideal as that would require us to update both when ever we make changes and it introduces a large chance of the pipeline breaking down over time.
I can scrap the idea of using IIS Deployment and just use a VSBuild task that uses arguments /p:DeployOnBuild=true /p:PublishProfile=Staging. This doesn't seem like best practices because it means my release pipeline isn't passing a build package to deploy, it is just creating a new one at each stage.
So is there a better option that would allow me to utilize the package I created with VSBuild and the .pubxml configuration together in a deploy? If that isn't possible then are either of my options the "correct" way to handle my situation or am I just missing another method of deployment I could use?
Thank you for any help or insight you can provide. Please let me know if there is any more information I can give that would be useful.
You can try using publish settings file (*.publishsettings) for your IIS deployment.
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
To view more details, you can see:
Publish an application to IIS by importing publish settings in Visual Studio
Deploy your app to a folder, IIS, Azure, or another destination
So unfortunately there doesn't seem to be a way I can achieve everything I wanted in this. The publish profiles are required for when we build the project so without making changes to how we configure those I need to build the project whenever I want to deploy. Ultimately I went with option #2. I essentially just copied most of the build tasks used in the testing pipeline and placed those in the release pipeline with a few modified commands to actually deploy the build once finished. It all seems to work just fine but still doesn't feel like best practices. If I am missing something please let me know and I will make updates as appropriate.
When using Azure DevOps I notice that occasionally my pull request builds will fail. After some tracking down I noticed that this is only happening when another build is already running.
It seems that the reason is that the files in the output for the build (exe, dll, note_modules, etc.) will be locked so when another build is started the new build will fail until the currently running one is finished, then I will have to manually re-queue the build again.
I am not very familiar with Azure DevOps pipelines since we recently migrated to this platform and also not sure of the best way to fix this issue. The sln's being built include .NET Framework, .NET Core, TypeScript, and Node.js if that helps at all.
I would love to post the logs and current configuration, but due to company policy I'm not allowed to... :(
Azure DevOps build pipelines fail when another build is already running
You could try to use/add a Capability, like Agent.Name to that two specific build agents then in the build definition you put that capability as a Demands.
As stated here:
How to send TFS build to a specific agent or server
The Capabilities of the agent:
Project Settings->Agent pools->Your agent pool-> Agents->Agent->Capabilities
The Demands of the build pipeline:
Options-> Demands:
In this case, when a pipeline is running in this particular agent, another new build will be in pending state until the current build is completed.
Whenever multiple builds are running on the same pipeline only the first build completes and the rest error.
I would the builds to run sequentially instead of in parallel like they are now, so that if two developers check-in at about the same time, the second build will also complete.
When editing the pipeline in the execution plan under the Parallelism heading I have the radio button set to "none" and they still seem to try to run in parallel anyway.
Can anyone suggest how to solve this issue?
enter image description here
It seems you have multiple build agents. Assuming you are using self-hosted build agents, you could specify certain demands of the agent to use only one agent. In this way, if the agent is not free, the build will keep waiting. To use a particular agent, add a demand of Agent.Name equals agentname, check the screenshot below. Agent name can be found in capabilities of the agent.
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