I am working on a task (a spike) which is about investigating the usage of pipeline (exists in) organization-1 to another organization-2.
So far I have found nothing on the Microsoft documentation about the usage of pipelines/projects/repos across organizations
Only information I have found in MS documentation (Project QnA) tells that you can move/transfer the data to another organization but not without loosing it or use the trid-party tool to copy the data.
Somewhat same information I found in this SO link (Azure DevOps Repos synchronization between Organization).
I wonder if the above two solutions are the few possible ways to use the pipeline across organizations? And does Microsoft provide any "out-of-the-box" solution for it at all?
Does anyone else tried/faced the same scenario? If so, how you resolved this? Or did you contact the Azure support for this?
Note: I also created two different organizations in DevOps and explored the ways (especially using service connections) if a pipeline or project becomes available in another organization, but, I could not found any solution for it.
In Pipeline, if you want to use Azure Repos Git repositories in a different organization than your pipeline, you need to create Azure Repos/Team Foundation Server service connection, and use a repository resource in your pipeline:
resources:
repositories:
- repository: MyAzureReposGitRepository # In a different organization
endpoint: MyAzureReposGitServiceConnection
type: git
name: OtherProject/MyAzureReposGitRepo
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: MyAzureReposGitRepository
- script: dir $(Build.SourcesDirectory)
More details, check the documentation here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#repository-resource-definition
Related
I use github for hosting my projects and have multiple projects in github. And I use Azure devops for CICD alone. I have a single project in Azure devops, where I create individual pipeline corresponding to each project in my github repo. All these github projects would need to use the same azure-pipeline.yml for build. So instead of keeping the same yml file in each project, is there a way I can keep this yml centrally. So that in future, if at all a change is required, I need not do it for all individual projects, instead, update the main yml template.
A single yml file where I have all the code is even possible for my usecase? Any help is much appreciated
Have you considered using templates? Essentially you have would end up with a single template containing the main build steps that is reusable and individual yaml for each pipeline that can pass parameters to the template for any differences you have between them (such as different triggers or variable values). This way you can update all pipelines by making changes to the template
Template documentation
According to your description, you may setup a repo contains all the YAML files for pipelines. Kindly also be advised that we can also keep the templates in other repositories, if we have defined the repository resources in the core YAML pipeline. Kindly refer to the sample Core and template YAML files below.
#Core YAML in Azure Repos
trigger: none
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: GitHub_REPO_1
type: github
name: GitHubAccountName/GitHubRepo1
endpoint: GitHubServiceConnectionName
- repository: GitHub_REPO_2
type: github
name: GitHubAccountName/GitHubRepo2
endpoint: GitHubServiceConnectionName
steps:
- checkout: none
# - checkout: GitHub_REPO_1
- template: GHREPO1.yml#GitHub_REPO_1
# - checkout: GitHub_REPO_2
- template: GHREPO2.yml#GitHub_REPO_2
#Template YAML from GitHub Repo
steps:
- script: echo "This YAML template is from GitHubRepo1"
displayName: 'Template From GitHubRepo1'
By the way, we could also checkout the code from one or multiple repository resource(s) and trigger the pipeline by the commits from the repository resources. Please refer to the following documents for more information.
Define YAML resources for Azure Pipelines - Azure Pipelines | Microsoft Docs
Check out multiple repositories in your pipeline - Azure Pipelines | Microsoft Docs
I have a requirement of giving multiple teams access to a shared resource in azure. I therefore want to limit how people can publish changes to the shared resource.
The idea is to limit the use of a service connection to a specific pipeline, as per this documentation. However if the pipeline is stored in their own repo the developer could change it. This would not give me enough control. I therefore found that it was possible using a template from a central repo. Using a shared repo, would then allow me to have a service connection solely for the template?
So how I imagine doing the above is I need to grant project X a service connection for my BuildTemplates Repo. But this is basically just access to the repo and to be able to use the shared templates. Then in BuildTemplates repo I can have a service connection for my template A.
Now the developer in project X - creates her deployments and configurations for her pipeline with her own service connection scoped for her resources. Then she inherits a template from BuildTemplates Repo and passes relevant parameters for the template A.
She cannot alter the template pipeline A and only the template pipeline A can publish to the shared resource, because of the scoped service connection. I can therefore create relevant guards for the shared azure resource in the template pipeline A - so I restrict how developer X can publish to my shared azure resource.
does this make sense and is it viable?
The pipeline part in A cannot be edited by developer in X ?
The service connection in A will not propagate out so developer in X can use it in an inappropriate way?
Update
The above solution does not seem to be viable since the pipeline template is executed in the source branch scope.
Proposed Solution
The benefits I see with the above suggestion doe not seem possible, because of the issues. However one can utilise pipeline triggers, as a viable solution. This however results in a new issue. When a pipeline is triggered by Developer Y in Y's repository and it succeeds. Then a trigger is made in MAIN repository and the pipeline in MAIN fails e.g., because the artifacts from Y introduced an Issue. How does developer Y get notified about the issues in MAIN pipeline?
Here is my solution, in same Azure organization, we can create a Azure Project, then create a repo to save common pipeline template.
All the repos in other Azure project can access this pipeline template.
UserProject/UserRepo/azure-pipelines.yml
trigger:
branches:
include:
- master
paths:
exclude:
- nuget.config
- README.md
- azure-pipelines.yml
- .gitignore
resources:
repositories:
- repository: devops-tools
type: git
name: PipelineTemplateProject/CommonPipeline
ref: 'refs/heads/master'
jobs:
- template: template-pipeline.yml#devops-tools
PipelineTemplateProject/CommonPipeline/template-pipeline.yml
Since the inline script of pipeline has 5000 characters limitation,
you can put your script(not only powershell, but also other languages) in PipelineTemplateProject/CommonPipeline/scripts/test.ps1
# Common Pipeline Template
jobs:
- job: Test_Job
pool:
name: AgentPoolName
steps:
- script: |
echo "$(Build.RequestedForEmail)"
echo "$(Build.RequestedFor)"
git config user.email "$(Build.RequestedForEmail)"
git config user.name "$(Build.RequestedFor)"
git config --global http.sslbackend schannel
echo '------------------------------------'
git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" -b $(ToolsRepoBranch) --single-branch --depth=1 "https://PipelineTemplateProject/_git/CommonPipeline" DevOps_Tools
echo '------------------------------------'
displayName: 'Clone DevOps_Tools'
- task: PowerShell#2
displayName: 'Pipeline Debug'
inputs:
targetType: 'inline'
script: 'Get-ChildItem -Path Env:\ | Format-List'
condition: always()
- task: PowerShell#2
displayName: 'Run Powershell Scripts'
inputs:
targetType: filePath
filePath: 'DevOps_Tools/scripts/test.ps1'
arguments: "$(System.AccessToken)"
Notes:
Organization Setting - Settings - Disable Limit job authorization scope to current project for release pipelines
Organization Setting - Settings - Limit job authorization scope to current project for non-release pipelines
Check some option in project setting as well.
So the normal user only access their own repo, cannot access DevOps project, and DevOps owner can edit template pipeline only.
For the notification issue, I use an Email extention "rvo.SendEmailTask.send-email-build-task.SendEmail#1"
I have checked this link Azure DevOps: 1 Solution Multiple Projects CI/CD which is related to one solution with multiple project.
Can we use multiple solution in single CI CD pipeline ? where we have different artifacts for each solution and app servers to deploy.
Please advise.
As long as the code is in the same repository there are no issues to using multiple .net solutions or any other type.
You can also publish multiple artifacts from the same pipeline
If you are using YAML pipeline, you can check out multiple repositories in your pipeline.
Pipelines often rely on multiple repositories. You can have different repositories with source, tools, scripts, or other items that you need to build your code. By using multiple checkout steps in your pipeline, you can fetch and check out other repositories in addition to the one you use to store your YAML pipeline.
Repository declared using a repository resource :
resources:
repositories:
- repository: MyGitHubRepo # The name used to reference this repository in the checkout step
type: github
endpoint: MyGitHubServiceConnection
name: MyGitHubOrgOrUser/MyGitHubRepo
- repository: MyAzureReposGitRepository
type: git
name: MyProject/MyAzureReposGitRepo
steps:
- checkout: MyGitHubRepo
- checkout: MyAzureReposGitRepository
Repository declared using inline syntax :
If your repository doesn't require a service connection, you can declare it inline with your checkout step.
steps:
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization
For details ,please refer to this official document.
When defining a GUI release I can make it be triggered by an Azure Artifact, is there a way to replicate this for pipelines in YML?
I am building in one AZDO tenant, pushing universal packages to another tenant, where the release definitions will be defined, I'm hoping this can be in YAML. But I don't see an obvious way to do this at the moment?
I see there is a design document that makes mention of packages, but no further details are provided
https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/pipeline-resources.md
Cheers
Edit-
Is there a way to trigger pipeline using Azure Artifacts in YML?-But I don't see an obvious way to do this at the moment?
Yes, Yes. You are right !
That because the content in this document are speculative, designs, and future features.
If you check the upper level of design document you provided, there is a state:
Azure Pipelines YAML - Design Docs
The design docs within this repo are created at different times during
the development of Azure Pipelines, to support collaborative
contributions to the design process. Designs documents are for,
features considered for implementation but never implemented
already implemented features
future ideas for features
The design docs in this repo may not represent the current state
of an Azure Pipelines feature.
When you check the officially release document YAML schema reference-Resources, it only list:
resources:
pipelines: [ pipeline ]
repositories: [ repository ]
containers: [ container ]
So, Azure Artifacts source in YAML should be a future feature at this moment. Hope MS can achieve it one day earlier.
Hope this answer clear your question.
Build completion triggers are not yet supported in YAML syntax. After you create your YAML build pipeline, you can use the classic editor to specify a build completion trigger.
Reference:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#build-completion-triggers
Though i would suggest you to use below mechanism to trigger the release:
Resource triggers
Resources trigger will be helpful in below scenario:
I would like to trigger my pipeline when an artifact is published by ‘Helm-CI’ pipeline that ran on releases/* branch.
I would like to trigger my pipeline when an artifact is published and tested as part of Helm-CI pipeline and tagged as 'Production'.
I would like to trigger my pipeline when ‘TFS-Update’ pipeline has completed ‘Ring2’ stage so that I can run some diagnostics.
https://github.com/microsoft/azure-pipelines-yaml/blob/master/design/pipeline-triggers.md
Webhook triggers
At the end of the CI piepleing , you can add a task to hit webhook url which can trigger your CD is one way.
Hope it helps.
You can use a multi-stage pipeline to achieve this.
One stage would include a task that will push your artifacts to the feed. The next stage will contain other jobs that you want to be executed after pushing the Artifacts.
eg:
stages:
#Stage for preparing the Artifact
- stage: prepare
jobs:
- job: prepare
pool:
vmImage: xx
steps:
- task: PublishBuildArtifacts#1
inputs:
pathToPublish: xx
artifactName: xx
# Next stage in your pipeline
- stage: build
dependsOn: prepare
jobs:
steps:
- task: xx
Note that the second stage build dependsOn the stage prepare.
ps: Multi-Stage pipeline is currently under preview. If you enable it from the preview feature, you will also be able to see a nice visual representation of the stages.
I want to create a central point repository with templates for all my rust projects. And in other projects I just wanna add link to them:
here is an example link to my templates repository. You can find them here.
trigger: ["master"]
pr: ["master"]
resources:
repositories:
- repository: templates
type: github
name: xoac/rust-azure-pipelines
# Test top level crate
- template: azure-test-stable.yml#templates
parameters:
name: test_tokio
displayName: Test tokio
cross: true
And I am getting an error here
I have found here that I need specify service connection.
If you choose github as your type, then name is the full name of the GitHub repo including the user or organization. For example, Microsoft/vscode. Also, GitHub repos require a service connection for authorization.
I don't know what type of connection this should be.
I want to make it accessible to everyone who want to use it.
It would be a Github service connection (when you create new service connection)
Permissions are granted on build level, not on user level, so anyone who can launch the build would be able to launch it and it would work
for github repo name, i think you are using the correct one, but you would also need to add endpoint: service_connection_name to the repositories definition.
Reading:
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema#repository-resource