I have 2 ways to build a pipeline on Azure DevOps, with YAML pipeline template or with Tasks preset in Classic Editor(which can be converted into Task Group as well).
If I select the same template in either one of these ways, the same task in the Classic Editor could be missing from its YAML pipeline template counterpart.
I selected .NET Desktop with both ways.
https://i.imgur.com/2fGcZ14.png
In Classic Editor, I could see 2 of these publishing tasks as seen below.
https://i.imgur.com/yxYxD44.png
With YAML Pipeline, the 2 tasks seen above are missing though.
# .NET Desktop
# Build and run tests for .NET Desktop or Windows classic desktop solutions.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/windows/dot-net
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
I can't figure out why this is happening though. Appreciate some help or pointers on this, thanks in advance.
Both those tasks are not missing, but you might need to manually add them.
Publishing artifacts is no long a standalone task, it's become part of the core capability of YAML pipelines, so it's effective a native step called publish
steps:
- publish: output/files # path to files/directory containing files you want to publish
artifact: myartifact # Name of the artifact
As for copy files, that's still a task, as documented here
The docs for YAML pipelines are pretty good IMO
As well as a complete reference for the all the built-in tasks
Related
I have an azure devops package feed which was working fine for my purposes, until recently a hard drive failure disrupted operations. Suddenly I found myself unable to push any packages without running into a 401 response. I was able to get it to work eventually after modifying a nuget.config file as described in the answer to this question, but given that this entire process was fairly convoluted, it seems like there should be a much more straight-forward way to set this up when needed. So that in the case I ever need to do this again in the future, and so that I don't have to rely on getting lucky with stack overflow answers, what is the best, most straight-forward method for setting up publishing to azure devops package feeds?
nuget.config is the most commonly used authentication method for push packages to feed. There are two ways to push packages to feed, I think you may need another.
Pipeline push should be a easy way to achieve your requirement.
trigger:
- none
pool:
vmImage: 'windows-latest'
steps:
- checkout: self
persistCredentials: true #This step will do the auth.
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--configuration Debug'
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
versioningScheme: 'byPrereleaseNumber'
majorVersion: '1'
minorVersion: '0'
patchVersion: '2'
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'xxx/xxx'
You just need to 'click' the feed you want push to and then change the step of YAML like the above.
After that, give the permission to pipeline:
Finally, run the pipeline to push artifact to feed:
Each step of this method is very clearly and each time you want to push artifact, you just need to change several settings is ok(Version, Repo that the pipeline based on, artifact name). Create once, use for a long time.
Additional:
How to change the repo that the pipeline based on:
Repository Structure on my side:
Everything of push artifacts:
Publish Nuget packages(NuGet.exe)
Publish Nuget packages(dotnet)
Publish NuGet packages with Azure Pipelines (YAML/Classic)
The issue is described here.
TLDR;
I have a repository with .NET Solution Containing WPF application and WAP project. I created a pipeline to build the solution. The pipeline definition yaml file contains:
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild#1
inputs:
solution: '$(solution)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
When the pipeline runs in the build step I receive an error:
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(823,5): Error : No certificate found with the supplied thumbprint: 7FA3B996D434F774830FF22AE1A157751AFB419E
It is difficult to know the specific cause of this problem, so please try the following:
As the error message says, the error is most likely due to your certificate. Try to generate a new certificate or cancel certificate validation.
Check your .sln file. If it has PackageCertificateThumbprint or PackageCertificateKeyFile parameter, check that it is configured correctly and that you have uploaded the correct certificate file to the appropriate path. Or try to delete the parameter and see if the problem is solved.
Make sure that the agent windows-latest has all the .NET SDK versions you need and all the software your project needs to reference. If not, use the task or command line to download them. Click this link to view the software installed on the windows-latest agent.
Try to run the build project locally. If it is successful, try using the self-hosted Agent. Click this document for detailed steps.
My Wpf app version is .net 5 and I had the same problem.I fixed it in this way in Azure Devops pipeline :
first I removed AppxPackageSigningEnabled and PackageCertificateThumbprint from wapproj file then I installed Code Signing task from azure devops marketplace and then add this task to my build pipeline after msbuild task. it signed my msix without problem.below picture is just a test and of course password should not be visible in not testing case.
How does Azure DevOps identify linked workitems during pipeline (Azure DevOps YAML)?
I believe it is supposed to get only the workitems linked to new commits (i.e. commits which were not included in a previous pipeline)
However, it sometimes seems to link all work items. But this does not always happen. I did not manage to identify the pattern yet. But I noticed that when I do a change in the pipeline YAML, it seems to trigger this behaviour that links all work items again (even if they where linked to a previous commit and not to newly included commits).
Updated to include additional information
This is my build pipeline YAML
name: 03.01.00$(Rev:.r)
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
steps:
- checkout: self
clean: true
persistCredentials: true
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: MySol/MySol.sln
- task: VSBuild#1
displayName: MySol/MySol.sln
inputs:
solution: MySol/MySol.sln
vsVersion: 15.0
- task: WorkItemUpdater#2
inputs:
workitemsSource: 'Build'
workItemType: 'Task,Bug'
updateAssignedTo: 'Never'
updateFields: 'Microsoft.VSTS.Build.IntegrationBuild,v$(Build.BuildNumber)'
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
Pipeline settings:
Processing od new run requests: Enabled
Automatically link work items included in this run: checked & dev branch selected
Triggers:
Override the YAML continuous integration trigger from here: checked
Enable continuous integration: checked
Batch changes while a build is in progress: unchecked
Branch filters
Included dev branch + another feature branch
Path filters
None
I try for several days now to publish my ClickOnce application with Azure DevOps Pipeline. Before going in detail here is what I would like to do from my release view:
I started with one artifact and 2 release stage modifying the config.deploy file with staging variables during my Staging stage and modifying the config.deploy file with production variables during my Production stage. Deployment was working fine but installation of application was not working because of hash check system.
So I decided to create 2 builds with 2 artifacts. I renamed the classic drop by a drop_staging during my first build and drop_production for my second build. I was hoping the build system (MSBuild) was able to select the correct app.Debug.config then app.Release.config file during the build and publish process.
Here is my build definition
Here is my build arguments
/target:publish
/p:ApplicationVersion=$(Build.BuildNumber)
/p:PublishURL=http://app-staging.example.com/
/p:UpdateEnabled=true
/p:UpdateMode=Foreground
/p:ProductName="App Staging"
/p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"
Configuration is set to Staging for first build then on Production for second build. I have, of course, a Staging and Production build definition in visual Studio. I have an app.config with app.Staging.config and app.Production.config in my project.
I cannot simply add a task to transform my config file after the build because I will not respect the hash. I should find a way to say to my build to use the correct XML transformation config file. I don't see any other solution or maybe applying this transformation before the build? Is it possible? What are your solutions?
finally I could solve this by adding a file transform before my build.
In case you need more help here is my YAML detail for transformation
steps:
- task: FileTransform#1
displayName: 'File Transform: '
inputs:
folderPath: App.Example
enableXmlTransform: true
xmlTransformationRules: '-transform **\*.Staging.config -xml **\*.config'
fileType: xml
#Your build pipeline references the ‘BuildPlatform’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971
steps:
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: Example.sln
msbuildArgs: '/target:publish /p:ApplicationVersion=$(Build.BuildNumber) /p:PublishURL=http://staging.example.com/ /p:UpdateEnabled=true /p:UpdateMode=Foreground /p:ProductName="App Staging" /p:OutputPath="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(BuildPlatform)'
configuration: Staging
To add to the build solution stage, you can use your visual studio Publish profile as shown below on the msbuildArgs. Please note this doesn't do the version incrementation for you
- task: VSBuild#1
displayName: 'Publish Project'
inputs:
solution: '$(projectSolution)'
msbuildArgs: '/target:publish /p:ApplicationRevision=$(applicationRevision) /p:PublishProfile="Application/PublishProfiles/HerbalPublishProfile.pubxml" /p:PublishDir="$(build.ArtifactStagingDirectory)\Publish\\"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
msbuildArchitecture: x64
I'm trying to to create a yaml definition file for a simple CI/CD pipeline in Azure DevOps.
My pipeline should look like this:
Is it possible to define the whole workflow in one definition file with different stages and jobs?
How can I determine which project (which GIT sub-path has triggered the build) has changed to proceed with project A/B workflow?
The first workflow with project A seems feasible for me. I can run the sc command together with runsas or psexec to start/stop the service and use a copy file task. But how can I initiate to publish the ASP.NET web application to a local directory (as I would do with VS->Publish->Local Folder)?
After that I guess it's the easiest way to make use of scripts to replace content, install npm packages to minify and bundle js/css files and upload these to a ftp server. Or any better/easier ideas?
If you guys can support me by creating an initial yaml definition just for the workflow without the details of the tasks I would really appreciate that. Maybe I get a more clear vision if you can answer my questions above.
At the moment I have a very simple initial build file:
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master # for a productive deployment after manual approval
- develop # for a automatic test deployment
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
feedsToUse: 'select'
vstsFeed: 'tpcemedia'
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
No, releases are not yet possible in yaml. You can have build stages\jobs, but it makes no sense to use them in such a simple case
Yaml has a path-trigger filter, just configure a build per application. no need to complicate the build with conditions. do something like this:
build1:
trigger:
paths:
include: src/proj1/*
build2:
trigger:
paths:
include: src/proj2/*
Better to separate release and build, this way your release agent will be directly on the server and would be able to restart service locally without the need to have network access (and its more secure). It would also pull the artifacts generated by the build agent "for free".
Why use ftp, just use "publish artifacts" step(s), much easier.