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
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)
Clarifications and corrections:
Testing with one self-hosted agent.
By version I mean version of the application. Or any new commit.
The same work directory is being used for builds of different commits, when there are still pending stages (requiring approval) in multiple build runs.
We have Azure an azure devops YAML pipeline with multi stage and approvers. I noticed that running different build versions of the same pipeline uses the same work directory on the build server.
How does this not cause corruption of content, for example if the pipeline runs simultaneously for different build versions?
For example what if the newer pipeline run checks out source code while the other run is building and creating artifacts for its own version? I have checked the current path for two concurrent builds and it is the same.
What will happen if you run two commits in the same agent：
Here is my example of multi-stage pipeline:
pool: Default
stages:
- stage: A
jobs:
- job: A
steps:
- task: PublishPipelineArtifact#1
inputs:
targetPath: '$(Build.SourcesDirectory)'
artifact: 'drop'
publishLocation: 'pipeline'
- stage: B
jobs:
- deployment: DeployWeb
displayName: deploy Web App
pool: Default
workspace:
clean: all
environment: 'env'
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: CopyFiles#2
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: '**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
I added a approve check in the environment. My running order is stage A(commit1)->stage A(commit2)->stage B(commit1)->stage B(commit2) .
stage A(commit1):
This job will checkout source code of commit1 and publish files in Sources Directory of commit1.
stage A(commit2):
This job will checkout source code of commit2 and publish files in Sources Directory of commit2.
stage B(commit1):
It is a deployment job and will not checkout resource by default.
The deployment job will download the artifact of commit1 as expected.
If I don't clean the workspace, it will continue to use the source code of commit2. This may cause some issues.
If I add a checkout step in this stage. It will checkout the source of commit1.
So you can add checkout step and clean workspace to the deployment jobs. Nondeployment jobs automatically check out source code and it will use the correct source.
What I want to achieve:
I have a repository on Azure DevOps which hosts my web application. I wrote a test suite for UI Automation using Cypress. I created a separate repository for my test cases to check if they are working properly or not. I created a pipeline which has the following content:
trigger:
- manual-tests
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
displayName: 'npm install'
- task: Npm#1
inputs:
command: 'custom'
customCommand: 'run test'
continueOnError: true
- task: PublishTestResults#2
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/test-output-*.xml'
testRunTitle: 'My Test Cases'
I have a trigger set to a branch of the repository in which my UI Automation code is stored. What I want is, to trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this? Can we store our test case files in the application repository and give the path of the test script?
It seems that the UI Automation Repo and Web Application Repo are two separate repos.
To trigger my automation script, when there is a push on some branch of the web application repository. Is there a way of doing this?
The function: "trigger a pipeline from a different repo" is not available now.
This feature is still under development. Multi-repository support for YAML pipelines will be available soon for azure devops service.
Please check the function:"Multi-repository support for YAML pipelines" in Azure DevOps Feature Timeline 2020 Q2. This feature will roll out to everyone by the end of July 2020.
Workaround：
You could try to use the Pipeline triggers.
Here are the steps:
Step1: Create a pipeline with web application repository, then you could set the trigger branch.
Step2: Add the Pipeline trigger in the Yaml file (UI Automation Repo).
For example:
resources:
pipelines:
- pipeline: Name
source: Pipeline name
trigger:
branches:
- releases/*
- master
When you make changes in web application repository, the pipeline with the web application will be triggered.
After running the pipeline , the pipeline with UI Automation repo will be triggered.
Can we store our test case files in the application repository and give the path of the test script?
Of cource. You can do it.
If you want to use the test file in the pipeline (UI Automation repo), you could add the repo resouces in the pipeline.
For example:
resources:
repositories:
- repository: MyAzureReposGitRepository
type: git
name: MyProject/WebapplicationRepo
...
steps:
- checkout: MyAzureReposGitRepository
Note: the repo will be check out to the Agent Source Folder.
Hope this helps.
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
In Azure DevOps we have created both build and release pipeline using classic way and now we are planning this to convert to yaml file.
But it seems in yaml method, the code can be put only on the root of the repo, where we want to keep the build yaml files in a separate repo, where the developers won't have access.
How can achieve this?
You can use templates, put in the main repo only the minimal yaml that refers to a template with all the steps, the template exits in another repo.
For example, your main repo yaml:
resources:
repositories:
- repository: templates
type: git
name: Contoso/BuildTemplates
jobs:
- template: common.yml#templates # Template reference
In in the repo: Contoso/BuildTemplates put the full yaml:
# Repo: Contoso/BuildTemplates
# File: common.yml
parameters:
vmImage: 'ubuntu 16.04'
jobs:
- job: Build
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
Restrict the access to the second repo (unless the agent pipeline user).
Read here more info about the resources.
I agree that one solution could be the one proposed by #Shayki Abramczyk
but to have standalone *.yml in dedicated repository you can use 'git clone' while using 'Git Credentials' to access the other repository that contains the files you want to build by the pipeline.
If your repository dedicated for *.yml is in the same Azure Devops project then you should not have any problem with the release definition.
Please see example *.yml that works for us as described:
pool:
vmImage: 'your-preferred-image'
variables:
solution: '$(Agent.BuildDirectory)/**/YourSolution.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Debug'
urlWithCreds: 'https://YourUser:YourPassword#dev.azure.com/YourOrganization/YourProject/
_git/YourOtherRepository'
steps:
- task: CmdLine#2
inputs:
script: |
git --version
git clone --quiet $(urlWithCreds)
git checkout master
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: 'your build args'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
You don't have to keep the YAML files in the root of the repository; ours are in a dedicated sub-folder:
That's crucial, because it means that we can add a PR policy which restricts who can approve changes to any of the pipeline YAML files.