Hoping someone could help me out with an issue I'm running into. I have 4 different pipelines set up with the first triggering the second upon build completion and so on down the line. The triggers are not kicking off after the previous pipeline steps build completion as they are supposed to do so. THey're also all on the same branch so i'm at a loss as to what to do. Any ideas? Classic pipeline not a YAML
First, you need to make sure that your MPV Automated Testing Step 1 pipeline runs successfully, because a failed run will not trigger the Build completion trigger.
I tested two pipelines on the same branch. On my side, build completion trigger works well.
In addition, there is a recently event of availability degradation of Azure DevOps, which could affected these services, and it has been resolved. If you want to know more information, please click here. You can try again to see if the problem still exists.
Related
I’m using SonarQube 8.8 on Azure DevOps.
It’s work just fine, I have analyzed severals applications. However i have a problem on some applications:
When I run the pipeline it get's stuck in queue indefinitely "The agent request is not running because all potential agents are running other requests. Current position in queue:"
But as soon as I remove the sonarqube tasks, the build works just fine. There is no error message so I have no clue about where the problem may come from.
Can you please help
In your current situation, we recommend you can check your agent pool and make sure your all agent is available. And please check your parallel jobs. Also, we recommend you can try to create more self-agent in your local machine and try to run this pipeline.
And you can refer Sourav's answer in the comment.
More details about this issue you can refer this doc: You don't have enough concurrency
I have an Azure DevOps pipeline build that has several steps and the build is long. Every time there is something wrong with the build we review the logs and identify issues or come up with theories, then in case of a theory we have to insert a diagnostic command line (such as get directory, show contents of a file, etc) in between the steps; and in case of a fix we add a fix but we have to wait for the whole pipeline to rerun and find out. This is causing us to take a lot of time to fix build issues.
If we had access to the state of the agent of an unfinished build and we could just log on using RDP or any other terminal and checkout the contents, and the state of the files on disk that would have saved us a lot of hours.
Is there any way with Azure DevOps to do any diagnostic of this type?
No, if you are using hosted agent. If you are using self-hosted agent you can obviously log in to that one. You can, however, implement steps that only work if the build failed and those steps can attempt to capture information you are interested in (say publish the state of the build directory).
If you are using Azure DevOps Services, there is a new REST API version out that will let you do a "preview" run of changes to the YAML definitions: https://learn.microsoft.com/en-us/azure/devops/release-notes/2020/sprint-165-update#preview-fully-parsed-yaml-document-without-committing-or-running-the-pipeline
I've got Azure DevOps release pipeline for our web apps with two stages:
staging (production slot) and production.
Both of those stages have a task to run integration tests against those environments as the final step.
Sometimes, due to the nature of the live environment (data), some of the tests may fail. That doesn't mean there's an issue with the app.
Once that happens, the release to that environment is marked as Failed (rejected), which is correct from process point of view, but then manual inspection can reveal that it was only a data issue, thus it's ok to keep it.
Is there any way to manually change the status (via GUI or API)? So it no longer appears as Failed on the dashboard.
I can't find anything in the GUI. I was able to find Manual Interventions in the API (https://learn.microsoft.com/en-us/rest/api/azure/devops/release/manual%20interventions?view=azure-devops-rest-5.1), but without any details on what it does.
Redeployment is not guaranteed to be successful from data perspective hence the need to manually override the status.
Edit:
This is what I'm currently getting when it fails, but I'd like to be able to turn the red stage into green.
You can try using option "Trigger even when the selected stages partially succeed" that is available in the pre-deployment condition.
Then I saw option to manually deploy the prod environement.
In exploring devops I have set up several build pipelines for my Azure repository.
When I push my code the following pipeline runs
However I want to stop this pipeline running and run a different one instead.
Where do I configure this?
[Update]
From the docs
It would appear to be to do with step 9, triggers.
How do I edit the triggers?
On the Triggers tab check Override YAML Continuous Integration trigger from here.
Then select Disable continuous integration
Than save
I run build pipelines in Azure DevOps to daily update a Dockerfile and rebuild a container image with updated dependencies. The purpose is to have an up-to-date version of a dependency for the project and release a new artifact in container registry.
In Azure DevOps I have three chained build pipelines. The first pipeline is triggered every day with scheduled trigger. The next two pipelines are triggered with CI trigger file path filters. This all works well, most of the times.
My problem is that sometimes the schedule is not triggered at all. This happens after the pipelines have been running normally for days (ranging from about 1 to 15 days). The checkbox "Only schedule builds if the source or pipeline has changed" is unchecked, so having no commits should not be the problem.
Strange thing after this problem situation is that when I login to Azure DevOps portal the scheduled event is immediately triggered and I can see that the latest daily build starts running. I don't need to start it manually, it starts automatically like it would be scheduled but at the time I logged in.
This project is running with the free version of Azure DevOps. The project and pipelines have been created when Azure DevOps was VSTS and the same triggering problem was also in VSTS. Sometimes I run out of free quota and then I get an error that the agent cannot be started. This is not the case when the scheduled trigger is not running.
What could cause the problem in triggering by the schedule? Have any of you encountered this same problem? How could I debug or resolve this and get my builds running reliably? I cannot find any debug information about the trigger events, only logs from agent after the trigger has already happened. I have not yet recreated the pipelines to find out if "rebooting" helps in this case. That's my next step if no better answers will come up.
Update 07/11/2019:
We have since updated this logic to give 1 full month of scheduled builds to continue to run without any user activity.
Nightly builds require someone to sign in daily.
From the docs:
My build didn't run. What happened?
Your Azure DevOps organization goes dormant five minutes after the last user signed out. After that, each of your build pipelines will run one more time. For example, while your organization is dormant:
A nightly build of code in your Azure DevOps organization will run only one night until someone signs in again.
CI builds of an external Git repo will stop running until someone signs in again.
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=vsts&tabs=yaml