I have a repository with two solutions in it. Both solution files exist in the root directory, essentially like this:
/WebsiteOneDirectory/
/WebsiteTwoDirectory/
/.gitignore
/WebsiteOne.sln
/WebsiteTwo.sln
Is it possible for me to build multiple pipelines pointed at this repository to build the different solutions? When I create my first pipeline it is generating a azure-pipelines.yml file for the repo, so I am unsure how/if I am going to be able to have multiple pipeline configurations if that is a fixed name it expects.
In addition to James Reed's answer, if you prefer using the .yml files, what I would recommend is to create multiple .yml definitions, one for each pipeline.
Here's what one would look like:
trigger:
branches:
include:
- master
paths:
include:
- WebsiteOneDirectory/*
exclude:
- WebsiteTwoDirectory/*
For building, you'd need to specify which solution to build. For a (.net core) example:
variables:
buildConfiguration: 'Release'
pool:
vmImage: 'Ubuntu-16.04'
steps:
- script: dotnet build WebsiteOne --configuration $(buildConfiguration)
Yes, you can use path filters in your trigger
Edit your build and go to the Triggers tab. Here you can add or remove branches, and also add path filters.
You have the option to either explicitly include or exclude paths. In the image below you can see that I'm explicitly excluding the "docs" folder from the master branch.
Related
I've a single repository having visual studio solution(.sln), where I've more than one project(.csproj) in same solution(i.e. WebAPI project, WebApp project etc.)...
Now, I've created separate pipeline(s) for individual project, which trigger whenever any commit comes to my XYZ branch...(ex. through PR code merge from feature to XYZ branch)
Now, the issue is...
Whenever any commit come to any project in that repository all pipeline start building there respective projects... Here I just want to build a specific project pipeline for which the commit file(s) comes into...
You can specify file paths to include or exclude.
# specific path build
trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md
When you specify paths, you must explicitly specify branches to trigger on. You can't trigger a pipeline with only a path filter; you must also have a branch filter, and the changed files that match the path filter must be from a branch that matches the branch filter.
Check here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers
My project is using microservices and in one repos we have multiple applications in Azure DevOps.
For Example, we have Repos named Microservice, where we have .NetProject, AngularUI Project, and Java Project code.The structure looks like this:
While setting up the CI pipeline, I have included the path like the below:
variables:
- name: working-dir
value: 'MicroserviceProject/AngularUI/ClientApp/'
trigger:
branches:
include:
- master
paths:
include:
- 'MicroserviceProject/AngularUI/ClientApp/*'
I don't see the code of AngularUI project being checkout properly and encountering the error, that they cannot locate the package.json file.
How can I set the working directory for different projects in a repo?
Update:
I am able to locate the file but the build isnot giving me any output files.
How I fixed this issue:
Initially I was not sure if the working directory was set properly.Even if it was , I was not sure whether the package.json file was read properly. To check that, I added the below script to the Azure CI pipeline, for example:
inputs:
targetType: 'inline'
script: dir
$(Build.ArtifactStagingDirectory)
displayName: 'Check'
This showed me that after building , the artifacts are not stored anywhere. hence I had to explicitly mention the outputpath. For that I ran the below command for build:
run-script build -- --output-path=$(Build.ArtifactStagingDirectory
This fixed the issue I was facing.
I have a single project but with two "master" branches.
master
virt/master
Each of them would have their own azure-pipeline.yml specific for their branch.
The first pipeline in master has the trigger set up as
trigger:
batch: true
branches:
include:
- refs/heads/master
The second one is in the virt/master branch.
trigger:
batch: true
branches:
include:
- refs/heads/virt/master
Here's the repository that I am experimenting on https://dev.azure.com/trajano/experiments/_git/multi-branch
master build https://dev.azure.com/trajano/experiments/_build?definitionId=11
virt/master build https://dev.azure.com/trajano/experiments/_build?definitionId=12
The problem I am having is when I push a change to the virt/master branch both pipelines get executed
Am I missing something in my configuration? Or is this a bug on Azure Devops?
I also tried to exclude but to no avail.
trigger:
batch: true
branches:
include:
- refs/heads/master
exclude:
- refs/heads/virt/master
If you want to have separate pipelines please create separate file definition for them. I think that your configuration is fine and the issue is that you share the same file as definition.
When I moved to separate file it works as expected:
To create different pipelines for different branches. You need to rename the azure-pipelines.yml file in virt/master branch or create a new yml file with the some contents and with a different name. And create pipeline multi-branch(virt) from this new yml file.
If both pipelines are created from the yaml file with the same name azure-pipeline.yml. And the azure-pipeline.yml file exists in both of the branches. Then they are identical pipelines(even though the azure-pipeline.yml file contents might be different).
You can see from above screen. Pipeline multi-branch and multi-branch(virt) were building the same virt/master branch(using the tasks in the azure-pipeline.yml of virt/master). If you push to master branch. You will see both pipelines will be triggered to build master branch(using the tasks in the azure-pipeline.yml of master). Pipeline multi-branch and multi-branch(virt) are one pipeline
See this thread for more information.
I've read the official documents to put the yaml file in the root of a project. I'm thinking to create a some sort of pipeline repo that contains several yaml files in charge of different pipeline workflow for different project. But Azure pipeline only recognise the azure-pipeline.yaml file name.
Issue:
It is obviously not possible to create several yaml files with the same azure-pipeline.yaml name under the same folder. What's the best practice to organise the azure pipeline yaml files? Shall it be just put in the root of the project?
It sounds like templates might be what you're looking for. This assumes you have a single project/repo and a large pipeline that you'd like to split up so it's easier to read or reason about individual parts.
Taking an example from the linked documentation page, you can define a template yaml file like this (ex: include-npm-steps.yml):
steps:
- script: npm install
- script: yarn install
- script: npm run compile
And then include it as a "module" in the main azure-pipelines.yml file like this:
jobs:
- job: Linux
pool:
vmImage: 'ubuntu-latest'
steps:
- template: templates/include-npm-steps.yml # Template reference
- job: Windows
pool:
vmImage: 'windows-latest'
steps:
- template: templates/include-npm-steps.yml # Template reference
It is obviously not possible to create several yaml files with the
same azure-pipeline.yaml name under the same folder.
Yes, it's not possible to create several yaml pipelines with same name under same folder. Cause the yaml pipeline is under version control and Azure Devops git doesn't support two files with same name in same folder...
What we can do is to create several pipelines with different names in same folder, like azure-pipeline.yaml,azure-pipelines-1.yml,azure-pipelines-2.yml and so on.
Not sure if you know this option when editing yaml pipeline:
We can easily change the yaml file's name in source control, and we just need to modify the path here:
What's the best practice to organise the azure pipeline yaml files?
Shall it be just put in the root of the project?
Assuming you own one Team Project with two repos A and B:
If A and B both represent the module of one final product, then you should have corresponding pipelines for A and B. It means in most scenarios, you should have at least one pipeline in RepoA and one in RepoB. They all need corresponding azure-pipeline.yaml file.
Now if azure-pipeline.yaml in RepoA and azure-pipeline.yaml in RepoB have many same variables/tasks/jobs, we can consider moving the duplicate contents into templates. We can create a RepoC in same project to store the templates, and in this templates repo, we don't need to create yaml pipeline here.
About how to reference templates in RepoC in RepoA's pipeline, see this document. If the source is in github, you can check Krzysztof's link. And if the RepoC is in Azure Devops Repos and same project with your RepoA and RepoB, you can should this format:
resources:
repositories:
- repository: templates
type: git
name: RepoC
ref: refs/heads/master
To sum up, functional repos (those with source code) should have corresponding yaml pipeline in it. And if you want to monitor the changes in one repo (without source code) for some purpose, you can also have one yaml pipeline in that. For templates repo, yaml pipelines are not necessary.
Also, apart from yaml pipelines you may sometimes use Classic Build/Release pipelines which are not under Version Control. See this.
I have a project which depends on 2-3 other projects, is there a way to pull them together with the master project?
When the build process starts projects will be on the file system and the master project can locate the other dependency projects?
As #Kehinde's said in comment, what you want could be achieved by the feature Multi-repo checkout.
Note:
Multi-repo checkout is the feature which only supported YAML. Because what the design logic is Checkouts from multiple repos in combination with YAML builds enable focusing the source level dependency management to one structured descriptor file in Git (the YAML biuld definition) for good visibility.
But for pipeline that configured by classic UI, you had to add those other repositories/projects as submodules, or as manual scripts to run git checkout in pipeline.
For personal, I strongly suggest you use YAML to achieve what you want.
Simple sample YAML definition:
resources:
repositories:
- repository: tools
name: Tools
type: git
steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)
Here, image I have a repository called "MyCode" with a YAML pipeline, plus a second repository called "Tools".
In above third step(dir $(Build.SourcesDirectory)), it will show you two directories, "MyCode" and "Tools", in the sources directory.
Hope this helps.
For Bitbucket:
resources:
repositories:
- repository: MyBitBucketRepo
type: bitbucket
endpoint: MyBitBucketServiceConnection
name: {BitBucketOrg}/{BitBucketRepo}
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: self
- checkout: MyBitBucketRepo
- script: dir $(Build.SourcesDirectory)