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.
Related
We have an on-premises, TFVC setup with Azure Devops 2019. We use the "Classic Editor" to create our pipelines since YAML does not support the TFVC repository:
https://developercommunity.visualstudio.com/t/enable-yaml-for-tfvc/234618
In the "Triggers" section, we have both options checked:
However, the result is that the build never gets queued when a checkin occurs. If I uncheck the "Batch changes" option, then the build gets queued on every checkin (as expected).
We have two build servers with Windows Server 2019. One has two build agents while the other has four. Both servers exhibit the same issue.
I have tried everything I can think of to get the batch feature to work: toggling "Clean" in the "Get sources" task, toggling "Clean" for the solutions, fiddling with Path filters (adding more specific ones, setting higher level ones), ordering of tasks, etc., but nothing seems to work.
Trial and error is not working but I'm not even sure how to debug this issue. Does anyone have any ideas as to where to look to figure out why the batch feature isn't working? Anything else to try?
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
I am new to using Azure DevOps builds/pipelines, as the source code for the solutions I need to build are in TFVC I am limited to using the Classic (i.e. UI) builds rather than YAML.
When I want to test changes to a build definition I sometimes want to run a clean build, i.e. ensure that sources and artifacts from earlier builds are removed before the new build run, yet leave normal builds (i.e. ones triggered by changes in TFVC) to be incremental so to make builds faster.
I am used to TeamCity which has a plethora of options with regards to managing source and artifacts retention between builds, including a simple "clean" check box when triggering a manual build.
ADO Builds seems very limited in this regards and if I want to have a clean build it seems the only option is to change the build definition, select clean, run the build, then change the build definition again to remove the clean option.
Are there better ways to manage "ad-hoc" clean sources and artifacts in ADO Builds?
Those settings are either on/off. They wouldn't accept conditional run-time variables.
That being said, you might try leveraging the "Save as draft" option. It seems to create a DRAFT pipeline definition you could execute for your changes.
You could probably just flip it back to no clean before publishing. I don't really use that feature, but I am going to guess on the back-end it is using a different temporary definition id. That will probably mean on the build agent a new folder gets created under _work. If that is the case, you probably wouldn't even need to flip the clean sources since it will not exist the first run. It also probably means if this a self-hosted agent you will have doubled the work folder size and you might have to manage that clean-up after you are done.
If it does create the second work folder, this is probably preferable as it means you won't break the incremental build on the build directly following your test with clean. Whether you did that ad-hoc or through editing the build definition.
Build.Clean variable is deprecated, you can only use Clean option to clean local repo on the agent currently.
I'd like suggest you submit a user voice at website below, product team will evaluate it carefully:
https://developercommunity.visualstudio.com/content/idea/post.html?space=21
One workaround is adding a Post Build Cleanup task in the end of your pipeline, when you want to run builds incrementally, you can disable this task.
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.
I am trying to create a Visual Studio Team Services Extension Task for my builds and releases. I need a task that will send out an alert to another system if a previous task (including the default build/test/publish/etc.) fails.
I have already created the task to send the alert. However I do not see a way to kick off the task only if my build fails.
Is there a way in VSTS to run a task if a previous task fails, but not run it if all other tasks were successful?
It is now possible to select a running condition for all tasks with the following possible values:
Only when all previous tasks have succeeded
Even if a previous task has failed, unless the build was canceled
Even if a previous task has failed, even if the build was canceled
Only when a previous task has failed
Custom conditions
EDIT:
It is currently part of a preview, you can enable it through the "Preview features" menu after you click on your profile click on VSTS:
And activate the "New Build Editor":
There is no built-in feature.
But you can use the "Rollback" task from the Release Management Utilities to run a powershell script on failure.
https://marketplace.visualstudio.com/items?itemName=ms-devlabs.utilitytasks