This post was most recently updated on February 25th, 2023.4 min read.
It took me something like 10 years of struggling to get remote triggers to finally fire in Azure DevOps, and in this article, I’ll share how I finally got the remote repository trigger to work for an actual Team Project in real production use (and that’s a first!) 😃
Okay, I know, that’s a bit rich – they’ve been supported for maybe a few years, so there’s no way I’ve been struggling with remote triggers for 10 years. And I haven’t!
But I have worked with Azure DevOps (or it was called Visual Studio Team Services, and before that, Team Foundation Server) for almost 10 years. And I ultimately like the product. But it has often been a struggle. So there.
Azure DevOps hasn’t been getting that many new features lately (more focus seems to be on GitHub), but it’s still a staple in the development process of many software teams in the world. And I doubt the usage is even going down – rather, it sounds like it’s here to stay!
One of the bigger changes in the last years was the service implementing YAML pipelines. While introducing a host of new issues, it’s ultimately a super flexible and well-refined way to define a pipeline. And your pipeline is defined as code and checked in like any other code. Inception and all that stuff.
For a very long time, AzDO has supported checking out multiple repositories, which might be useful in a few different situations.
Since early 2020 or so, you have also been able to define and check out remote repositories, i.e. git repos from different organizations or Team Projects. This is a well defined and apparently well-liked feature that a lot of people have used.
Well, the problem is, for me, this remote triggering functionality has never worked.
I’ve tried configuring it 2-3 times in the last few years, had a few friends look over it, and it never worked. Not even once. Frustratingly, the pipeline just failed to trigger with no errors or anything like that.
And it wasn’t just me! Smarter colleagues tried, too. To no avail. It almost seemed like this functionality, this holy grail of continuous integration across repositories and even Team Projects, was actually a fad.
Ah, but it wasn’t. It is a real feature. But sometimes, making the functionality actually, well, function, can be a bit of a pain.
Time needed: 30 minutes.
How to build an Azure DevOps pipeline that’ll trigger remotely from a different repository?
- Make sure your local git repo has trigger defined
So for whatever reason, this seemed to be important: Your local git repository needs to either have a trigger set to a branch or none. Without the statement or with an empty trigger, the configuration wouldn’t work.
So, in short, you could have this to disable CI triggers in the current repo (in my case, the one hosting the pipeline files and templates):
And then you can later define the remote trigger.
- Define the remote repository as a resource
Now you’ll want to add the “remote” repository as a resource for your pipeline so that you can refer to it in later steps. This can be done somewhat like this:
# Specify other repositories
- repository: 'myrepo'
name: My Team Project Name/MyRepo
“My Team Project Name” refers to the name of the team project housing your remote git repository. Spaces are fine – and actually, they are required if your team project name has them.
“MyRepo” refers to the name of the repository itself. Make sure to have the casing correct!
In this case, $(RemoteBranch) is a pipeline variable that you can set during pipeline execution. For me, it’s “main” by default.
I set my pipeline to trigger on commits to 3 different branches, namely main, dev and preprod. This is the coveted remote trigger! Super easy. But soon we’ll see if it actually works or not.
- Check the remote repo out
Okay, at this point you should be able to at least check out the code from your remote repository. And just for the record – while I hadn’t been able to get the remote triggers to work earlier, checking out has always worked just fine.
Should be straightforward enough:
- checkout: myrepo
The checkout task accepts the remote repository name – as defined in your resources -section – as input. Additionally, you can set the checkout path, but in my case, that was not required.
- Automatically trigger the pipeline from the remote repo
And now comes the interesting part! Your pipeline should automatically trigger from commits to the 3 branches shown in earlier steps – main, dev and preprod.
If it does, you’re good.
If it does not, see the YAML sample below and any issues and solutions I might’ve documented in the Problem resolution -section below.
And there you have it! Should be that straightforward, although it unfortunately not always is.
The full sample
So here’s a sample of a pipeline that actually does function for me.
name: $(date:yyyyMMdd)$(rev:.r) # Trigger for main repository trigger: none # Specify other repositories resources: repositories: - repository: 'myrepo' type: git name: My Team Project Name/MyRepo ref: $(RemoteBranch) trigger: - main - dev - preprod stages: - template: templates\stages_pipeline.yml parameters: repository: 'myrepo'
The pipeline is pretty heavily templatized, so all of the steps, jobs and stages are actually in a few different templates. But all of that stuff is actually completely irrelevant to the remote triggering!
Note: $(RemoteBranch) is a pipeline variable that you can set during pipeline execution. For me, it’s “main” by default. It refers to the branch that the pipeline should check out from the remote repository.
I’ll try to log any issues and solutions I run into under this section. Let’s see which ones I manage to encounter.
One thing I’ve run into a few times is that the pipeline is somehow corrupted.
Try recreating the pipeline and you should be good! I’ve submitted feedback about this to Microsoft but haven’t heard back 😅
- How to fix OnePlus 10 Pro Bluetooth issues - May 23, 2023
- How to actually uninstall conflicting PowerShell modules? - May 16, 2023
- How to enable Developer Mode on Android? - May 9, 2023