I have a following structure:
Test-A and Test-B projects created on Azure Devops. Test-A project's CI build pipeline will produce an artifact.
Test-B's pipeline uses the artifact produced by Test-A's CI pipeline in its build. I am able to download the build artifact of Test-A project and use it.
The problem I am facing here is I am unable to do a CI automatic trigger with project Test-A dependency in project Test-B i.e when ever I make changes and push the changes on to Test-A github repo or whenever I do a new build on Test-A I want the build for Test-B to start automatically.
I have read the documentation on Azure devops but they are not working.
Link for pipeline trigger
Link for pipeline multi-trigger
Below is my .yml file.
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
resources:
pipelines:
- pipeline: JustAName
project: Test-A
source: Test-A_CI
branch: master
trigger:
branches:
include:
- master
repositories:
- repository: justAnotherName
type: github
name: myGitRepo
endpoint: myGitServiceConnection
trigger:
branches:
include:
- master
steps:
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'specific'
project: 'hashValue or Test-A'
definition: '1'
specificBuildWithTriggering: true
buildVersionToDownload: 'latest'
targetPath: '$(Agent.BuildDirectory)'
I am not sure where I am doing wrong or if it is a permission issue. I checked the logs to find any reference with the resources part in the yml but I had no luck.
Can someone suggest what is the best way to check what is the problem and resolve the issue.
Build completion option is disable in classic editor
The build completion option in the pipeline classic editor is limited to the pipelines within the same project. So it won't work for your scenario(the triggering pipeline and triggered pipeline reside in different project) even if it is enabled.
For issue build completion option is disabled. You can report this issue here. Click report a problem and select Azure Devops.
Resources pipeline trigger doesnot work properly sometimes. This similar issue has submitted to Microsoft by some other users. You can follow and vote on these cases or create a new one. Build Completion Triggers not working, Pipeline trigger not working as expressed in documentation
You can follow the workaround which using task TriggerPipeline given by #Hugh. You can also add a powershell task to call the rest api to queue another build pipeline. You can check this thread for example scripts
For your issue , there is a custom task in the Azure DevOps marketplace: Trigger Azure DevOps pipeline.
With this task you can trigger a build or release pipeline from another pipeline within the same project or organization but also in another project or organization.
To get started a PAT is needed with the appropriate rights to execute pipelines. Give the PAT the following rights depending on your scenario:
Triggering a Build: Build – Read & execute
When you have installed the extension, you can add this task into yaml. In the task setting ,you need to connect to a Azure DevOps Service connection. For detailed configuration, please refer to this.
steps:
- task: TriggerPipeline#1
inputs:
serviceConnection: 'triggerpipeline'
project: 'Test-B'
Pipeline: 'Build'
buildDefinition: 'xxx'
Branch: 'master'
Related
I'm trying to implement azure automatic pipeline build with azure-pipelines.yaml
i have tried the below methods in order to get it work.
azure-pipelines.yaml(yml)
.vsts-ci.yml(yaml)
.azure-pipelines.yaml(yml)
But when I'm trying with UI it's detecting.
Is it possible to build auto build pipeline in Azure-devops?
If you're building a GitHub repo in an Azure DevOps pipeline, there's some stuff you need to setup.
Azure Pipelines can automatically build and validate every pull request and commit to your GitHub repository. This article describes how to configure the integration between GitHub and Azure Pipelines.
If you're new to Azure Pipelines integration with GitHub, follow the steps in Create your first pipeline to get your first pipeline working with a GitHub repository, and then come back to this article to learn more about configuring and customizing the integration between GitHub and Azure Pipelines.
Source: Build GitHub repositories.
If you explicitly need a DevOps Pipeline to build your GitHub repo, have a look at the article linked to above. Otherwise think about either working with GitHub Actionshttps://github.com/features/actions on your GitHub repo, or hosting your repo in Azure Repos.
Depending on where your repository is located you should place your .yml file inside this repository in order to work with the trigger. You should also use the trigger keyword.
Then when you create your pipeline, you will choose Github, Azure Repos Git, whatever you use and select existing pipeline.
If you use the starter pipeline of Azure Devops, the pipeline will trigger out of the box when a commit is pushed on the main branch.
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
- script: |
echo Add other tasks to build, test, and deploy your project.
echo See https://aka.ms/yaml
displayName: 'Run a multi-line script'
You can change main to which ever branch you need to trigger automatically.
I have 3 Yaml Pipelines:
CI1 that should be build on any commit to services/* branches
CI2 that should be build on any commit to services-release/* branches
CD that should do the deployment of the artifacts created by CI2
CD is setup the following way:
YAML Settings
Triggers Settings
As you can see, I've tried different formats of the branches to branch filters. Even if I add non-wildcard filter, I still see the following behavior:
CD pipeline is triggered after CI2, triggered by commit into services-release/* branch (which is correct), but it releases latest build from a branch, specified in "default branch for manual and scheduled builds" dropdown - which is develop in my case.
What should I change to deploy the artifact that was generated by CI2 build from services-release/* branch?
Judging by the pictures, you are using yaml-pipelines but classic pipeline triggers. While this works for triggering the pipelines, you might want to consider implementing the triggers in yaml files for C1- and C2-pipelines.
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
As for the yaml-based CD pipeline, in order for the pipeline to trigger upon completion of CI2 and for it to download artifacts from the triggering run (instead of latest from the default pipeline), you should reference the CI2-pipeline as resource:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops
So something like:
resources:
pipelines:
- pipeline: ci2_pipeline #this is used to reference this resource in CD pipeline
source: CI2 #Rename this to match your build pipeline name
trigger:
branches:
- services-release/*
For the artifacts, you want to ensure that you are using Pipeline Artifacts instead of classic build artifacts and use the Download Pipeline Artifacts -task in CD-pipeline (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-pipeline-artifact?view=azure-devops). So something like:
steps:
- download: none # Disable downloading default artifacts
- task: DownloadPipelineArtifact#2
inputs:
buildType: "specific"
project: "$(resources.pipeline.ci2_pipeline.projectID)"
definition: "$(resources.pipeline.ci2_pipeline.pipelineID)"
preferTriggeringPipeline: true
buildVersionToDownload: "latestFromBranch"
branchName: "$(Build.SourceBranch)"
targetPath: "$(Pipeline.Workspace)"
I am using 'batched CI' trigger for a number of pipelines in our Azure DevOps Server installation, as in
trigger:
batch: true
branches:
include:
- master
These pipelines in turn use build artifacts from another pipeline for performing their actions:
resources:
pipelines:
- pipeline: artifacts
source: Artifacts
trigger:
branches:
include:
- master
After a triggered build has finished, I need to retrieve information on the exact build resource the triggered build was using, i.e. what artifacts it was based on. But I cannot find any information on that.
I've tried the REST API for build items, and that is supposed to contain properties TriggerInfo and TriggeredByBuild. But these never contain any information.
The information is clearly possible to retrieve, since every build summary in Azure DevOps contains the Related/Consumed artifact information. But does anyone here know how to retrieve this information?
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.
Problem
Azure DevOps has a feature (documented here) to trigger a pipeline on completion from another pipeline.
This works fine in a test organization, but it won't work in our main organization.
There could be something on the organization, project, repository or even branching level, but I'm currently stuck and any help would be appreciated!
Pipelines
Pipeline Pipeline B should run automatically when pipeline Pipeline A completes.
File pipeline-a.yaml for Pipeline A:
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo Hello, world!
displayName: 'Do something'
File pipeline-b.yaml for Pipeline B:
trigger: none
pool:
vmImage: 'ubuntu-latest'
resources:
pipelines:
- pipeline: pipeline-a
source: 'Pipeline A'
branch: master
trigger:
branches:
- master
steps:
- script: echo Hello, world!
displayName: 'Do something'
Organizations
In my test organization the above pipelines run like a charm. This means that Pipeline A runs on a commit, and after completion, Pipeline B runs automatically.
Yet in our production organization, Pipeline B does not run automatically.
Discovery
Both pipelines run fine when started manually, in both organizations
All Preview features are equal on organization and personal level for both organizations, including the Multi-stage pipelines feature.
The production organization has branch policies on master, while the test organization does not have policies. I don't see a connection with pipeline triggers and did not investigate this.
Installing extensions to have them equal on test and production does not make a difference.
The test organization seems to be in the slow ring and was still on Sprint 161. EDIT: The issue persists after the organization was updated to Sprint 162.
It works when I use the classic editor and manually create a build completion trigger. But this overrides the YAML pipeline trigger and I don't want to do this (I want to generate the pipeline and it's triggers)
Deleting and re-adding the pipeline did the trick. So keep the YAML file but delete the pipeline and add it again.
The Azure DevOps backend seems to miss a relationship between pipelines now and then.
We troubleshot a similar problem today. With Pipeline-A defined as a resource that is meant to be consumed by Pipeline-B.
The consuming pipeline was never being triggered. Deleting and recreating the pipeline did not work for us. This work\pipeline was net new and on a feature branch. That ended up being important.
The ultimate fix was defining that feature branch as the Default branch for manual and scheduled builds in Pipeline-B. You can find that setting tucked away in Pipeline -> Edit -> triggers -> yaml-> Get Sources. Expect that as we promote this code to the main branch we will need to update the setting.
So it seems like the Default branch for manual and scheduled builds would be better named
Default branch for manual and scheduled builds and Pipeline Completion Triggers
In my case it was as simple as the source pipeline completing with an error. Testing with a very simple non erroring pipeline and the code worked fine.