How can I trigger my build on Azure DevOps using YAML file?
I did a merge on my master branch. Build was tiggered.
Then I did a pull request from master to
release/development
release/staging
release/production
in this order. Only the merge on release/production triggered the build.
Why? To make sure it is not just a question of the correct version of the YAML file on the correct branch I repeated these actions a second time. Same result.
# 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:
branches:
include:
- master
- release/production
- release/development
- release/staging
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
name: $(Date:yy).$(Date:MM).$(Rev:r)
variables:
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: $(Solution)
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: $(Solution)
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: VSTest#2
displayName: 'Test Assemblies'
inputs:
testAssemblyVer2: |
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
diagnosticsEnabled: True
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
condition: succeededOrFailed()
Why the master and production build are starting and not the other one?
Check if you have set the trigger on the web UI for the build pipeline. The triggers set on the web UI will override that set in the YAML files.
If the triggers set on the web UI only includes the master and release/production branches, the pipeline will only be triggered for the two branches.
To avoid this, you can disable the triggers set on the web UI and only keep the triggers set in the YAML files.
Did you merge yaml to other branches? The build may not start if it is not in a branch. An example of the development branch:
Related
I'm trying to publish a couple of pipeline artifacts during a build so that I can use them in a build of another solution.
My first build builds and tests the soltuion using the following yaml
- stage: build_test_release
displayName: Build
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
jobs:
- job: build
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- 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)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
This all works great and I've been able to do deployments using this yaml in the same file
- task: AzureRmWebAppDeployment#4
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'azuresubscription'
appType: 'webApp'
WebAppName: 'webappname'
deployToSlotOrASE: true
ResourceGroupName: 'resourcegroupname'
SlotName: 'staging'
packageForLinux: '$(build.artifactStagingDirectory)/**/projectToPublish.zip'
I'm now trying to publish some of the projects which were build as Pipeline Artifacts so that I can use them in the build of another solution which references them. The following publish task gives me the error:
"##[error]Path does not exist: D:\a\1\a**\projectToPublish.zip"
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(build.artifactStagingDirectory)/**/projectToPublish.zip'
artifact: 'artifactname'
publishLocation: 'pipeline'
What am I missing here? I've been thinking of moving the projects which are referenced by both soltuions into their own solutions and adding them as nuget packages or something similar. The projects I am trying to publish as artifacts to be used in the second solution are both WCF Client projects.
Thanks!
The issue is that the task you're using, Publish Pipeline Artifacts, does not support wildcards for the 'File or directory path' argument. For this task $(build.artifactStagingDirectory) is replaced with D:\a\1\a\, in the second directory named a Azure DevOps is looking for a sub directory named ** which does not exist and causes the shown error. The other task AzureRmWebAppDeployment#4 you're using does support wildcards.
See the image below, where Azure DevOps shows in the the UI that the PublishPipelineArtifact#1 task does not support wildcards in targetPath:
Second I'm wondering why you're using a wildcard, because the task VSBuild#1 will just drop the package in the build.artifactStagingDirectory which should make the path $(build.artifactStagingDirectory)/projectToPublish.zip to locate the package.
In AzureRmWebAppDeployment#4 you have
'$(build.artifactStagingDirectory)/**/WebProjectToPublish.zip'
And in PublishPipelineArtifact#1 you have a different name
'$(build.artifactStagingDirectory)/**/projectToPublish.zip'
I would like to have a pull request launch a build and that build must succeed before merging into the target branch is allowed.
I have master and develop branch and create feature branches from develop. work is completed and then a pull request initiated to merge back into develop.
I have created a build pipeline that completes successfully when run manually.
I have specified in the branch policies for the develop branch that the build must be run and complete successfully.
Now when I create a pull request, it says that in order for the pull request to be approved, the build must run but it does not run the build. What am I doing wrong?
This is a c# .net framework app.
Should I be saving the yaml in the develop branch or master? That part confuses me. Is the trigger correct?
This is my yaml for the build pipeline:
trigger:
- develop
pool:
vmImage: 'windows-latest'
name: '1.0.1.$(Rev:r)'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- checkout: git://OvaFlow/Utilities#develop
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: VersionAssemblies#2
inputs:
Path: '$(Build.SourcesDirectory)'
VersionNumber: '$(Build.BuildNumber)'
InjectVersion: true
FilenamePattern: 'AssemblyInfo.*'
OutputVersion: 'OutputedVersion'
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Build.SourcesDirectory)/Utilities/packages.config'
feedsToUse: config
nugetConfigPath: '$(Build.SourcesDirectory)/NuGet.config'
restoreDirectory: '$(Build.SourcesDirectory)/packages'
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Build.SourcesDirectory)/UtilitiesTests/packages.config'
feedsToUse: config
nugetConfigPath: '$(Build.SourcesDirectory)/NuGet.config'
restoreDirectory: '$(Build.SourcesDirectory)/packages'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
inputs:
solution: '$(Build.SourcesDirectory)/Utilities.sln'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
inputs:
testAssemblyVer2: |
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
codeCoverageEnabled: true
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
continueOnError: true
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
Contents: '**\bin\$(BuildConfiguration)\**'
TargetFolder: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
Should I be saving the yaml in the develop branch or master? That part confuses me. Is the trigger correct?
The answer is yes! In fact, you have already found the answer.
As we know from the Build validation:
Set a policy requiring changes in a pull request to build successfully
with the protected branch before the pull request can be completed.
Build policies reduce breaks and keep your test results passing. Build
policies help even if you're using continuous integration (CI) on your
development branches to catch problems early.
So, the build validation used for the branches which you want to protected, the .yml should saved in the branch which you set the build policy.
As test, if I set the .yml file under the Test branch, then pull request for the dev branch, the build will not be triggered automatically:
Then, I moved the .yml file to the dev branch with a new build pipeline, it works fine:
Hope this helps.
If build is not configured to run automatically on push, you have to run it manually, here:
Or you can configure build to trigger automatic on branch update:
Our DevOps Pipeline has versioningScheme set to off in the nuget pack command (options for that are documented here), and we're using the AssemblyVersion attribute in the AssemblyInfo.cs file to specify NuGet package versions. E.g.,:
[assembly: AssemblyVersion("1.9.14")]
We have a DevOps Pipeline setup that, when we merge code into our Git "develop" branch, will automatically perform a Debug build and publish to our private NuGet repository. The NuGet package version will match the AssemblyVersion attribute's value.
We have another DevOps pipeline that will do the same for the Master branch, but the build will be in Release mode.
We would like to have the Pipeline for the "develop" branch automatically append a string, e.g., "-beta" or "-dev", so that we can easily distinguish our pre-release builds, that are built in Debug mode, from the release builds. I've reviewed the YAML for our pipeline and I have been unable to figure out how to do that when you're using the AssemblyVersion (or AssemblyInformationalVersion) attribute. Is this possible? Or would we need to switch to a different technique for specifying versions?
YAML for our current Pipeline is below:
# 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:
- develop
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- 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)'
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: NuGetCommand#2
inputs:
command: 'pack'
packagesToPack: 'DataAccessLayer/DataAccessLayer.csproj'
versioningScheme: 'off'
- task: NuGetCommand#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: '2ba68ed5-dcd7-40e3-8b6b-06972c41ec5e'
versioningScheme: 'off' in the pack step is the issue, it means there is no way to override the package version passed to the nuget pack command.
Rather than setting the version number explicitly in the assembly info file, an alternative solution is to just specify the major minor version and let Azure Devops calculate the next patch version with a counter expression, then setting the build number to major.minor.path:
variables:
majorMinor: 1.10
patch: $[counter(variables['majorMinor'])]
steps:
- task: PowerShell#2
displayName: 'echo patch (debug)'
inputs:
targetType: inline
script: echo $(patch)
- task: PowerShell#2
displayName: 'update build number to major.minor.patch'
inputs:
targetType: inline
script: |
if ("$(Build.SourceBranchName)" -eq "master") {
echo "##vso[build.updatebuildnumber]$(majorMinor).$(patch)"
} else {
echo "##vso[build.updatebuildnumber]$(majorMinor).$(patch)-alpha"
}
You can then make use of the BUILD_BUILDNUMBER environment variable in your nuget pack step:
- task: NuGetCommand#2
inputs:
command: 'pack'
packagesToPack: 'DataAccessLayer/DataAccessLayer.csproj'
versioningScheme: byEnvVar
versionEnvVar: BUILD_BUILDNUMBER
I am new to DevOps and CICD pipelines.
I successfully deployed ASP .NET MVC website using Azure DevOps CICD pipeline to my onprem agent/machine using Azure DevOps.
Similarly I want to deploy a console application which can be
ultimately used as scheduled job in windows 'Task Scheduler' or either
as a 'Windows Service'. Right now I am managing these deployments
manually but after seeing the power of DevOps I hope, there could be
really some automated solution for console apps as well.
The applications are built in legacy framework like 3.5 to 4.5, so not .net core apps.
I found lot of online articles which demonstrates deploying webjobs on azure or may be possible for onprem but is it possible for old console apps?
I tried to build a very simple console app in Framework 4.7 and tried to deploy/copy/publish to my onprem machine's shared path. Gave permission to VSTS agent services which are running but copy files and publish artifact tasks are failing. I tried to do it in both CI and CD pipelines but all are failing.
Please review the pipelines and logs and suggest where I am doing wrong or there are any alternatives?
https://dev.azure.com/MSTCsandippatel/DemoConsoleApp
2019-11-05T05:03:52.8436105Z ##[error]Publishing build artifacts
failed with an error: Unable to create directory '\MAHANTAM\Azure
Artifacts\DemoConsoleApp'. Unable to verify the directory exists:
'\MAHANTAM\Azure Artifacts\DemoConsoleApp'. If directory is a file
share, please verify the share name is correct, the share is online,
and the current process has permission to access the share.
CI pipeline 1
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)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=True /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'DemoConsoleApp'
publishLocation: 'Container'
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)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=True /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'DemoConsoleApp'
publishLocation: 'Container'
CI pipeline 2
pool:
name: Azure Pipelines
demands:
- msbuild
- visualstudio
steps:
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
vstsFeed: '622d44e2-69d4-4d42-bb91-9d6ddd97f9ba/8eaf9077-829d-4567-93c0-8e0d7973634b'
- task: VSBuild#1
displayName: 'Build solution **\*.sln'
inputs:
solution: '$(Parameters.solution)'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: CopyFiles#2
displayName: 'Copy Files to: $(build.artifactstagingdirectory)'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
Contents: '**\bin\$(BuildConfiguration)\**'
TargetFolder: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
- task: CopyFiles#2
displayName: 'Copy Files Task'
inputs:
SourceFolder: '$(system.defaultworkingdirectory)'
Contents: '**/**'
TargetFolder: '$(build.artifactstagingdirectory)'
condition: succeededOrFailed()
- task: ArchiveFiles#2
displayName: 'Archive $(Build.BinariesDirectory)'
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: DemoConsoleApp'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: DemoConsoleApp
If you use Agent Pool "Azure Pipelines" for your agent, the deployment will occur on an azure cloud machine which doesn't know anything about your on-premise machines.
You should install a self-hosted agent on-premise and link that to your DevOps and use that for the agent.
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
I want to create packages to load to the store.
Here is the YAML so far
trigger:
- master
pool:
vmImage: 'VS2017-Win2016'
variables:
solution: '**/*.sln'
buildPlatform: 'x64'
buildConfiguration: 'Release'
appxPackageDir: '$(build.artifactStagingDirectory)\AppxPackages\\'
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '**\*.sln'
feedsToUse: config
nugetConfigPath: 'MyApp.Win10/mynuget.config'
- task: VSBuild#1
inputs:
platform: 'x64'
solution: '**\*.sln'
configuration: '$(buildConfiguration)'
msbuildArgs: '/p:AppxBundlePlatforms="$(buildPlatform)" /p:AppxPackageDir="$(appxPackageDir)" /p:AppxBundle=Always /p:UapAppxPackageBuildMode=StoreUpload'
The docs mention the Artifacts explorer on the Artifacts tab of the builds results page. But I cant find it.
I have also looked at the Artifacts in the project but they only contain some nuget packages I put there.
You don't see the artifacts becuase you don't have the "Publish Build Artifacts" task.
For example, add this task:
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(appxPackageDir)'
artifactName: 'drop'