When doing a deployment job with a CI trigger and resources.pipelines that are defined like
resources:
pipelines:
- pipeline: thumbnailGenerator
project: myServices
source: thumbnail-generator CI
trigger:
branches:
include:
- master
The deployment job downloads the latest build of the pipeline (which may be a PR) rather than the last build from master. Is there a way of making it only download the specific branches when doing a CI build?
I haven't explored it yet, but I am thinking based on this behaviour it will always do the latest builds for all the pipelines regardless.
There's a property called branch on the pipeline object
resources:
pipelines:
- pipeline: thumbnailGenerator
project: myServices
source: thumbnail-generator CI
branch: master
trigger:
branches:
include:
- master
Related
I have trigger in azure-pipelines.yaml like below.
resources:
repositories:
- repository: APPLICATION
type: git
name: AAA/APPLICATION
ref: master
- repository: TESTS
type: git
name: AAA/TESTS
ref: master
STAGES:
- stage : BuildApplication
// checkout branch & build necessary things
- stage : BuildTests
// checkout branch & build necessary things
Since the yaml resides in Application repository, While creating manual CI build I am able to select the Branches in Application repository & for Tests repository the branch checkout will be master always.
is there any was I can able to set the branch details of Tests repository before creating release ?
Is there any was I can able to set the branch details of Tests repository before creating release ?
From your YAML sample, you need to select the Resource Repo branch when manually running the pipeline.
I am afraid that there is no out-of-box method can select the resource repo branch. The branch is defined at resources field. When you running the pipeline, it will use the default branch.
For a workaround, you can change to define the repo in check out field. You can use paramter to define the repo branches and then you can select the branch when you running the pipeline.
Refer to this doc: Inline syntax checkout
Here is an example:
parameters:
- name: test
values:
- refs/heads/main
- refs/heads/test1
pool:
vmImage: ubuntu-latest
steps:
- checkout: git://azure/Repo13#${{ parameters.test }}
Result:
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)"
In ADO, you can create a "repository resource" per this documentation. The "trigger" section allows you to define a CI trigger for any Azure repo in your space. Therefore, given the following config:
Repos:
AzureRepo1 - Contains project files that should be built
AzureRepo2 - Contains pipeline file 'pipeline.yml'
resources:
repositories:
- repository: "Azure_Repo_1"
type: git
name: AzureRepo1
ref: development
trigger:
branches:
include:
- development
- staging
- production
pool:
vmImage: 'windows-latest'
jobs:
- template: Template.yml
parameters:
service: "development"
run_tests: true
When I make a change to AzureRepo1, the pipeline triggers. At runtime, how would I determine which branch ("production", "staging", or "development") of the target repo (AzureRepo1) triggered the build? Ideally, the "service" parameter being fed into the example template would dynamically reflect which branch triggered the build.
Note: "Build.SourceBranch" and "Build.SourceBranchName" seem to pull the branch from the repo that hosts the YML file (in this case, AzureRepo2).
I was wrong. These function as intended. Use the below solution.
According to documentation here:
When an update to one of the repositories triggers a pipeline, then the following variables are set based on triggering repository:
Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage
For the triggering repository, the commit that triggered the pipeline determines the version of the code that is checked out. For other repositories, the ref defined in the YAML for that repository resource determines the default version that is checked out.
If triggers happens on AzureRepos1 you should have correct branch name in Build.SourceBranchName
I want my YAML in one repo RepoA and my code to build in RepoB. How do I configure the YAML to have a CI Trigger on the code RepoB only?
Note: these repos are in the same Azure DevOps project.
The YAML is in the default branch (master) of RepoA. I've seen that people have had issues with CI triggers if the pipeline is not in the default branch.
Here is the azure-pipeline.yml contents:
trigger: none
resources:
repositories:
- repository: RepoB
type: git
name: RepoB
ref: master
trigger:
- master
pool:
vmImage: 'windows-latest'
steps:
- checkout: RepoB
I also tried removing the line
trigger: none
to see if that would work. The build will then start as soon as I save the yaml, as I would expect, but not when I make a change to RepoB master.
Then I tried the following and many more guesses, but nothing ever enabled a CI Trigger on RepoB. That is, the pipeline never ran when I would make commits to the master branch in RepoB.
resources:
repositories:
- repository: RepoB
type: git
name: RepoB
ref: master
trigger:
branches:
include:
- master
pool:
vmImage: 'windows-latest'
steps:
- checkout: RepoB
Here is what I see when I look at the pipelines triggers in the Azure Pipelines UI. Should I see a trigger for RepoB?
Update 1:
Although these were not my original settings, I have updated the settings to be as open as possible (no limits). I then tried the following:
I committed a file to the branch in RepoB. No CI trigger occurred.
Deleted the pipeline, and recreated. I committed a file to the branch in RepoB. CI Trigger finally occurred!
I believe this is a bug because none of these settings should limit this scenario for the following reasons:
Both of the repos are in the same Project.
RepoB is explicitly referenced in the pipeline.
Also, you shouldn't have to delete and recreate a pipeline in order for a setting to take effect.
UPDATE 2:
I narrowed it down to this Organization or Project level setting: Limit job authorization scope to referenced Azure DevOps repositories
The documentation of this setting does not mention CI Triggers at all, but I do not think that it should affect this scenario regardless, because the repo is referenced explicitly.
Doc References:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml#limit-job-authorization-scope-to-referenced-azure-devops-repositories
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#limit-job-authorization-scope-to-referenced-azure-devops-repositories
I believe this is a bug and I have reported it here:
https://developercommunity2.visualstudio.com/t/yaml-pipeline-ci-trigger-for-repository-resource-i/1314241
Azure DevOps enables some limitation to access to resources by default. Please check if this project enables below options in Project Settings page.
Testing in my side that if these options are enabled, this issue can be reproduced. Thus please disable them, and create a new yaml pipeline. The new yaml pipeline should work as expected.
See: Access repositories, artifacts, and other resources for details.
I used your yaml and all works (the only difference is that I have main not master branch)
trigger: none
resources:
repositories:
- repository: RepoB
type: git
name: azure-functions
ref: main
trigger:
- main
pool:
vmImage: 'windows-latest'
steps:
- checkout: RepoB
On this screen you have a trigger which fires for a change done on RepoB
I have the following repositories:
my-app-repo - Contains the code for the app
pipeline-repo - A collection of pipelines that build my-app-repo as well as others
I'm trying to build a yml pipeline within pipeline-repo that will be triggered on a commit to my-app-repo.
According to the official yml documentation, it sounds possible but I'm not able to get it working.
Here's what I've tried:
pipeline-repo/my-app-repo-build.yml
resources:
repositories:
- repository: target_repo
type: git
name: my-project/my-app_repo
trigger:
branches:
include:
- master
jobs:
- job:
steps:
- script: echo "Should be triggered from a push to my-app-repo!"
The build is not triggering when I push to my-app-repo. It only kicks off for commits to the source repo (pipeline-repo) which I cannot change since that holds the yml definition.
Am I missing something easy?
Edit:
I see you've added an issue to the github repository you mentioned. I agree that it seems to be broken.
While you aren't exactly trying to provide template functionality to your pipelines, you might use it as a work around until the issue you created is addressed.
I've tested this in my playground and it seems to work.
In the app repository
resources:
repositories:
- repository: templates
type: git
name: Pipeline-Templates
trigger:
branches:
include:
- master
jobs:
- template: azure-pipelines-template.yml#templates
In the pipelines repository
jobs:
- job: Get_Last_10_Commits
pool:
vmImage: 'vs2017-win2016'
steps:
- task: PowerShell#2
inputs:
targetType: 'inline'
script: |
cd $(Build.SourcesDirectory)
Write-Host "Show git log (last 10):"
git log --oneline -10
One "advantage" of this work around is that you no longer need to specify that the repository to checkout is the resource repository and not the self (your template-repository) as the self repository is the app-repo.
This would allow you to restrict changes to the pipeline core by having it in a separate repo like you want, but would still trigger on the app-repo master.
Not ideal b/c you now have 2x .yml files for each build you need, but that's basically the definition of work around: not ideal.
It looks like your include syntax is wrong. Have you tried to use the simple syntax?
All of the examples (and my experience) show that you should use the wildcard syntax when your trigger has an include or exclude specification.
resources:
repositories:
- repository: myPHPApp
type: GitHub
connection: myGitHubConnection
source: ashokirla/phpApp
trigger:
branches:
include:
- features/*
exclude:
- features/experimental/*
paths:
exclude:
- README.md