Im working on a simple deployment pipeline with azure devops. I created a deployment pipeline running on a self hosted ubuntu deployment group.
The pipeline looks like this:
Download artifacts from CI pipeline (created with dotnet publish)
Stop running deployment
Unzip the ASP.NET Core Web API to the deployment directory
Run new deployment with dotnet MyApp.dll
The first two steps work as expected. However, when the dotnet My App.dll command is run, the process runs for 10 seconds with following "error" message being printed at the end:
The STDIO streams did not close within 10 seconds of the exit event from process '/usr/bin/bash'. This may indicate a child process inherited the STDIO streams and has not yet exited.
The deployment task is successful despite the message and the app not running. I tried to work around this feature by using nohup & and relocating the command output. After some research I found that all processes started by a pipeline agent are stopped after the agent's work is done - meaning this behaviour is intended and my understanding of azure deployments/agents is wrong.
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
You are already on the right way.
All the process launched in the pipeline will be finished/clean up in “Finalize Job” step when the pipeline is over.
If you don't want the process to be closed, please try set variable Process.clean= false to stops the "finalize job" step from killing all processes.
But when you create a new pipeline next time, you need to close the app before starting it.
Related
On my Azure DevOps Server instance (2020 Update 1.1) I have easy multistage YAML pipeline with Build job (run against BuildPool) and release job (run against ReleasePool). Build job is executed successfully. In release pool there are many idle agents but job is in waiting state with message:
The agent request is not running because all potential agents are running other requests. Current position in queue: 1
No agents in pool ReleasePool are currently able to service this request.
Other pipelines on the server against ReleasePool are executed.
This pipeline was executed one month past also successfully, and since this execution the YAML definition stays unchanged.
Pipeline have no explicit demands, I'm trying to identify implicit demands (from used tasks - I have checked tasks.json task manifests for each used task) - but there isn't used no task with demands.
I have no idea what I could try next.
Is the way how to diagnostic how are agents assigned to the pipeline jobs? I have admin permissions and access to the DB, I'm ready to do very deep analysis.
Since other tasks are running fine, maybe a specific demands on selected agents are not met and this is preventing an agent to be found.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops-2020&tabs=yaml
Or else, it's a bug.
I found a similar issue here, and Microsoft responded July 2022 with:
"We have released a fix for this issue"
https://developercommunity.visualstudio.com/t/no-agent-found-in-pool-azure-pipelines/870000
It is however not clear to me if this only applied to Azure DevOps or also to Azure DevOps Server.
But since your on 2020 Update 1.1, updating couldn't harm you:
https://learn.microsoft.com/en-us/azure/devops/server/release-notes/azuredevops2020u1?view=azure-devops-2020
I have a simple build and release pipeline in Azure Devops. I notice that when it finishes, it shows a summary screen and selects the job not the final task. A simple example is:
Agent: Hosted Agent
Started: Just now
Duration: 4s
Job live console data:
Starting: Job Deploy Development
Finishing: Job Deploy Development
Is there any way to add to this output stream (such as echo "##vso[job.xxx ...")? I checked the pipeline logging options and only see ways to interact with an individual task screen.
As far as i know, this is not available.
The Logging commands are for tasks and scripts communicate with the agent, not the entire job scope.
I have set up a build pipeline, that builds a solution(windows service), publishes it on a windows server and starts up the service. It runs flawless for the first time.
After that, when I trigger the pipeline, it fails at the "Initialize Job" step and reports that it can't remove some of the files in the Debug folder.
While I know why it can't delete these files(the service is running), I can't figure out a way to stop the service beforehand. I tried running a powershell script as first task like following with script so that it can delete my previous build
if (Get-Service "MyService" -ErrorAction SilentlyContinue) {
net stop MyService
sc.exe delete MyService
}
But it fails even before executing any task from the pipeline.
What's the best way to go about it?
I've used these Windows Service Release Tasks in on-prem servers:
https://marketplace.visualstudio.com/items?itemName=jabbera.windows-service-release-tasks
Looking at the attached image, I think might be trying to put stuff that's not supposed to be there in the build pipeline. Instead of trying to install services as a part of the build pipeline (or build stage of multi-stage pipeline), separate deployment tasks to release pipeline (or release stages of multi-stage pipeline). You are now essentially running operations that try to create services within the build agent and you want to run them in the server you are copying the build results into.
Run the release pipeline with deployment group agents so the release is executed at the server you are deploying to, or if that's not possible, run the release pipeline with hosted agents/build server agents, but use WinRM to run the tasks against target server.
I've recently had an issue using Azure DevOps pipelines when deploying a release.
I'm using a set of Tasks to take a VM snapshot, install the application, start services to multiple websphere application servers in parallel and then delete the VM snaps if release is successful.
The 'delete snapshot' step is marked to run 'only when all previous jobs have succeeded' and the application install step has the 'Fail on Standard Error' checked in the Task's Advanced option.
The release deployed successfully to 1 server and failed on another because the service didn't start. both the checks were then ignored and the snapshot was deleted.
How can I get the Pipeline to fail when any one node has failed, instead of all of them?
I'd like to enhance the release definition so that I don't need to have a separate environment that only starts an Azure VM.
If we take a scenario where we have a Test, Beta, Production environments. The client wants the application to be installed in Beta and Production on their local network. We internally want a Test environment to run E2E tests against, allow for non-technical folks to exercise the app without needing VPN access to the customer beta environment, etc.
So here we have Environment followed by where the Agent is running:
Test - Azure VM
Beta - Client machine
Production - Client machine
How we've solved this is to install the VSTS Agent on a machine at the client, which allows us to target that agent queue in the Beta and Production environments defined for that release. Then we typically build an Azure VM and target that agent queue for the Test environment.
We don't want to run that Azure VM 24/7/365. However if it's not running, then it can't respond to requests from Release Management.
What I've done is to create a environment named Start Test VM and Stop Test VM that use the Azure Resource Group Deployment to start and stop the VM. Those 2 additional environments can have their agent queue set to Hosted.
I'd like to figure out how to combine the first 3 environments into a logical Test instead of having to create 3 release management environments.
Start Test VM - Hosted
Test - Azure VM
Stop Test VM - Hosted
Beta - Client machine
Production - Client machine
The problem is that can be rather ugly and confusing when handing this over to one of our PM's or even myself when I circle back around 3 months later and think, "What the hell is this environment? Oh it's just there to start/stop the VM."
Options:
Stay with status quo - keep it like it is, it can't be fixed
We could open up a port on the Azure VM and use Powershell remoting. Then run on the Hosted agent or on an on-premise agent to start the VM, then deploy the application, then stop the VM. - we really dislike this because the deployment would not be the same as the client on-premise deploy. We'd like each environments' tasks to be the same, just with different variables.
You can use "Azure PowerShell" and "Azure SQL Database Deployment" tasks to configure your Azure VM and SQL or call other script to run on the Azure VM.
There isn't any way to set the agent for tasks. You can submit a feature request on VSTS User Voice for this.
And another way to reduce the environment is that: if you deploy every build linked to the release, then you can add "Start Test VM" task into your build definition to start the VM when build is successful and add "Stop Test VM" task into "Beta" environment.
What we've currently settled on is to continue with having an environment that isn't really what I would consider an environment, but more of a stage in the release pipeline that starts and/or shuts down a VM. We run that on a hosted agent so it can start the VM and make sure to check Skip artifacts download on the environment.
For a continuous integration build, we set a chain so the VM gets started, CI environment gets kicked off and then VM gets stopped. The remaining environments are then manually deployed up the chain as desired.
So here's an example:
Start CI VM
CI
Stop CI VM
Beta
Production
And here's an image of how it looks in Release Management as of 2016.06.27:
I put single quotes around environment because I think I agree with this user voice request in that, it's really more of a stage in the release pipeline. Much like database development, the logical and the physical don't necessarily map 1 to 1.