I was trying to fix an issue with my build pipeline in Dev Ops, but for some, reason all the tasks on all the pipelines have been removed. I get the error 'This task is no longer installed' on all tasks.
I have tried to revert the pipeline to the last good known configuration, with no success.
Also, I am unable to remove the task and reinstall them as they do not appear in the task list.
Any help is greatly appreciate as it is driving me insane!
UPDATE
Here is the setting for the Pool
After some help in the form of an Azure Support Ticket, the solution as simple.
Go to your Organization Settings > Pipeline > Settings and make sure that Disable built-in tasks is disabled
Related
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.
My pipeline name is set as
name: $(Date:yyyyMMdd)$(Rev:.r)
this works but Azure Pipelines still includes the commit message in my pipeline name. For example, the pipelines UI shows:
#20200422.2 The commit message
is there a way to get Azure Pipelines to just use the name I specified?
Thanks.
is there a way to get Azure Pipelines to just use the name I specified?
Sorry for any inconvenience.
This behavior is by designed and is not a bug. I do not believe there is a way to set Azure Pipelines name without submit message.
Including the submit message in the name of the pipeline helps us find the cause of the pipeline failure faster.
For example:
Just like above build history, We could directly judge the cause of the failed pipeline by the same submit information, not from the code update, more from the task settings and pipeline settings.
On the other hand, We could judge that the pipeline failure may be due to the update of the code according to the different submit information. Then we check the submit record through the submitted history, and we will quickly know which code we have modified to cause the build to fail, which provides great convenience.
This is especially important for those pipelines that enable CI.(
Enable continuous integration).
Hope this helps.
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 am using Azure DevOps pipelines releases to try to deploy a windows service on premise. Periodically, the windows copy files step will hang and try again every 30 seconds and output "The process cannot access the file because it is being used by another process" as it attempts to copy the build artifacts.
We've ruled out any kind of permission issue. We've tried all sorts of tools to see what might be locking these files up and they don't tell us much.
This has happened before in the past with some other projects I was also trying to release on premise. Sometimes, I am able to just wait an hour or two and redeploy successfully (not exactly a solution I'm satisfied with), but this one particular project, a windows service, seems to be experiencing the issue very, very frequently. Almost every time I try to deploy.
Has anyone else experienced this? Or any word from Microsoft on the issue?
Thanks in advance.
I experienced this issue while trying to create and deploy a release from an existing artifact. So I have a build pipeline on Azure Devops that generates artifacts to be used by the release pipeline. All I did was to make a commit that triggered the build pipeline which generated a new artifact and triggered the release and it worked fine.
It was the first time I experienced this and I had no clue on why it happened.
I'm going to be doing more research and share any thing I find helpful.
I might be doing something wrong, but I have created a Build and a Release in VSTS. For the release I need to execute a task only if one of the previous failed. This is easy for the tasks in the Build, there is a dropdown with several options including "Only when a previous task has failed", however for the release, I only have Always run and continue on error, which doesn't work for me.
Is this because the control options for release doesn't support the same options as the build or is something missing for my VSTS?
Task conditions aren't yet an option for tasks used in releases.