Failed to retreive the Service Connection - Sync-ElasticPool.ps1

[jessicalavoie]

Hi,

I have been hitting an issue lately, its related to the section to Register the scale set into ADO. The service connection isnt getting picked up The service connection running the task has full access to the ADO project&ORG as a build administrators so its not rights related...

Im trying to run the code locally to validate the underlying of the error but not much getting very far :\

Any ideas why its failing ? the rest is very great. Good work btw.

thanks

[AlexanderSehr]

Holy Molly, hey @jessicalavoie. Please excuse the delay of merely a few months. The creation of the issue must have gotten lost under the flood of notifications from GitHub. That being said - if the issue still persists (I hope note), then I'd ask you to double-check if the pipeline agent (i.e., the principal used by the pipeline) is configured so that it can ready the service connections as described here (Initial configuration / 1.1 (Optional) Configure the agent pool parameters & environment / 1.1.2 Configure the Azure DevOps environment to enable the pipeline to read & register the resources)

If you can confirm that the permissions are configured correctly, my next best test would be to create a dummy pipeline with a simple AzureCLI task and try to retrieve the service connections using an implementation like here.

Please let me know how it's going.

[jessicalavoie]

Hi Alexander,

not a problem for the delay, i dit it manually for the time being. Im going to test this out again this week - if I remember correctly my service connection has the full access required for the org-project in ADO. Ill test with the dummy get-endpoint.ps1 see if i get any output and might get back to you in any cases!

thanks a lot Jessica

On Thu, Jul 4, 2024 at 3:28 PM Alexander Sehr @.***> wrote:

Holy Molly, hey @jessicalavoie https://github.com/jessicalavoie. Please excuse the delay of merely a few months. The creation of the issue must have gotten lost under the flood of notifications from GitHub. That being said - if the issue still persists (I hope note), then I'd ask you to double-check if the pipeline agent (i.e., the principal used by the pipeline) is configured so that it can ready the service connections as described here https://github.com/Azure/DevOps-Self-Hosted/wiki/Self-hosted%20Azure%20DevOps%20Virtual%20Machine%20Scale%20Set%20Agents#initial-configuration:~:text=Enable%20the%20build%20service%20to%20list%20service%20connections (Initial configuration / 1.1 (Optional) Configure the agent pool parameters & environment / 1.1.2 Configure the Azure DevOps environment to enable the pipeline to read & register the resources)

If you can confirm that the permissions are configured correctly, my next best test would be to create a dummy pipeline with a simple AzureCLI task and try to retrieve the service connections using an implementation like here https://github.com/Azure/DevOps-Self-Hosted/blob/main/constructs/azureDevOpsScaleSet/scripts/registerAgentPool/Get-Endpoint.ps1 .

Please let me know how it's going.

— Reply to this email directly, view it on GitHub https://github.com/Azure/DevOps-Self-Hosted/issues/36#issuecomment-2209485935, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABU45YHHMLQCJMW5BOVC6PDZKWO7PAVCNFSM6AAAAABG6PIGXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBZGQ4DKOJTGU . You are receiving this because you were mentioned.Message ID: @.***>

[AlexanderSehr]

On that note (and I haven't tested it yet, so please take it with a grain of salt), there seems to be a new Resource Type on the Horizon: DevOps Infrastructure Pool. A colleague is currently working on an implementation for the Azure Verified Modules, to which I also aim to contribute the image building construct (at least to an extend). Ideally, the two will complement each other and it will simplify the 2 constructs in this repository quite a bit. Nothing to leverage yet, but a heads up in case it's of interest to you 😉

[AlexanderSehr]

Hey @jessicalavoie, if of any interest, please note that I just release a new major version of the IP that not only upgrades the codebase to AVM, but also switches the Agent-Pool implementation from 'VMSS + custom code to register it as an agent pool' to the new 'Managed DevOps Pool' service with has a different, better approach towards the registration.

PS: While refactoring the solution I was wondering if maybe this parameter caused you the headache: https://github.com/Azure/DevOps-Self-Hosted/blob/f9ee6fd753f49642179cf86965b359827fc93733/constructs/azureDevOpsScaleSet/scripts/misc/REST.jsonc#L5 I've recently worked more with other Enterprise Applications and can't help but suspect this GUID is tenant-specific (i.e., different in your tenant) and would need to be updated too.

[jessicalavoie]

Hey @AlexanderSehr ! i wasn't aware of the Managed DevOps pool in preview! will definitely keep an eyes on this and the development you guys are working on. very nice!

Might return on this project in the upcoming weeks, so ill pull the new file you mentioned about the PrincipalId and will retest the pool deployment process to see how it behave!

Thanks a lot for the information's. Jessica

[AlexanderSehr]

Sounds good. Let me know how it is going when you get the chance 💪