Added a new VSTS extension to vsts marketplace https://marketplace.visualstudio.com/items?itemName=ManishSingh.soapuiazure&ssr=false#overview
I am able to install this extension on organization but not able to see this in task list to add in pipeline.
Got some way to fixed this on internet like uninstall and reinstall - Didn't worked
Disabled and enable - didn't worked.
The extension uses the deprecated PowerShell v1 execution handler for Azure Pipelines and needs to be upgraded to the Powershell3 execution handler. The v1 handler is from the era of the v1 agent that shipped in 2015 and was replaced by a complete rewrite in the summer of 2016.
##[warning]Task 'SoapUI on Azure' (2.0.6) is using deprecated task execution handler. The task should use the supported task-lib: https://aka.ms/tasklib
For me the task fails to show up in the YAML task helper, but it does show up in the classic UI based pipelines and releases.
You may be able to just make it work when using the Get YAML helper in the classic UI:
steps:
- task: ManishSingh.soapuiazure.5ad1e1bc-7ee6-49c8-b12f-7b7606c5b0e4.SoapUI on Azure#2
displayName: 'SoapUI project.xml'
Then simplify that to:
steps:
- task: SoapUI on Azure#2
displayName: 'SoapUI project.xml'
^^^^
Tested this and it works.
But it looks like this extension could use some love. I already see a few things wrong with it:
Using deprecated task handler
always downloads SOAPUI from blob storage (useful for Hosted agents, but not for persistent agents)
Manifest issues
space in Task Name (task.json)
guid in Task ID (in vss-extension.json)
Some of these are likely unfixable, cause the marketplace makes it very hard to change identifiers once the task is published publicly.
Test to install the same extension and it will show the task: Soap UI on Azure in the task list.
For example:
You can add the task to Agent Job or Deployment Job.
On the other hand, if you are not able to find the task after installing it, you can try to open a Browser InPrivate Window and use the same steps to search the task in Azure Pipeline.
Related
I have
developed a skeleton Android App in Android Studio
the Build pipeline in Azure DevOps
An Internal Testing track for this app on my Google Dev Console
Uploaded MANUALLY via the GUI of the Google Dev Console the signed .aab bundle produced
via Android Studio to the Internal Testing Track
The testers that had been set up for the track have been able to install the app on their devices and test it
The steps above work fine.
I then implemented the following
Created a Release Pipeline in Azure DevOps using the editor (not in YAML)
In this Release the Google Play Release Bundle plugin has been used (see pics
below) with its Track Property set to "Internal test" as per the available dropdown
value
Added a Deploy Stage following this Release (see pics below).
However, when the Release pipeline runs I get the error in the title (Only releases with status draft may be created on draft app.) that is also visible in the screenshots below.
I read the SO posts below
Only releases with status draft may be created on draft app
ERROR: Only releases with status draft may be created on draft app
and also articles/documentation like the following
Trigger Azure Pipelines with Postman and Parameters
Release pipelines - What is a draft Release
Releases - Create
How do I specify variables I want to edit when a release is created?
Publish to Google Play Store
I suspect that to remove the error I need to somehow create a release such that
isDraft = true;
that is a draft release that would not be rejected on deployment by the Azure Dev Console Internal Testing Track, but I am a bit at loss with it as I would have expected the Google Play Release Bundle plugin to take care of this detail for me but something apparently goes wrong or I do not clearly understand and I cannot figure out what it is or how to approach this problem in the best/simplest way.
I am running my Selenium tests from Azure Test Plans in DevOps. When any of my test fails, I have the option in DevOps to create a bug for it**(attaching the screenshot of the option to create a bug manually once the test case fails)** but I want the bug to be created automatically as soon as the test case fails. Is there a way to configure it so that my work item(bug) gets created automatically?
There is an option to create a work item on failure in build pipeline as below, so you could enable it to create a bug when this build is failed.
In addition, if you run test plan in release pipeline, this option is not available in release pipeline, so you need to use API to create a work item in it. You could use Powershell Task to run Rest API: Work Items - Create to create a work.
Set the condition
Or you could directly use this Extension- Create Bug on Release failure.
For the YAML pipeline, you can use the CreateBug task:
Example task:
- task: CreateBug#2
inputs:
isyamlpipeline: true
custompaths: false
customrequestor: false
Link: https://marketplace.visualstudio.com/items?itemName=AmanBedi18.CreateBugTask
When deploying to an Azure functions app using the devops task AzureFunctionApp#1, there is an option to supply a runtimeStack. When I choose JavaScript it automatically inserts the runtimeStack as shown below
- task: AzureFunctionApp#1
runtimeStack: 'DOCKER|microsoft/azure-functions-node8:2.0'
My linux functions app is running node 12/runtime 3.0 and the deployment is zip. This is inserted as node8 and runtime 2.0. Is this correct? It doesn't match the version I am using but the Azure editor highlights it as an error if I change it to anything else.
Answering my own question here, but looks like this is a bug in the azure tasks UI and will be fixed soon
https://github.com/microsoft/azure-pipelines-tasks/commit/ae348864ae539a2c84c49b1e6bd499ce92b90356
If I recall correctly, Azure Devops was set to add a feature to allow release pipelines to be placed into yaml , similar to build pipeline. Is this feature available yet?
Im hoping to get some guidance on the migration of legacy classic release pipeline, to the new format?
UPDATE: It looks like I'm only about 4 months behind. Posted on May 6, 2019
With our new updates, development teams can now leverage the same YAML documents to build multi-stage pipelines-as-code for both Continuous Integration and Continuous Delivery. This was one of the biggest requests from our customers
here are some helpful links for those that are like me : have many classic release pipelines manually created, interested in the new format.
https://azure.microsoft.com/en-us/updates/unified-pipelines/
https://azure.microsoft.com/en-us/blog/accelerating-devops-with-github-and-azure/
For migrating release classic pipelines, Azure DevOps still lacks some more straightforward support.
But there is an external tool, yamlizr, for helping migrate many release pipelines.
In my case I had to hack a bit the tool (see its issues if they are still opened).
The result is not production ready, but is still a good starting point from my viewpoint, and helps a lot.
I've discovered that Microsoft provides some built-in help to migrate a release pipeline from a classic GUI-based Release pipeline to a YAML-based pipeline.
If you edit your classic GUI-based Release pipeline and drill down to a task, there is a link at top right that says View YAML:
Clicking the link generates the YAML associated with the task. Unfortunately it doesn't include the field values. Instead it uses variables and doesn't specify the values of those variables:
steps:
- task: IISWebAppManagementOnMachineGroup#0
displayName: 'IIS Web App Manage'
inputs:
IISDeploymentType: '$(Parameters.IISDeploymentType)'
ActionIISWebsite: '$(Parameters.ActionIISWebsite)'
WebsiteName: '$(Parameters.WebsiteName)'
WebsitePhysicalPath: '%SystemDrive%\inetpub\wwwroot\AspNetDemo'
AddBinding: '$(Parameters.AddBinding)'
Bindings: '$(Parameters.Bindings)'
ParentWebsiteNameForVD: '$(Parameters.WebsiteName)'
VirtualPathForVD: '$(Parameters.VirtualPathForApplication)'
ParentWebsiteNameForApplication: '$(Parameters.WebsiteName)'
VirtualPathForApplication: '$(Parameters.VirtualPathForApplication)'
AppPoolName: '$(Parameters.AppPoolName)'
Luckily the task in the GUI has links against most fields, with field-specific help. That help mentions which variable maps to the field value:
So you can go through each field in the task determining which variable corresponds to each field, to work out what values to add to the YAML snippet.
It's a bit labour intensive but it's quicker than trying to figure it all out from scratch.
Unfortunately there doesn't seem to be any way to view the YAML at the job or stage level, only at the task level. So you'll have to repeat the process for each task. You'll also have to work out the YAML that defines the stage and the jobs yourself.
Create a new multi-stage pipeline-as-code.
https://azure.microsoft.com/en-us/updates/unified-pipelines/
https://azure.microsoft.com/en-us/blog/accelerating-devops-with-github-and-azure/
I'm using an Azure DevOps Pipeline to release an ASP.NET MVC system to an Azure Web App.
I've configured the build not to apply the XML transforms, so I can apply them later, during the release step, and the same build artefact can be released to multiple environments.
The build works fine, and I end up with an artefact containing an untransformed web.config, and the environment-specific transform files.
The Azure App Service Deploy task has a check-box called XML Transformation, which displays the following help text:
The config transforms will be run for *.Release.config and
*.<EnvironmentName>.config on the *.config file. Config transforms will be run prior to the Variable Substitution. XML transformations
are supported only for Windows platform.
At the moment I'm trying to set up a release into a test environment, but the Web.Release.config is being applied, rather than the Web.Test.config. I've searched everywhere I can find for a place to define the environment to make the release use the test config, but I can't find anywhere.
There's a similar question on GitHub which shows the following screenshot:
Unfortunately mine doesn't look like that:
Am I trying to do the right thing? If so, where do I set the environment?
You need to make sure your stage name is just 'Test' and not 'Deploy EMS to Test', reference here.