I'm working on the web services project on the Azure DevOps. I have written the yaml pipeline for build and release.
Currently I have kept the yaml file in Develop branch and created the pipeline job from same. As per the practice, we have two branches - Master & Develop. So how I can use single pipeline job for both the branches with auto trigger for develop and schedules base for main branch ? What is the best practice to build and deploy the code to DEV, UAT and PROD environments for Development and Master branches?
Update:
You need to make sure the yaml file that the pipeline use exists in both master and Develop, otherwise the commit will not trigger the pipeline at all.
1, pure yaml trigger settings in one pipeline.
azure-pipeline.yml in Master branch:
trigger:
- none
schedules:
- cron: "53 7 * * *"
displayName: Master Schedule
branches:
include:
- master
always: true
pool:
name: default
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
azure-pipeline.yml in Develop branch:
trigger:
- Develop
pool:
name: default
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
2, pure UI settings in one pipeline.
Original Answer:
You can override the CI trigger of your pipeline.
Pipeline of develop branch:
Pipeline of master branch:
Related
I'm using Azure DevOps for pipelines and GitHub as my repo. I want to trigger a build in Azure DevOps when a pull request is made.
I have two branches in GitHub: master and test.
When I update test and create a pull request I want Azure DevOps to automatically build the pipeline and run it... how can i do this ?
I tried the below but nothing happens
pr:
main
trigger:
main
pool:
vmImage: ubuntu-latest
You can add a pr trigger in your yaml pipeline:
pr:
- master
this worked for me in the end :
**pr:
branches:
include:
- '*'**
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
We have a YAML based pipeline that Unit Tests and build an ASP NET Core website then if everything is OK it deploys to DEV, TEST and eventually Live Azure Resources.
Our source control is Git within Azure Dev Ops.
Our process has us working in a branch for each feature, once those branches are ready we merge them into a "release" branch for an integration test before being PR'ed to MAIN. An example of our release branch would be "release_3_1_5".
The start of the YAML pipeline looks like this
pool:
vmImage: 'windows-latest'
# Why would I want 'resources'
# resources:
# pipelines:
# - pipeline:
variables:
azureSubscriptionEndpoint: 'ARM Service Connection'
webAppKind: webApp
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
# Change this when adding functionality that is a breaking change
majorVersion: 3
# Change this when adding functionality that is backwards compatible
minorVersion: 1
# Change this when making fixes that are backwards compatible and not adding functionality
buildVersion: 0
# Concatenate version parts and buildId to get a full build version string
fullBuildVersionString: $(majorVersion).$(minorVersion).$(buildVersion).$(Build.BuildID)
name: $(MajorVersion).$(MinorVersion).$(buildVersion).$(Build.BuildID)
stages:
- stage: Build
jobs:
- job: Build_Job
steps:
- bash: |
echo $(fullBuildVersionString)
We don't specify any explicit triggers so the build runs everytime we push to a branch.
The "MAIN" branch has some branch policies set, those policies include "Build Validation" and currently the Build Validation build policy is configured to run the same YAML pipeline.
The CI pipeline works just fine when pushing changes to our branches, except when the branch in question is the subject\source of a PR to MAIN. In this situation the pipeline starts twice. Once for the push to the "release" branch and once by the branch policy because of the PR into MAIN.
Is there a better way to configure the pipeline so it does not kick off twice? I basically do not want the CI truigger to fire when the branch is the source of a PR to MAIN but that looks like an impossible condition
This is something we struggle with as well. We have just accepted the double builds for now. However, I am starting to consider not having a build trigger for feature/ branches and only trigger for PRs.
The only other option are double manifests. One manifest for branches that are not MAIN, and the other being a manifest that includes only PRs and the MAIN branch.
If you want builds to run for branches, you could consider pre-receive hooks that requires builds to run locally.
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.
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
My pipeline looks like:
trigger:
branches:
include:
- release-*
jobs:
- job: release
condition: contains(variables['Build.SourceBranch'], 'refs/heads/release-')
pool:
vmImage: 'windows-latest'
steps:
- bash: |
echo "RELEASE"
displayName: 'release_task1'
How can I make it executed automatically when new release-.. branch is created?
How can I make it executed automatically when new release-.. branch is created?
This is a limitation of YAML trigger.
If the yaml file is not present in the new create branch, the build will not be triggered.
That is reason why it does not execute automatically when creating a new release ... branch.
To resolve this issue, we need to create the yaml file in the basic branch, like release-basic, then we create a new branch based on the branch release-basic. Now the build will be executed automatically.
Hope this helps.