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.
Related
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.
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.
We use Azure DevOps Server 2020 on prem. We are not in a position to move to Services. We are not in a position to use agents in Azure, because these agent would not be able to talk to the server, which is behind the corporate firewall.
So, we are stuck with on-prem agents and this suffocates us. Our app is a monolith in the worst sense of the word. Its PR build takes time and is extremely hungry on resources. Currently we have 2-3 PR builds running concurrently on the same machine and it takes eternity. In short - it is very bad.
On the other hands, developers have pretty powerful machines. Of course, I do not want my machine to serve PR builds of others, but if it could run my own PR build, that would be fantastic.
Alas, I do not see how this can be done. So, my question - is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine and only if there is no such agent would it pick up a "standard" build agent running on a build server?
Clarification
Although the question speaks about Alice, but there are also Bob and Charlie and Deepak. About 300+ developers. So, the solution should not assume there is only one developer working on the code.
is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine
We could install the self-hosted agent in the Alice's machine, open Organization Settings->Agent pools->select the agent->click the tab Capabilities->search the field Agent.ComputerName, then open PR build definition and add Demands, such as below.
Then the PR build will run with the specified agent, you could check this doc: Specify demands
for more details.
In addition, if the PR build does not find the matching agent, the build will not run with another agent.
Update1
Each developers have their owner agent on their owner’s machine, right?
Check this doc: predefined variables, it contain the variable Build.RequestedFor and Build.RequestedForEmail, if the pipeline is pull request trigger, it will show the pull request creator name and email, add this to the pipeline Demands. Such as
And then, let all developers add capabilities to their agents, such as TriggerName = {their email or display name}. Since I am using the variable Build.RequestedForEmail, in my agent, I add the capabilities:
Then if I create a pull request, the build will run via my own machine agent.
Update 2
For example, the original PR build name is A. Open it and add default demand(you could add anything)
Add new build definition name B, add task power shell and enter power shell script to call below REST API to update the A definition
Definitions - Get
GET https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.1-preview.7
Definitions - Update
PUT https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.1-preview.7
Then add build B as pull request build.
Update3
is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine and only if there is no such agent would it pick up a "standard" build agent running on a build server?
If the "real" targets the build agent initially, then what happens when the auxiliary one determines the dev has an individual agent?
The real build definition has demands, If the build runs by default demands, it will run the standard build agent.
The auxiliary one, we need to add condition to run the power shell script to update the real build demands. if Alice's machine has matching agent, it will update the real build demands, and then the real build will run the Alice's machine agent.
I'm trying to set Build Server machine in way that Build Agent is configured on it, and is targeting Azure DevOps Service (Cloud) collection, or organization as it is named like that for now. There is established connection but problem that I'm faced with is regarding workspaces.
When I try to run build definition, checkout step fails due to "Can not determine workspace..." error. As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story. I have to run the mentioned command again (new workspace is appeared in the list) and then I'm able to build that project.
Can someone point me on right way in diagnostic or tell the cause/solution if faced with this already?
According to the description and this thread which i assume is also posted by you,seems the agent in Azure DevOps is the one you used in TFS which is called as migration.
As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story.
It looks like the build definition requires a specific workspace which you managed by manual command.
What about create a new agent in Azure DevOps which is quite simple see if the problem can be resolved.
I'm using azure devops pipeline to build my IIS application and deploy via release management to several different servers, and it works great. My issue though is that one of the servers I need to deploy to will always be offline, so I need to set up some sort of offline installer for that deployment. Is there a way to do this using the build and release management I already have that I'm not seeing?
Azure Pipelines assumes that the server is always available. Best I can think of is to generate some kind of drop on a fileshare and then add a Manual Intervention Task to pause the pipeline and allow you to do your thing.
There is no air-gapped agent nor a way to run part of your pipeline on another system and import the results.