I am new to this.
When I run the deployment I get this error.
Job issues
1 error
1 warning
An image label with the label Ubuntu16 does not exist.
Under Agent Pools, Microsoft hosted agent job is showing Ubunt-16.04. How and where do I go change the value for this.
Azure Pipeline
I don't know if you are using the classic or yaml pipeline version, but when you are creating the job, you can specify which agent you need.
In the classic version you must choose the correct pool and after that you can indicate the version of ubuntu that you need. I prefer to use the ubuntu latest always
Classic pipeline example:
In the yaml version you just must pass this:
pool:
vmImage: ubuntu-latest
Related
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.
In azure devops i'm getting a warning about the removal of microsoft host agent that uses windows 2016 (vs2017-win2016)
https://github.com/actions/virtual-environments/issues/4312
What i want to know in regards to that, is if on the pipelines agent jobs where the agent specification is set to windows 2016, if they will automatically start using a newer version of windows agent or stop working completly.
The github topic seems to indicate that.
The ones were the agent job inherits from the pipeline, i believe there is no problem, besides that for some reason the task(s) are tied to windows 2016.
And what about the pipelines defined in the Releases section
When i click Create release
will it only fail after i try to deploy a created release?
I think, your pipelines will fail. There was a situation when MS just "friendly" reminded about depreciation:
Check this issue: https://github.com/actions/virtual-environments/issues/4312
Releases also contain the same issue. You have to update their jobs to use the new agent type:
I have created several releases of my backend service in gitlab. Now I want to be able to pick one of them and run the deployment job in my gitlab pipeline on it. SO that the specific version gets deployed. (I'm creating release notes to each release so I can pick which release should now get deployed.)
This is my deployment job in the gitlab-ci.yml:
So far I have used this job like this: When a feature branch was merged into the master and the stand could be deployed and passed all the tests, then the job was triggered manually in the pipeline overview page. Now that I'm using tags to tag each new master version, I want to be able to deploy a version/release from the tags.
Does anyone have an idea how this could work in principle? It would be best if I had a dropdown menu where I can select one of the releases and then trigger the deployment job for it.
The job needs to not get run in the master pipeline, but in the tags pipeline
only:
refs:
- tags
when: manual
This way I can copy the tag of the version that I want to deploy:
and search for it in the pipelines overview page to then trigger the deploy job manually:
We are using Azure Devops with Octopus deploy.
I have integrated the release steps, and release creation as well as release to first environment (Development in my case) is happening without any issue.
Issue is with subsequent releases.
Release fails in Semantic Versioning check of release name.
'1.2.1023.0508-09' is not a valid version string
at Octopus.Client.Model.SemanticVersion.Parse(String value, Boolean
preserveMissingComponents)
In the first stage, I am creating Octopus release, and deploying to Development environment in the same task (using Create Octopus Release task in Azure devops)
create-release "--project=<projectName>" "--releaseNumber=1.2.1023.0508-09" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
This step is successful.
In the next stage, I have tried 2 variations,
Promote Release
promote-release "--project=projectName" "--server=serverName"
"--apiKey=***" "--from=Development" "--to=envName"
Deploy Release
deploy-release "--project=projectName" "--releaseNumber=latest"
"--server=serverName" "--apiKey=***" "--deployTo=envName"
Both of them giving same error, saying release name is not a valid version string.
My confusion is, if the name is incorrect, even the first deployment should fail.
If it's correct and allowed, then subsequent stage release should also succeed.
If any one has faced such a issue before, or can add in some pointers to resolve this issue, it will be very helpful.
This sounds like a bug but I'd need more time to reproduce and verify. Can you share what version of Octopus and the Octopus Extension you are using?
My best suggestion to get going with this is to base the release number off of your Azure DevOps build number and use that variable to control what version is getting deployed. Using the 'latest' version could backfire if you have other releases created in between your stages.
If you can set your Azure DevOps build number to be in the same format that you want your Octopus release number (1.2.1023.0508-09), you can use the following commands to build and promote a release.
create-release "--project=<projectName>" "--releaseNumber=$(Build.BuildNumber)" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"
deploy-release "--project=projectName" "--releaseNumber=$(Build.BuildNumber)" "--server=serverName" "--apiKey=***" "--deployTo=envName"
This will make sure that you are promoting the same release that was created in the pipeline.
Just in case if someone came here looking for solution, below are the steps I took to solve the problem,
For first stage (dev in my case), create a new release. If you have multiple tenants, add them. Do not forget to add Package Version. This is especially needed when you have multiple versions of artifacts getting created. I faced hard time resolving this. if you do not add PackageVersion, latest available artifact is picked.
For further stages, DO NOT promote release. Instead, deploy release. This way, you can pass the same release number as configured in first stage. In my case, I kept the stage name same as my environment name. So I was able to use variable for env as well. I copied this stage for 4 different environments.
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/