Closed alvipeo closed 3 years ago
Hi @alvipeo
do I see it correctly that you are using a Build on one Organization to trigger another one that is on a different Organization?
The team project name has to match exactly, so if there would be some space or so this could cause it. Another source of problems could be the access rights - when using OAuth you will have the build service access rights, meaning it might not be "allowed" to see the project. You could try using a Personal Access Token to verify that assumption (make sure to create the PAT in the target organization where the build you want to trigger is located).
Another option to try it out would be to use the "Guid" instead - it's not as readable but we could try it out just to see whether this works to pinpoint the problem.
To get the guid of your team project, run the following request:
GET https://dev.azure.com/someorg/_apis/projects/MyProjectIneedToTrigger
The returned json object should contain an id property with the guid.
Yes, the org is the same. The team project is copy pasted, so it does match exactly.
I tried many things and at the end I just added a second pipeline and used Build Completions Trigger. Works like a charm!
I think the issue is that the Azure DevOps API call via the SDK is only returning the first 100 projects.
If you are using the REST API to get the project list it too only returns a max of 100 projects. You can get more by adding the $top=500
to get more or handle the continuation token, but I think the SDK does neither.
Using the GUID for project in this tasks is the easy workaround
Hi @alvipeo
do I see it correctly that you are using a Build on one Organization to trigger another one that is on a different Organization?
The team project name has to match exactly, so if there would be some space or so this could cause it. Another source of problems could be the access rights - when using OAuth you will have the build service access rights, meaning it might not be "allowed" to see the project. You could try using a Personal Access Token to verify that assumption (make sure to create the PAT in the target organization where the build you want to trigger is located).
Another option to try it out would be to use the "Guid" instead - it's not as readable but we could try it out just to see whether this works to pinpoint the problem.
To get the guid of your team project, run the following request:
GET https://dev.azure.com/someorg/_apis/projects/MyProjectIneedToTrigger
The returned json object should contain an id property with the guid.
We ran into a similar problem. We have 2 team projects: TeamA and TeamB. In TeamA we have a PipelineA, in TeamB we have a PipelineB.
While for most projects we can reference from PipelineA to PipelineB using OAuth token, for some projects on TeamA we cannot. We get the same message as the author. I used my own PAT token to confirm the issues lies on the authorization side - I was able to call the PipelineB from PipelineA. No idea why though all other projects can discover TeamB, but this one cannot. Is there any way to view the scope of the OAuth token or fiddle with project/pipeline settings, so PipelineA can access/see it?
@mbartusz
If using OAuth, the "Build Service User" of that project is used. Probably you can check your Azure DevOps settings and see what permissions this specific user has (it's the user of the team project where the Pipeline runs that contains the trigger build task).
I'm not an expert when it comes to this part of Azure DevOps, but maybe it helps you to give you the required hint. So this user should then have permission to access/trigger the other pipeline in the other team project.
Let me know if this helped.
I set this task for my project but I keep getting this error:
I did provide the project name as it shows in my project's properties. Why can't it find it?